| Amiga Impact

  · Accueil
  · Actualités
   · Proposer une info
  · Agenda
   · Proposer une date
  · Articles
  · Forum
  · Petites Annonces
  · Chat IRC
  · À propos du site



 | Connexion

Identifiant :

Mot de passe :

 Mémoriser

  · Inscription
  · Mot de passe oublié



 | En ligne

Illustration du profil de pat55400 Illustration du profil de barroso Illustration du profil de wario17 Illustration du profil de SKYNET Illustration du profil de Tempus Illustration du profil de lolof Illustration du profil de mlanie70 Illustration du profil de zogobille Illustration du profil de crown




 | Nous suivre

Flux RSSGoogle+TwitterFacebook





Actualités


   AmiDARK Engine – Alpha Release 0.4 *publique*
   | 6 avril 2011 | Logiciels,

programmation

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)




Les commentaires appartiennent à leurs auteurs.
Nous ne sommes pas responsables de leur contenu.


Auteur Conversation
Artblink Posté le 6 avril 2011



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 Posté le 7 avril 2011



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

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



BatteMan Posté le 7 avril 2011



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 ^^).



Artblink Posté le 7 avril 2011



@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 Posté le 7 avril 2011



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



tarzin Posté le 7 avril 2011



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



BatteMan Posté le 7 avril 2011



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 Posté le 7 avril 2011



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



BatteMan Posté le 7 avril 2011



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 ! ^^



hivernaal Posté le 7 avril 2011



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



henes Posté le 7 avril 2011



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 🙂



centaurz Posté le 7 avril 2011



@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 Posté le 7 avril 2011



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



Artblink Posté le 7 avril 2011



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



centaurz Posté le 8 avril 2011



@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 Posté le 8 avril 2011



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 Posté le 8 avril 2011



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.



Artblink Posté le 9 avril 2011



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



AmiDARK Posté le 9 avril 2011



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



henes Posté le 9 avril 2011



@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 Posté le 10 avril 2011



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 …



Artblink Posté le 10 avril 2011



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 Posté le 10 avril 2011



@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.



Artblink Posté le 10 avril 2011



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 Posté le 10 avril 2011



@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



Artblink Posté le 10 avril 2011



@Ami Amidark:

J’ai pas ton MSN snif…

Edit: Excuse… merci pour les liens 😉



AmiDARK Posté le 11 avril 2011



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



henes Posté le 12 avril 2011



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 Posté le 12 avril 2011



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








Haut de page 

Copyright © 2004-2018 Amiga Impact. Tous droits réservés. Les marques citées sont déposées par leurs propriétaires respectifs.
Conditions d'Utilisation, Politique de Confidentialité et Information sur les cookies.


Fil RSS WordPressNicolas Gressard, Conseil et développement informatique

Do NOT follow this link or you will be banned from the site!