Faire du flash avec la méthode portable

J'essaye cette technique

- l'actionscript sert uniquement à programmer la partie graphique
- le coeur du jeu est programmé en c++ et compilé avec alchemy

Quel intérêt de travailler comme ça ? Hé bien l'avantage d'avoir un moteur en c++ c'est qu'il est portable, et qu'on peut en faire une jolie version windows en fullcreen sans saccades et avec plein d'effets graphiques que flash sait pas faire, une version mac, et plein de versions smartphone

Donc en fait le jeu est entièrement développé sur directx au départ et ensuite on adapte à d'autres environnements de programmation graphique, car c'est le truc qui change sur toutes les machines.

Bref c'est une approche plus intelligente que d'être enfermé dans le merdier moisi d'adobe.

Autres avantages: c'est plus intelligent pour se vendre en tant que gamedev de faire du c++ que de l'actionscript, vu que le marché du jv c'est surtout les mobiles, les consoles et les cd, le flash représente pas grand chose

Ha et puis autre avantage énorme, coder le gameplay en c+ permet de faire de l'alloc / dealloc, chose impossible en actionscript et ça c'est vraiment bien pourri et insupportable

Bref tout gagnant.

Le problème logique que je cherche à résoudre est le suivant:

Comment faire communiquer un composant alchemy avec les fonctions graphiques de flash

On ne peut pas appeler les méthodes graphiques de flash depuis le composant codé en c++, il faut donc fournir à flash des instructions qu'il va appliquer à son moteur graphique.

La seule façon de procéder est d'accéder au byteArray de la ram du composant alchemy.

il faut donc trouver des techniques pour coder les instructions graphiques en bytecode de la façon la plus simple possible...

je vous propose de proposer des pistes

histoire de partir sur un exemple facile, quelles instructions faudrait-il faire passer pour programmer un jeu de PONG ^^

bon heu désolé c'était de la m[...]e mon exemple... :lol:

pour un pong il suffit d'encoder trois integer pour définir les coordonnées des deux objets donc c'était nul comme exemple (et puis compiler trois lignes de c++ c'est également profondément inintéressant)

Bon, je repars sur un exemple pro:

J'affiche:
-deux calques de tile-layers. l'arrière-plan ne scrolle que sur X est est animé sur 3 frames, le premier plan n'est pas animé mais il scrolle sur X et Y
-16 petits sprites
-16 gros sprites.

Comment j'explique ça à flash avec un bytecode le plus simple possible ?

Bon puisque tout le monde s'en fout je me réponds à moi-même:

La solution la plus con consisterait à coder un moteur graphique "software" entièrement géré par le microprocesseur, qui trace l'ecran pixel par pixel, et puis ensuite il suffit de balancer le tableau de pixels dans flash.

C'est une solution intéressante pour faire du gros pixel oldschool mais c'est pas optimisé du tout, on ne profite pas du gpu côté version windows, ni du natif côté version flash. et en plus c'est inefficace au possible parce qu'on a pas forcément que ça à foutre de coder un moteur graphique de a à z

Voilà donc une approche possible:

- pour les deux tableaux de sprites, une série de 8 entiers pour chaque sprite: x,y,colonne,rangée,flipX,flipY,indexEffet,indexPalette

jusque là c'est facile, c'est pour les tile layers que ça va se compliquer

- d'abord les coordonnées x/y pour chaque calque, ainsi qu'indexEffet et indexPalette, là ça reste encore simple

là où ça se complique c'est pour mettre à jour les tuiles. on ne peut pas prévoir à l'avance quelles tuiles vont être ajournées ou pas.

c'est un peu à chacun sa cuisine, là je vais proposer une approche qui permet une consommation processeur constante.

on limite la vitesse de scroll à la largeur des tuiles. en vitesse max on va mettre à jour une rangée et une colonne sur le premier plan, et une colonne sur l'arrière-plan

je vais donc reserver dans ma ram alchemy une liste d'index de tuiles pour l'arrière-plan, et deux listes pour le premier-plan


voilà voilà

la communication alchemy->flash est donc gérée en lisant une quantité de nombres relativement petite

prochaine étape, comment appliquer ça au moteur 3d, héhéhé

Arf arf arf. Grosse erreur de ma part dans le post précédent,

j'ai raisonné de façon un peu trop "roots" comme dans les très vieux jeux où tous les gfx sont chargés en ram une bonne fois pour toutes (par exemple mario ou pacman)

donc j'ai oublié l'instruction qui permet de charger les tilesheets et spritesheets

je n'ai fait que décrire comment afficher les images dans la routine "ingame", par contre je n'ai pas encodé les instructions qui disent de charger les images...

bien donc, je reprends ma description du code:

- au tout début de ma ram alchemy j'utilise un octet qui va donner l'index d'état du programme. selon cet index une fonction différente sera appelée

pour la routine ingame que j'ai décrit plus haut on va utiliser par exemple l'index 1

pour la phase de chargement des images (appelée en général à chaque fois qu'on change de niveau) je code 4 index pour les deux tilesheet et les deux spritesheet à charger dans la mémoire vidéo

voilà

par ailleurs il y'avait une technique plus simple pour afficher les tiles que je n'ai pas évoquée. au lieu d'afficher des layers on affiche une image par tuile.
cette technique est plus facile à gérer:

- on crée un grand tableau de tuiles pour toute la map (je crée donc un nouvel index d'état qui va mettre à jour ce tableau au chargement du level et non pas au runtime)

- au runtime il n'y a plus qu'à donner la valeur X et Y du scrolling pour trouver les bonnes tuiles à afficher (avec copypixels ou bien avec des quads du moteur 3d)

cette technique est plus facile pour débuter l'affichage de tilemap mais elle consomme plus de cpu (surtout s'il y'a beaucoup de tuiles visibles)

Citation :

Bon puisque tout le monde s'en fout je me réponds à moi-même:

xD ! En faite je pense plutôt que personne n'a compris lol En tout cas pour ma part, y a des termes trop techniques du coup on se perd vite^^"

Je fais un petit rajout: la méthode que je cherche à tâtons ici est valable partout en réalité.

Les cartes graphiques modernes n'aiment pas du tout qu'on leur envoie trop de données au runtime, c'est pour ça que dans les jeux 3d on leur transmet le minimum d'informations en runtime:

- une bête "model ram", une suite de matrices avec index de vertexbuffer et texture pour rendre X objets
- si on met à jour des vertexbuffer (par exemple pour faire des trous dans un marching cube) c'est limité et local. pareil si on met à jour des textures avec le cpu pour intégrer une vidéo, faire des ombres cpu-processed, ou afficher un jeu 2d rétro gropixel comme le fait un émulateur, il faut que cette texture soit assez petite

ces règles sont valables pour n'importe quel environnement 3d, (y compris ceux de flash, director et unity)

bah en fait pour la 2d les règles sont identiques:
- une spriteram, une série de matrices 2d avec index de tile
- une mise à jour locale et limitée des tilelayers

cette technique était déjà valable sur les vieilles consoles 2d

de toutes façons dans les jeux modernes ces deux trucs sont rendus avec les mêmes méthodes que la 3d: les sprites sont rien d'autre que des models plats et les tiles sont faite avec des vertexbuffer comme une heightmap


et maintenant si le jeu est bien fait proprement, ce tampon d'informations minimalisées doit se trouver précisément entre la partie portable de votre jeu (le "coeur abstrait" qui gère toute la partie logique) et la partie non-portable (la librairie d'entrée ou user interface qui va connecter votre jeu à directx, à opengl, à marmalade, ou à alchemy pour flash) cela permet de faciliter le portage du jeu (moins il y'a d'infos à transmettre à la couche d'intégration et plus elle se code vite)

dans le cas de flash ce tampon d'informations minimalistes correspond précisément au tampon de bytecode alchemy. étant donné qu'il est assez lourdingue à lire ( il est 1,5 fois plus lent de lire dans un bytearray que dans un vector ) ça vous oblige à minimiser la quantité d'infos stockée dedans et donc à faire du boulot optimisé

voilà voilà