AmiDARK Engine – Alpha Release 0.4 *publique*

Voici un communiqué d’AmiDARK concernant l’avancée de son moteur de création de jeux nommée « AmiDARK Engine.

Salut,

Une nouvelle version *alpha* de l’AmiDARK Engine a été mise en ligne sur www.os4depot.net.
Elle se trouve actuellement dans la liste des « uploads » mais elle devrait rapidement se trouver mise à jour à l’emplacement habituel.

Les principales améliorations concernent l’ajout de commandes pour l’utilisation de sprites.

Pour l’instant, aucune optimisation n’a été faite mais j’espère pouvoir optimiser le rendu des sprites pour une future version du moteur de création de jeux.

La liste des modifications apportées depuis la version 0.3 se trouve dans « lire la suite… ».

Le moteur de création de jeux ‘AmiDARK Engine’ compte maintenant plus de 450 commandes et fonctions utilisateur.

N’oubliez pas de régulièrement jeter un oeil sur le journal de développement pour savoir quelles fonctionalités seront rajoutées dans la prochaine version.

Si vous désirez soutenir le projet, vous pouvez faire une donation ici : http://www.amidark-engine.com/spip.php?article3

Have fun.

Sincèrement,
AmiDARK

Site internet : http://www.amidark-engine.comVoici la liste des améliorations de cette version en comparaison avec la version précédente 0.3 :

2011.03.31 :
————
SPRITES
– Ajout des commandes : DESetSpriteImage( SpriteID, ImageID )
– Ajout des fonctions : =DESpriteScaleX( SpriteID ), =DESpriteScaleY( SpriteID ), =DESpriteWidth( SpriteID ), = DESpriteHeight( SpriteID )

2011.03.30 :
————
SPRITES
– out des commandes : DEFlipSprite( SpriteID ), DEMirrorSprite( SpriteID )
– Toutes les librairies du moteur ont été restructurées.

2011.03.21 :
————
SPRITES
– out des commandes : DEHideSprite( SpriteID ), DEShowSprite( SpriteID ), DEHideAllSprites(), DEShowAllSprites()

2011.03.20 :
————
SPRITES
– out des commandes : DEPositionSprite( SpriteID, X, Y ), DESetSpriteX( SpriteID, X ) & DESetSpriteY( SpriteID, Y )

2011.03.18 :
————
SPRITES
-Vérification et fixs du rendu : Les sprites sont maintenant affichés correctement avec une fonction de « paste image » type.

2011.03.12 :
————
SPRITES
– out des commandes : DESetSpritePriority( SpriteID )
– Refonte du principe de gestion des priorités d’affichage des sprites
– Début de développement du support du rendu graphique des sprites.
– Support des backbuffers de sprites terminé.
– Support interne des priorités d’affichage terminé.

2011.01.29 :
————
SPRITES
– Début du développement des priorités d’affichage des sprites.

2011.01.17 :
————
SPRITES
– Début du développement du support de bitmaps des sprites.
SYSTEM
– Ajout de 11 fonctions sur les futures checklists.

2010.11.28 :
————
MAIN ENGINE
– Refonte du fichier « libamidark.h » pour inclure séparément les plugins et activer les modules 3D si demandé.
– Mise à jour des fonctions de synchro pour prendre en compte les 2 versions du moteur de création de jeu.
– Version 2D du fichier libAmiDARK.h terminée.
– Ajout des commandes : DECurveValue, DENewXValue, DENewYValue, DENewZValue & DECurveAngle.
– La caméra 0 par défaut n’est activée que si un objet 3D est crée.
CORE
– Ajout dans le setup la détection d’objets 3D pour activer la caméra par défaut (compatibilité avec DarkBASIC Professional)

29 Commentaires

Passer au formulaire de commentaire

    • sur 6 avril 2011 à 22h58

    Je suis très content de l’avancement de se projet, et j’ai énormément d’espérance en se langage.

    Il peut m’aider dans mes futures projets (long à venir mais continuel) de jeux pour AOS

    • Tarzin sur 7 avril 2011 à 9h03

    Vais tester ça dès que possible également.

    Les démos vues à l’Alchimie m’avaient emballées!

  1. Dommage, je n’ai plus de machine OS4-capable… mais je suis heureux de voir que tu avances dans ton projet ! Ce que j’en avais vu à la µAlchimie m’avait bluffé et on ne peut que se réjouir de voir un tel projet continuer !


    /me espère que l’AmiDARK Engine ira loin (et ira sur MorphOS, on ne sait jamais ^^).

    • sur 7 avril 2011 à 12h10

    @Batteman:

    Tiens, sa c’est une bonne interrogation, c’est facile de porter un programme C sous AOS vers Morphos et inversement? car si je me mets au C grâce à l’Amidark Engine, j’aimerais quand même que nos ami(e)s morphosiens profite de mes petites routines 😉

    • elwood sur 7 avril 2011 à 12h19

    il n’y a rien de facile mais rien d’impossible 😉

    • Tarzin sur 7 avril 2011 à 12h33

    Mode troll ON
    Heureusement que j’ai acheté une SAM avec OS4 pour l’essayer! 😉
    Mode troll OFF

  2. Tarzin : Espèce de troll des cavernes ! 😉

    En fait, j’avais un Pegasos II avant (avec AmigaOS 4 et MorphOS dessus) mais quand ce dernier est tombé en rade, je ne me voyais pas prendre une Sam et perdre du coup le système que j’utilisais à 95%… car oui, je n’utilisais pas OS4 plus que ça puisqu’il ne gérait pas ma carte Radeon 8500 et que je n’avais pas envie du tout de repasser à une 9250…

    Et je dois t’avouer que ça me fait un peu suer… mais bon, face à un PMac à 1,8 GHz dans lequel j’ai pu remettre toutes mes cartes, le tout pour 250 EUR, rien ne faisait vraiment le poids (c’est le cas de le dire, vu le poids de la bestiole ! ^^).

    Maintenant, je vais voir si j’aurais l’occasion de rechoper une machine OS4 compatible, mais bon, j’y crois pas de trop…

    Donc, ça m’embête de ne pas voir AmiDARK Engine (pour le moment ^^) sur MorphOS ^^


    /me ne prêche définitivement pas pour MorphOS mais pour… « sa gueule » ^^

    • AmiDARK sur 7 avril 2011 à 15h18
      Auteur

    J’ai réuploadé une nouvelle version avec les exécutable des démos qui manquaient dans le 1er upload.
    Lien alternatif de cette nouvelle version : http://files.amidark-engine.com/AmiDARKEngine_r04pub.lha

    Concernant MorphOS … Le problème ne se pose pas pour moi .. Je n’ai pas de machine MorphOS … Et je n’ai pas les finances pour en acheter une … Donc pour MorphOS … Désolé mais c’est pas pour demain …

    @+
    AmiDARK

  3. AmiDARK : Après-demain alors ! ^^ Courage, continue ton AmiDARK Engine, le reste viendra si ça doit venir ^^


    /me émettait juste un souhait, rien de plus. Et /me soutient AmiDARK dans son développement ! Keep uo the good work ! ^^

    • sur 7 avril 2011 à 16h42

    T’es une bête mon garçon, comme d’hab….

    • henes sur 7 avril 2011 à 18h32

    Tiens, sa c’est une bonne interrogation, c’est facile de porter un programme C sous AOS vers Morphos et inversement?

    Puisqu’il s’agit du même OS, porter un programme 100% écrit en C est très simple.
    Les seules choses à adapter sont causées par le changement de processeur (un tag supplémentaire à utiliser lorsque l’on crée une tâche, ce genre de choses). Je parle en général de recompilation plutôt que de portage…

    D’expérience, il ne faut pas plus de quelques heures pour porter un programme. Quelque soit sa taille ou sa complexité. Un peu plus s’il faut adapter des bibliothèques partagées.

    Les véritables problèmes pour les débutants sont plutôt causés par le changement de compilateur (aztec/sasc/dice… remplacés par gcc/vbcc), le code écrit n’importe comment et qui « fonctionnait » un peu par hasard jusqu’ici… et le fait qu’un débutant ne comprend pas forcément bien ce qu’il fait et les messages d’erreur qui surgissent…
    Mais surtout, on parle souvent de porter un programme écrit par quelqu’un d’autre… et dont les sources sont une énigme qui doit être résolue 🙂

  4. @henes
    Je pense qu’Artblink parlait surtout d’AOS4 vers MOS et vice-versa, auquel cas les problèmes qui peuvent surgir viennent surtout des nouvelles fonctions et moins des SDK vu que c’est GCC des 2 côtés.

    Dans ce cas, il vaut mieux écrire du code compatible OS3.1, cela demandera encore moins de travail pour le recompiler sur les 2 autres.

    • AmiDARK sur 7 avril 2011 à 20h10
      Auteur

    Dans ce cas, il vaut mieux écrire du code compatible OS3.1, cela demandera encore moins de travail pour le recompiler sur les 2 autres.

    Oui mais dans mon cas c’est pas applicable car sinon … bye nye MiniGL :p MDR

    • sur 7 avril 2011 à 20h24

    Ok, mais sa va être dur de porter mes bidouilles sur morphos du fait que si j’utilise l’amidark engine, les commandes sont inexistante pour le GCC de morphos (n’oublier pas que j’y connais rien en C).

    Passer par le 3.1 se serai dommage, car j’exploite (a mon avis) rien, en fait, je veux exploiter les bécanes (surtout le peg2 et la sam 460, 2 bécanes que j’adore, je sais c’est con, j’ai pas encore de sam460, mais je l’aime déjà).

    Bon, de toute façon l’amidark n’est pas encore la, je me suis replonger sur le C ansi (qui est en faites très simple, c’est juste la déclaration de variable qui est fastidieuse et qui me fais un peux suer), mais j’abandonne pas mes projets holly 😉

    J’aimerai bien faire des bidouilles pour accélérer les cmd de hollywood en passant par des commandes C… mais est-ce possible… peut être en passant par des ports Arexx, d’ailleurs, Arexx existe bien sur AOS 4.X et Morphos? si non, pas la peine que je continue a me casser la tête à chercher

  5. @AmiDark

    Oui mais dans mon cas c’est pas applicable car sinon … bye nye MiniGL :p MDR

    Pas forcément, j’imagine que MiniGL et TinyGL implémentent plus ou moins le même sous-ensemble de fonctions OpenGL.

    • henes sur 8 avril 2011 à 20h23

    Le SDK de tinygl.library contient même un wrapper de l’API de MiniGL, c’est à dire les appels mgl_#?, pour « porter » des trucs par simple recompilation (cf plus haut:)

    • AmiDARK sur 8 avril 2011 à 20h45
      Auteur

    Intéressant …
    Mais en même temps … je n’ai plus de machines OS 3.x … Et utiliser WinUAE .. Bof :p
    Pour l’instant je vais me concentrer sur AmigaOS4 … On verra + tard pour d’autres OS Amiga.

    • sur 9 avril 2011 à 10h46

    Il y a des commandes en moins sur tinyGL comparait à miniGL?

    • AmiDARK sur 9 avril 2011 à 12h00
      Auteur

    Déjà que sur MiniGL il y a plein de choses que je ne peux pas faire ….

    • henes sur 9 avril 2011 à 12h53

    @artblink

    Historiquement, c’était plutôt l’inverse : tinygl.library avait beaucoup plus de fonctionnalités que minigl. Mais, au vu du changelog de minigl 2.x, cela semble moins vrai aujourd’hui.

    cf http://3d.morphos-team.net/ et http://hdrlab.org.nz/projects/amiga-os-4-projects/minigl/ pour se faire une première idée… à condition de connaître OpenGL un minimum 🙂

    @freddix

    Choses que tu pourrais faire avec un OpenGL plus complet ? Aurais-tu un exemple ?

    • AmiDARK sur 10 avril 2011 à 0h54
      Auteur

    un Exemple ?
    Simplement les shaders …. du cell shading, du bloom, etc … Bon après, faut que les cartes graphiques le supportent … mais plein de choses qu’il y a dans DarkBASIC Professional et que je ne pourrais pas adapter à l’AmiDARK Engine …
    Il y a aussi certaines fonctionalités comme le glReadPixels, glCopyPixels qui sont très lents … Même si tu fait une capture de texture directe en mémoire vidéo ça rame dur … Alors que ça devrait moins … Alors gérer des « sprites » ala « old skool » c’est plus lent que Amiga 1200 :p lol
    Bon ça empêchera pas l’AmiDARK Engine d’être un outil pour créer des jeux sur Amiga OS 4 … Mais c’est vrai que ça gâche un peu le plaisir …

    • sur 10 avril 2011 à 8h49

    Merci henes, mais j’y connais rien en opengl… j’arrive pas à tous comprendre (en plus c’est en anglais)

    J’ai trouvai sa sur internet, sa convient pour AOS et Morphos (pour déjà comprendre les bases)?

    http://www.siteduzero.com/tutoriel-3-5014-creez-des-programmes-en-3d-avec-opengl.html

    Je peut acheter se livre pour apprendre le C pour développer par la suite sur AOS et Morphos ?

    http://www.siteduzero.com/boutique-614-65-apprenez-a-programmer-en-c.html

    • henes sur 10 avril 2011 à 15h04

    @freddix

    Ok pour les shaders. Par contre, le cell shading est tout à fait possible sur Amiga. J’ai même un quake en cell shading 🙂

    Enfin, il est normal que glReadPixels() soit lent. Lire en mémoire vidéo est obsolète depuis vraiment très longtemps. Cela tue le parallélisme, les caches et oblige à convertir le buffer.

    @artblink

    J’ai rapidement regardé tes deux liens.

    Le premier apprend à utiliser glVertex() pour faire du code qui rame à mort. Et ne parle pas des vertex arrays, vbo etc… C’est souvent le cas dans ce genre de tutorial et il y a sans doute quand même plein de choses à en retirer… mais cela reste dommage. Surtout qu’il n’est pas forcément aisé de passer d’une technique à l’autre ensuite. Alors autant tout de suite apprendre la bonne.

    Idée : glVertex() ayant été retiré d’OpenGL ES, les articles concernant l’iphone doivent être d’un meilleur niveau.

    Quand au bouquin qui apprend le C à travers l’usage de SDL… pourquoi pas. J’ai cependant relevé pas mal de bugs dans les exemples (retour de fonction non vérifié…) et il t’apprend à faire du son à travers « fmod » qui n’existe pas sur Amiga.
    Mais, encore une fois, il y a sans doute plein de choses à garder.

    • sur 10 avril 2011 à 16h05

    Merci de me donner un peu de ton temps, dommage qu’il n’y ai pas de cours C pour AOS/Morphos en francais…

    Bon, d’abord, il faut que je maîtrise le C ansi, ensuite, apprendre les fonctions spécifiques au 2 OS a mon avis se fera au fur et a mesure que je bidouillerai, je mettrais mes sources sur le forum comme ceux d’hollywood.

    J’essai de terminer mon supercars au plus vite pour passer sérieusement au C, avec le jeu, il y aura la source évidement.

    Par contre, pas le temps de faire un tuto, il y aura un peu de commentaire, mais se sera pas l’extase.

    J’arrive a faire, mais j’ai beaucoup de mal à m’expliqué clairement, c’est l’un de mes nombreux gros défauts 😉

    • AmiDARK sur 10 avril 2011 à 16h31
      Auteur

    @Hénès :
    Oui le cell existe mais c’est pas un cell shading en shaders … C’est une bidouille … Il y a d’ailleurs dans les exemples/démos de MiniGL un exemple qui montre la bidouille pour faire croire à l’effet … mais aucun shader …
    pour les pixels, je voulais parler de ça : glCopyTexImage2D : http://www.opengl.org/sdk/docs/man/xhtml/glCopyTexImage2D.xml
    Car ça permet de faire de la capture de rendu de caméra pour application sur textures :p
    Je pense qu’il doit y avoir moyen de directement faire un rendu vers un buffer mémoire mais pas encore vraiment cerné la possibilité sous AmigaOS 4 … MiniGL ayant beaucoup de commandes manquantes par rapport à OpenGL 2.1

    @Artblink :
    pour le C : An Introduction to AMIGA Programming Using C : http://www.liquido2.com/tutorial/index.html

    Documentation OpenGL 2.1 : http://www.opengl.org/sdk/docs/man/
    (attention MiniGL correspond à l’OpenGL 1.5 donc pas toutes les commandes sont dispos) C’est ce que j’utilise en référence … C’est en Anglais mais pas trop mal
    OpenGLProgramming Guide : http://glprogramming.com/red/index.html
    Neon Helium Productions OpenGL Tutorials : http://nehe.gamedev.net/
    Jouyvieje Tutorials OpenGL : http://jerome.jouvie.free.fr/index.php

    Après j’ai aussi des exemples en OpenGL mais cela je peux pas les diffuser (achetés).

    Sinon si tu as mon MSN on peut en discuter de OpenGL sur AmigaOS4 😉

    @ +
    AmiDARK

    • sur 10 avril 2011 à 22h41

    @Ami Amidark:

    J’ai pas ton MSN snif…

    Edit: Excuse… merci pour les liens 😉

    • AmiDARK sur 11 avril 2011 à 12h33
      Auteur

    Artblink …. rectifié …..
    AmiDARK …. Jeux ….
    …….. Rectifié ….

    • henes sur 12 avril 2011 à 20h17

    Oui le cell existe mais c’est pas un cell shading en shaders … C’est une bidouille … Il y a d’ailleurs dans les exemples/démos de MiniGL un exemple qui montre la bidouille pour faire croire à l’effet … mais aucun shader …

    Je ne comprend pas vraiment de quoi tu parles…
    Dans tous les cas, même si je crois qu’il n’était que le deuxième jeu de l’histoire en cel shading, Jet Set Radio a popularisé ce type de rendu sur la Dreamcast, machine sans shaders progammables. Un autre exemple de très beau cel shading pourrait être Zelda sur Gamecube, autre machine sans shaders progammables…

    Tes propres liens montrent comment faire du cel shading avec de simple triangles et lignes : voir la leçon 37 de nehe…
    Après, je ne doute pas qu’il soit possible d’utiliser les shaders pour encore améliorer le rendu… mais c’est valable pour l’ensemble des effets 3D existant. 🙂

    Bref, sans doute une incompréhension quelque part. Techniquement, il n’y a strictement jamais rien eu qui puisse empêcher de faire du beau cel shading sur Amiga…

    • AmiDARK sur 12 avril 2011 à 22h52
      Auteur

    voila un rendu via SHADER :
    http://files.amidark-engine.com/Shading.png
    Sans Shaders c’est plus dur d’avoir ce genre de rendu …

Les commentaires sont désactivés.

Amiga Impact