La console fait pas la différence entre 1 ou 380 sprites actifs, elle fait toujours le rendu à la même vitesse. Ce qui peut la faire ramer, c'est le temps de calculer toutes les positions si ils sont animés.
380 sprites c'est le nombre pour lequel le système vidéo a été fait, si on veut en afficher plus, va y avoir des lignes horizontales qui vont commencer à ne plus être dessinées. J'essaye de finir un exemple avec 190 sprites de 2x2 tiles ce soir juste histoire de montrer que ça rame pas même avec l'écran rempli.
La console fait pas la différence entre 1 ou 380 sprites actifs, elle fait toujours le rendu à la même vitesse. Ce qui peut la faire ramer, c'est le temps de calculer toutes les positions si ils sont animés.
effectivement, si en plus la console doit calculer toutes les combinaisons des collisions possibles elle risque d'être à genoux. Dans ce cas l'émulateur serait à genoux comme la console ou pas ?
Au fait penses tu continuer ta cartouche de dev, si j'ai bien compris pour l'instant tu ne peux charger que le P1 c'est ca ?
Je ne te cache pas qu'a terme, le kiff total serait de voir une autruche lanceuse de missile sur ma borne à la maison
Je suis un quiche en électronique mais bon avec un plan je peux souder et programmer des chips.
La devcart est laissée de côté pour l'instant, je veux d'abord (bien) finir le câble pour ngcd puisque c'est moins cher et plus pratique. Faire une cartouche en dur pour ton jeu poserait pas trop de problèmes, ça se joue au prix du circuit, du plastique et des EEPROMs 16bit. L'électronique elle même c'est rien que du routage et quelques condensateurs.
Si tu veux une estimation du prix pour une très petite série, je dirais 50€ par cartouche hors coque.
Neodev voit les sprites comme des blocs dont on fixe la taille alors ? Parce que pour la console, ça reste un assemblage des fameuses bandes de 16 pixels, quelle que soit la largeur de "l'objet" qu'on en fait. Et c'est le nombre de ces choses là qui compte. Par ex., truc de 64x64 pixels qui bouge: 4 sprites, obligé.
Aussi j'ai entendu parler d'une technique utilisée par beaucoup de moteurs de jeux 2D, c'est une sorte de stack pour les sprites. Si le moteur du jeu a besoin d'un nouveau sprite, il regarde si la pile est pleine, si elle l'est pas il le met tout en haut, si elle l'est, il le met en attente. Quand un sprite sert plus, il est sorti de la pile et elle est décalée pour boucher le trou. Le moteur réorganise tout à chaque image selon les nécessités pour être sûr d'utiliser tous les sprites possibles, mais pour le joueur ça se voit pas
(bon ben j'ai pas fini de découper les knaki ball pour l'exemple)
Dernière modification par ftek, 25 février 2010, 22h34.
La devcart est laissée de côté pour l'instant, je veux d'abord (bien) finir le câble pour ngcd puisque c'est moins cher et plus pratique. Faire une cartouche en dur pour ton jeu poserait pas trop de problèmes, ça se joue au prix du circuit, du plastique et des EEPROMs 16bit. L'électronique elle même c'est rien que du routage et quelques condensateurs.
Si tu veux une estimation du prix pour une très petite série, je dirais 50€ par cartouche hors coque.
Je pensais à plus cher que ca, avec une telle cartouche, j'investis tout de suite dans un programmeur.
Neodev voit les sprites comme des blocs dont on fixe la taille alors ? Parce que pour la console, ça reste un assemblage des fameuses bandes de 16 pixels, quelle que soit la largeur de "l'objet" qu'on en fait. Et c'est le nombre de ces choses là qui compte. Par ex., truc de 64x64 pixels qui bouge: 4 sprites, obligé.
Oui, c'est exactement ca, qu'il fasse 64x64 ou 64x256, il occupera 4 "emplacements" dans les 0-383 dispo.
Aussi j'ai entendu parler d'une technique utilisée par beaucoup de moteurs de jeux 2D, c'est une sorte de stack pour les sprites. Si le moteur du jeu a besoin d'un nouveau sprite, il regarde si la pile est pleine, si elle l'est pas il le met tout en haut, si elle l'est, il le met en attente. Quand un sprite sert plus, il est sorti de la pile et elle est décalée pour boucher le trou. Le moteur réorganise tout à chaque image selon les nécessités pour être sûr d'utiliser tous les sprites possibles, mais pour le joueur ça se voit pas
C'est ce que j'ai rajouté à neodev par l'intermédiaire des fonctions suivantes:
int sprites_bank[384];
/* initialisation de la banque de sprite */
void init_sprite_bank(void);
/* récupère un emplacement libre de taille 'size'(pour un srpite de 16pixels size=1, 32pixels size=2) */
int get_sprite_bank_free(int size);
/* Réserve 'size' emplacement dans la banque à partir de 'start' */
void fill_sprite_bank(int start, int size) ;
/* Libère 'size' emplacement dans la banque à partir de 'start' */
void free_sprite_bank(int start, int size) ;
Commentaire