Salut à tous,

Bon, j'ai bien avancé sur le nouveau système de rendu que je nommerai : "Advanced Render Method" qui fonctionne maintenant *parfaitement* :)
J'ai aussi terminé le support de "Plugins Additionnels" (qu'on nomme souvent TPC ( Third Party Commands) ).
Cela m'a permit d'améliorer pas mal de choses dans l'AmiDARK Engine et aussi d'en optimiser quelques unes.

Le rendu à l'écran se faisait auparavant avec une fonction principale dans laquelle étaient appelées les diverses fonctions de rendu (Images, Basic2D, Basic3D, Sprites, Textes, RasterFX, etc...) dans un ordre précis avec seule possibilité c'est de basculer les priorités de SPRITES Vs 3D et d'IMAGES Vs 3D.
Tout ce système fonctionnait mais n'était pas vraiment ... *optimisé*...

Maintenant avec la nouvelle méthode de rendu avancé, chaque module s'il est utilisé, est inclut à la compilation et, sa fonction d'initialisation demandera à l'ARM (Advanced Render Method) d'ajouter sa fonction de rendu dans la fonction principale d'affichage (Synchro à l'écran).

Cela signifie plusieurs choses :
1. Si un module n'est pas utilisé, il ne sera pas inclut à la compilation et donc, sa fonction ne sera pas incluse dans le rendu final = Réduction de la mémoire utilisée sur disque et en mémoire RAM + Optimisation permettant de gagner un petit peu de vitesse dans le rafra?chissement du rendu final à l'écran.
2. De nouveaux modules/plugins peuvent être crées et avoir leur propre fonction de rendu pour s'intégrer dans le moteur de Jeu "AmiDARK Engine".
L'ARM gère aussi les priorités. Cela signifie que l'on peut modifier la priorité d'affichage.
3. Le développeur utilisant l'AmiDARK Engine pourra lui aussi créer des fonctions de rendu supplémentaires selon ses besoins.
(Une fonction de rendu n'est pas forcément graphique)

Par exemple, en ordre normal on devrait avoir 3D puis IMAGES puis SPRITES pour que la 2D s'affiche devant la 3D et que les sprites (dont le background est sauvegardé puis restauré après l'affichage à l'écran) soient dessus la 3D et les Images, mais on peux modifier cet ordre imaginons par exemple pour un jeu en 2D devant lequel on ferait bouger un objet 3D ... On peux mélanger dans n'importe quel sens ... Par exemple : IMAGES, 3D, SPRITES ou 3D, SPRITES, IMAGES, etc ... tout est paramétrable selon le besoin ... On commence avec tout cela à sortir du cadre de la "compatibilité" avec DarkBASIC Professional & DarkGDK.

Pour cela j'ai du aussi ajouter quelques fonctions internes pour les *futurs* développeurs de plugins/modules (et donc pour moi même dans le développement de l'AmiDARK Engine).

Ces fonctions ont pour but principal de permettre de basculer plus rapidement dans des modes d'affichages 2D, 3D ou CUSTOM.
Une fonction de rendu d'un module/plugin devra d'abord donc annoncer dans quel mode elle veut fonctionner :
1. Mode 2D : Cela mettra les valeurs d'OpenGL en mode permettant d'afficher des images 2D sur toute l'étendue de la fenêtre de l'application.
2. Mode 3D : Cela mettra les valeurs d'OpenGL en mode permettant d'afficher des images 3D sur toute l'étendue de la fenêtre de l'application.
3. Mode Custom : Cela mettra les valeurs d'OpenGL en valeurs initiales. Le module/Plugin pourra donc utiliser l'OpenGL pour définir ses propres propriétés de rendu.

Ces 3 modes de rendu ne tiennent pas compte des définitions de Caméra 3D du moteur. Lorsque l'on ajoute une fonction de rendu, elle ne pourra pas interférer à l'intérieur d'une autre fonction de rendu. Bien entendu des checkings ont été faits pour éviter des appels *inutiles* à l'OpenGL.

Je prévois aussi des optimisations et améliorations du moteur AmiDARK Engine qui n'existent pas dans DarkBASIC Professional ni dans DarkGDK.
(genre permettre de réaliser le rendu d'1 objet par 1, d'1 sprite par 1 pour contrôler très rapidement ce que l'on veut à l'écran sans avoir à utiliser plein de "Hide Object" ou autre ...)
Bien entendu tout ce que je viens de vous détailler ci-dessus n'existe pas non plus dans DarkBASIC Professional ni dans DarkGDK.

Ces optimisations et améliorations ne devraient pas réduire la potentielle compatibilité et portabilité depuis DarkBASIC Professional & DarkGDK cela dit, utiliser ces nouvelles commandes rendra "incompatible" un portage d'une application développée avec l'AmiDARK Engine vers DarkBASIC Professional ou DarkGDK.
Cela dit, je pense que ces ajouts et optimisations permettront à l'AmiDARK Engine d'étendre les capacités à bien plus que des jeux (des démos 3D par exemple :p, les Demo Maker devraient apprécier).
Et, il est primordial maintenant que l'AmiDARK Engine devienne réellement un moteur de création de Jeux Vidéo adapté à nos Amiga ... Et celà bien au delà de la simple compatibilité avec DarkBASIC Professional & DarkGDK.

La version 0.9 devrait bientôt être disponible avec toutes ces nouveautés et probablement quelques petites surprises en plus :)

@+
AmiDARK
Message édité par : AmiDARK / 23-11-2013 15:40
Message édité par : AmiDARK / 23-11-2013 15:41

Pas mal dis donc

à quand une version de tests?

Je corrige le petit soucis d'image et de textures, je refais les exemples et j'envoie une démo ... D'ici la fin de la semaine prochaine je pense :p

Ca sent bon :-P

Tu veux une API AMidark engine.... j'suis chaud là lol

Non, mais pas avec RxMui, il a du mal sous AOS4.... j'ai commencé à utiliser MuiRoyale depuis 3/4 mois et ça fonctionne nickel, pas d'erreur, pas de problème particulier, par contre, une API créé sous MuiRoyale, c'est du lourd :-(


En gros, inutilisable sous 6800x0... beurk! mais bon, au moins il y aura un truc... :-(

Artblink : Je dois avouer que je comprends pas ce que tu veux dire ...

Normal... t'es nul PTDR


Je parler d'un API style MHE dédié à l'Amidark (comme ça tu t'occupe de ton langage) mais je le fait avec MuiRoyale (Hollywood) mais ça va ramer à mort sur 6800x0+CGFX


T'as compris mon kiki?

:=!

Oui je comprends.

Le terme exact serait plutôt un "Wrapper de fonctions" pour les rendre disponible depuis Hollywood.
Seul soucis c'est que l'AmiDARK Engine ne fonctionne pas sur 680x0 ... Uniquement sur AmigaOS4.1 et MorphOS ...
Donc tu risques de le faire pour pas grande chose ...

Citation : AmiDARK?
"Advanced Render Method"

Plutôt : Rendering Method

Citation : AmiDARK?
chaque module s'il est utilisé, est inclut à la compilation et, sa fonction d'initialisation demandera à l'ARM (Advanced Render Method) d'ajouter sa fonction de rendu dans la fonction principale d'affichage (Synchro à l'écran).

Cooool ! :-)

Citation : AmiDARK?
On commence avec tout cela à sortir du cadre de la "compatibilité" avec DarkBASIC Professional & DarkGDK.

J'ai comme l'impression que tu veux montrer aux développeurs de la version PC que tu peux mieux faire. Et je trouve que c'est bien parti :-) Continue comme ça.

Message édité par : Elwood / 23-11-2013 23:54

Citation : Elwood?
J'ai comme l'impression que tu veux montrer aux développeurs de la version PC que tu peux mieux faire. Et je trouve que c'est bien parti :-) Continue comme ça.

Lool.
Ce n'est pas exactement cela... Mais il y a de l'idée :p
Disons que je commence à avoir une autre vision de mon projet...
(Maintenant que ma santé commence à s'améliorer, mon mental commence à retrouver la forme lui aussi et à émettre des idées :p)

C'est on dirait un peu "sortir de l'ombre" de l'original (DarkBASIC Professional / DarkGDK) grâce auquel j'ai pas mal appris (pour structurer l'AmiDARK Engine) et ce pour que l'AmiDARK Engine devienne un logiciel "à part entière".
Il conservera "autant que faire se pourra" la compatibilité avec DarkBASIC Professionnal & DarkGDK.
Mais pour que l'AmiDARK Engine soit "l'AmiDARK Engine" il va falloir qu'il ait ses propres cartes à montrer ;)
(Ainsi il ne sera plus réellement une sorte de "Port from scratch" (Portage repris à 0) mais réellement un produit *purement Amiga* et avec en bonus, le fait d'être compatible "DarkBASIC Pro/DarkGDK")

Voila ma pensée actuelle ;)
Message édité par : AmiDARK / 24-11-2013 00:06