PolySnd - Page 13

Mais bien entendu..

Non seulement effacer une partie n'est pas élégante! mais en plus ca grossit l'executable, ce qui est contraire a tes principe non toi qui favorise toujours la taille face a la rapidité!

mon message va passer inapperçu, je le signale juste parceque je tiens à ce que Kevin y réponde

Bon je viens de réfléchir longuement au sujet et la méthode que j'utilise n'est pas une méthode de débutant car afficher seulement des zones peut s'avérer plus rapide que de tout réafficher car imaginé donc un jeux qui change très souvent de sprites de décors ou autre et ou il y a une multitude de sprites...

Je vais tester ma méthode en prenant pour juste l'affichage du décors, du niveaux et des billes plus collisions avec seulement l'écran en réaffichant la zone concernée et j'ai trouvé une autre méthode pour tout réafficher qui théoriquement semble plus rapide mais qui possède beaucoup de contrainte:

Au démarrage du programme j'affiche une matrice spéciale de décors avec des sprites de 16x16 ou 8x8 pour j'enregistre completement ce décors dans un buffer via spriteX8Get, de même pour le niveaux que je sauve dans un buffer et je réaffiche tout en utilisant ce buffer mais là ou ça ce complique c'est lorsque je touche une brique, en effet il faut que je face encore une matrice qui elle enregistre un sprite en dessous des brique de 18x10 donc avec sprite32 mais je perd 25ko rien que pour ça donc pour dire qu'une brique et cassé j'affiche l'image en dessous de la brique via ce buffer, dans la map je met 0 et j'enregistre l'image du niveaux complet dans le buffer mais y a encore un problème c'est qu'il resteras toute image de billes, de missiles... dans le buffer du niveaux, donc éclairé moi sur ce sujet, en bref pour simplifier les choses, au lieu de lire la matrice du niveaux j'enregistre seulement l'image du niveaux et je l'affiche mais le problème c'est d'agir correctement avec le changement de l'image du niveaux.

Personnelement je ne trouve pas que ma méthode est barbare et surtout digne d'un débutant car de nombreux jeux font sur ce principe et heuresement d'ailleurs.

geogeo a écrit :
Bon je viens de réfléchir longuement au sujet et la méthode que j'utilise n'est pas une méthode de débutant car afficher seulement des zones peut s'avérer plus rapide que de tout réafficher car imaginé donc un jeux qui change très souvent de sprites de décors ou autre et ou il y a une multitude de sprites..

bah nan justement car il te faudra sauvegarder d'autant plus de zones. Tu veux un jeu où les sprites de décor changent avec une multitude de sprites? SMA.

Au démarrage du programme j'affiche une matrice spéciale de décors avec des sprites de 16x16 ou 8x8 pour j'enregistre completement ce décors dans un buffer via spriteX8Get, de même pour le niveaux que je sauve dans un buffer et je réaffiche tout en utilisant ce buffer mais là ou ça ce complique c'est lorsque je touche une brique, en effet il faut que je face encore une matrice qui elle enregistre un sprite en dessous des brique de 18x10 donc avec sprite32 mais je perd 25ko rien que pour ça donc pour dire qu'une brique et cassé j'affiche l'image en dessous de la brique via ce buffer, dans la map je met 0 et j'enregistre l'image du niveaux complet dans le buffer mais y a encore un problème c'est qu'il resteras toute image de billes, de missiles... dans le buffer du niveaux, donc éclairé moi sur ce sujet, en bref pour simplifier les choses, au lieu de lire la matrice du niveaux j'enregistre seulement l'image du niveaux et je l'affiche mais le problème c'est d'agir correctement avec le changement de l'image du niveaux.

Ouarf c'est pas élégant ()

Bas propose moi mieux!!

1- afficher le background en écrasant tout
2- afficher les briques. Tu peux par exemple utiliser un tableau dont chaque case correspond à une brique et contient le pointeur vers le sprite de celle-ci, et 0 si elle est cassée. Il suffit donc d'écrire une seule valeur dans le tableau lors d'une destruction. Pour afficher, tu parcours le tableau en largeur et hauteur et tu affiches directement la brique [x][y] à (x0+x, y0+y).
3- tu affiches les objets spéciaux tout simplement.

Pas de problème, pas de Kos en plus, pas de bitmapget, pas de buffer, pas de...
Enfin c'est ce que je ferais d'instinct, y'a surement mieux...

Tu voit pas le problème et c'est pourtant évident! Parcourir un tableau c'est ce que je ne veut surtout pas car c'est là la cause de la lenteur.

bof, c qd même pas d'une lenteur extreme...

des centaines (voires des milliers) de jeux utilisent ça...

Au fait, geogeo, hier j'ai écrit les fonctions Sprite8. En mode OR, on est 39% plus rapide que celle d'extgraph et en mode masqué, on arrive à plus de 50% de vitesse en plus (mais ça me parait un peu trop, je vais rebencher...)
Le temps que je fasse les versions Gray8 et je les uploade... (je pense que je ferai ça ce soir)

deux for décrémentés sont très rapides, en tout cas beaucoup plus que d'avoir à recalculer les coordonnées de tes briques à chaque fois, car là ces coordonnées correspondent justement à celles dans le tableau. Franchement je ne vois pas du tout pourquoi tu dis que parcourir un tableau est lent.

bah oué, les tableaux c tres bien ... puis faut mieux aller se déplacer dans un tableau que de recalculé par exemple ...

je parie que SMA et CF effacent tout et réaffichent tout
et pourtant, ils rament pas

Bon j'ai testé ma méthode de sauvegarde avec des zones... Avec 10 billes le max, les collisions avec les billes et avec l'écran et j'arrive à environ 75 à 82 fps, je dis ça car variable en effet j'utilise l'int5 modifié à 8khz et je joue du son en même temps donc desfois le so fait perdre 10 fps mais c'est le max mais je vais corriger ça car en effet mon int5 n'est pas précise elle varie de 8192 hz à 7800 hz.

Je vais réfléchir à tous ça est m'y mettre et je pense que vous avez résond de tout réafficher car cele me simplifiras de beaucoup, les bonus et aussi gagner en affichage de sprites. Mais je veut faire beaucoup de fps car je vais utiliser du son plus 8 niveaux de gris donc là je suis assez content mais je pense pas que ça suffiras evec 8 niveaux de gris si les 8 niveaux de gris divise par 2 le nombre de frames.

Maintenant j'ai fait en réaffichant tout sauf le décors, et j'arrive à 15fps a savoir que pour lire un niveaux je lis la matruce et je fait correspondre le numéro avec la matrice des briques donc logiquement rapide.

Je pense quand combinant les 2 méthode j'arriverais au delà de 82 fps car j'ai fait un teste en tout réaffichant et en utilisant une image pour le niveaux... à 162 fps. Je crois avoir trouvé une solution qui va me simplifier la vie.

Ptit sondage sur les 8 niveaux de gris et un autre sur le son.

[sondage=13406]

Merci d'y répondre honnetement et sérieusement.

Sondage sur le son:
[sondage=13407]

Ca serait vraiment sympa que vous y répondais sérieusement et surtout que vous me fasiez part de vos opinions car mon jeux dépenderas de c'est 2 sondages car j'hésite sur beaucoup de choses.

Avant de répondre au sondage pour le son il me faudrait une démo. Je ne peux pas voter sans connaître!

Je sais bien ça mais il faut être patient malheuresement car la librairie elle-même est au point mais elle subirat quelle-que modificaction dû à mon jeux mais en bref le son serat identique que pour la version 1.3 sauf qu'on pourras jouer du son avec des actions et des niveaux de gris.

J'ai fini tes fonctions, geogeo.
Pour les télécharger : FastGraySprite.zip

Ah oui, les perf des fonctions 32, c'est de l'ordre de 50%, il me semble. Enfin, tu verras, c'est marqué dans les fonctions.

Merci Jackiechan mais en attendant pour SpriteGet je vais créer un petit logiciel de conversion en C d'images dans ton format que je trouve d'ailleurs vraiment simple car plus besoin de jongler avec les plans.

pour le son, j'ai mis amusant, je crois
principalement si c une demo pr la lib, en fait.

pr les grays... inutile a me syeux

Merci squale92 pour ton vote et pour m'avoir expliquer ton choix car comme je l'ai dit maintenant je verrais en fonctions des votes et pour l'instant je vois que les 8 niveaux de gris ne font pas sensations.

Ca bouffe de la mémoire et ça n'apporte pas vraiment beaucoup par rapport aux 4 NVG. En plus ça clignotte plus.

Au fait, geogeo, si tu choisis de n'utiliser qu'un seul masque par sprite (au lieu d'un masque par plan), ce qui est largement suffisant, les performances des fonctions seront nettement augmentée, et les fonctions seront plus petites en taille.

C'est ce que je fait jackiechan, je n'utilise qu'un masque par sprite qui est en noir.
Par contre pour former un sprite de 64x8 je peux utiliser GraySprite32 x2?

Pour les 8 niveaux de gris je vais y réfléchir. Je vais essayer et je vais diffuser un screen et vous me dirais ce que vous en pensez.

Attends, tu utilises un seul masque que tu appliques à tous les plan, ou bien un seul masque que tu n'appliques qu'à un seul plan ? (si c'est la dernière, ce sera vraiment plus rapide, sinon, ce sera pas mal plus rapide)
Si tu utilises un seul masque NOIR, ça veut dire que tu as un masque que tu appliques aux deux (ou trois) plans.

Sinon, pour ce qui est de ton sprite de 64 pixels de largeur, oui, tu peux évidemment le décomposer en deux sprites de 32 pixels de largeur, mais ce sera légèrement plus lent qu'avec une fonction prévue pour. Mais j'ai la flemme d'en écrire une parce que ça complique un petit peu.

Et au fait, pour tes briques, tu dis quelque part que qu'elles ont 18 pixels de largeur. Ce serait nettement plus rapide si tu les prenais à 16 pixels. Ça irait vraiment plus vite, pour pas grand chose de perdu (les fonctions d'affichage de sprites de 32 pixels de largeur sont relativement lentes par rapport aux autres).

J'utilise un maque que j'applique à tout les plans.
Pour les briques, elle font du 16x8 mais pour sauvegarder les zones j'utilise du 18x10 car elles possèderont des ombres mais cette méthode je l'ai abandonnée car assez pénible donc je n'auarsi plus de buffer de 25ko pour la sauvegarde des zones sous les briques.

Pour les sprites de 64 ne t'inquiéte pas je ferait une macro.
J'utilise un masque que j'applique au 2 plans mais si je l'applique à un seul plan je doit rentrer dans les paramètre (NULL)?

La en ce moment je suis en train de dessiner les sprites car je ne peut pas continuer car il me manque SpriteGet, au point de vue des 8 niveaux de gris, je ferait des comparaison pour voir si c'est vraiment utile.

Bon, j'essaierai de te faire tes spriteget (ça ne devrait pas être trop long) cet après-midi

Sinon, si tous tes sprites ont une hauteur multiple de 2, on peut encore accélérer les choes (mais ce serait vraiment très peu là).

Je n'ai pas trop compris ce que tu me demandes dans ta question sur les masques.
Il faut savoir : soit tu as un masque que tu affiches sur chaque plan, soit tu as un masque par plan. Plus haut, tu m'as dit que tu utilisais la première solution, mais là tu me demandes comment faire pour appliquer un masque à un seul plan

En faite en ce moment j'ai un masque que j'affiche sur chaque plan mais afficher un masque pour chaque plan donc différent cela est inutile car mes masques sont toujours noir.