Arkanoid - Page 18

Du point de vue de la boucle principale, tout ce que ça change, c'est que tu dois faire un truc du style :
DrawBWSprite(sprites[i][cur_plane],16,16,planes[cur_plane]);
au lieu de
DrawGraySprite(sprites[i],16,16,grayplane);

Mais la contrainte, c'est que ton jeu doit tourner à plus de 90 fps sinon le jeu va clignoter ; cela dit ce n'est pas forcément difficile puisque toutes les routines graphiques travaillent sur 2x moins de données (et en fait, on doit pouvoir se débrouiller pour que ça marche avec un jeu qui tourne seulement à un peu plus de 60 fps, mais là ça devient plus subtil).

Et en plus ça t'évite ce que le triple buffering te bouffe en RAM.

OK je comprend mais je vais devoir remodifier toutes mes fonctions pour travaillier en B&W et changer à chaque boucle de plan dans mon buffer ScreenBuffer.

Je vois plutôt ça moi:
n=0

boucle:
Je fais mes collisions.
Je dessine en noir sur ScreenBuffer+n*6000
J'affiche le ScreenBuffer en B&W sur LCD_MEM (en bref je change l'adresse de la mémoire vidéo?)
n=1 xor n
Continuer boucle.

Pas exactement, mais du point de vue de la boucle principale c'est ce qui se passe. La subtilité vient du fait que c'est l'interruption qui modifie n, pas la boucle principale, pour qu'on soit bien à 90 Hz, et aussi du fait que n vaut 2 fois sur 3 0, et 1 fois sur 3 1.

OK ça m'interesse vraiment cette méthode, je vais coder une autre version d'arkanoid utilisant cette méthode et comparer les versions pour voir si ça en vaut la peine. De plus je vais gagner 7680 octets ce qui n'est pas négligeable et ce qui compensera mon buffer de 240x200 pixels et mon buffer de MAP.

Reste une question, j'utilise PolySnd dans mon programme soit l'interruption 5 occupé, il lui reste 1 Hz qui me permet d'afficher le nombre de fps et d'appliquer des temps d'attente, donc il me reste l'auto int 1 qui tourne à 255 Hz sur HW2 mais je me sers aussi de cette auto int1 pour les animations, j'espère que ça ne va pas tout pomper!

Pour les ombres personnelement je les trouve bizarre et je voudrais avoir de vos conseils, sur la version originale du jeu, leurs effets d'ombres et obtenus avec des sprites alors que moi je les calculs.

J'ai réalisé le rippage des raquettes avec animations et ce pose un problème, il y a des effets d'ombres posible à réaliser pensez vous que les ombres soit utile dans ce cas?

il me reste l'auto int 1 qui tourne à 255 Hz sur HW2

256.

OK merci.

Bon je viens de modifier le jeu pour adopter la méthode de Pollux alors les résultats sont vraiment génial:
J'affiche juste pour l'instant le plan voulu du buffer ScreenBuffer sur l'écran et mon compteur de frames m'indique 480 fps par plan donc 240 fps pour les 2 plans mais ce pose un problème je n'arrive pas à stabiliser.
En effet dans mon inetrruption de 256 Hz j'utilise la même méthode de PolySnd pour passer de 256Hz à 30 Hz ou 31 Hz or les plans ce desynchronise. Je dois utiliser un switch? Et ne pas créer 2 compteurs par plan?

Je crois qu'il faut que tu utilises l'auto-int 5, donc essaye en l'intégrant dans PolySnd et en mettant éventuellement un offset réglable pour pouvoir régler le moment où tu changes l'écran.

Euh sinon je ne comprends pas trop tes histoires de 480/240 fps... Je ne vois pas comment ça pourrait aller plus de 2x plus vite avec cette méthode.

Je vous assure je ne rêve pas j'ai belle est bien 440 fps et ce qu'en affiche seulement un plan.

480 et 440 la différence vient que 480 est obtenu avec PolySnd v2.0 et 440 avec l'auto int 1 à 256 Hz.
J'ai un gros soucie car je n'arrive pas à synchroniser les compteurs d'affichage de plan. Car en effet je change l'offset de mon plan.

Bon le peu de gris que j'ai vu c'est vraiment fantatisque, pas de clignottement et vraiment parfait mais c'est pas stabilisé.

Ah oui je n'affiche que une partie du buffer sur LCD_MEM ce qui fait que j'applique qu'une routine en boucle. Donc ce qui peux expliquer ce nombre de frames élevé mais il est 4x plus élevé qu'avec les niveaux de gris de TIGCC voir plus.

Ah, tu veux dire en désactivant les gray de TIGCC ?

Bah ton idée n'était pas de désactiver les niveaux de gris de TIGCC et donc de réaliser les miens?
De plus les nouveau niveaux de gris rendent meiux, l'écran ne bave pas, la bille est plus visible... or ça clignotte horriblement. Comment je dois procéder au juste?

Bah non, tu peux reprendre les grays de TIGCC en changeant le plan d'origine (i.e. tu prends le dernier plan dessiné), en activant le flag qui dit qu'il faut se remettre à dessiner et en décidant quel est le plan suivant à dessiner.

Euh, c'est quoi ces hacks pourris que tu suggères là? Modifier l'adresse du plan -> pas prévu par l'API! Activer un flag -> carrément pas prévu par l'API!
La solution correcte est de tout simplement attendre la synchronisation. Si tu forces le redessin plus tôt que prévu, tu ne vas pas laisser à l'écran le temps de réagir et ça va clignoter comme pas possible.

OK j'avais juste penser libérer 7 Ko en évitant d'avoir GetPlane(0) et GetPlane(1) de TIGCC.
Je vais voir ce que je peux faire. Mais Kevin a raison il faut laisser un temps pour l'écran.

Euh, c'est quoi ces hacks pourris que tu suggères là? Modifier l'adresse du plan -> pas prévu par l'API! Activer un flag -> carrément pas prévu par l'API!

Je ne parle pas d'utiliser l'API, je parle d'utiliser la source et/ou la méthode.

La solution correcte est de tout simplement attendre la synchronisation. Si tu forces le redessin plus tôt que prévu, tu ne vas pas laisser à l'écran le temps de réagir et ça va clignoter comme pas possible.

Oui, mais qui te parle de forcer le redessin? C'est évident qu'il faut se synchroniser à 90 fps, parce que de toute façon l'écran ne supporte pas plus.

Pollux
: Oui, mais qui te parle de forcer le redessin?

Toi:

Pollux
: en activant le flag qui dit qu'il faut se remettre à dessiner

Je parle justement d'un flag qui dit à la boucle principale de se remettre à dessiner, ce qui implique qu'elle était en train d'attendre Donc je parlais précisément de synchronisation (en le voyant du côté interruption et pas du côté boucle principale : il faut bien signaler à la boucle principale que la synchro est arrivée).

Je viens d'essayer ta méthode Pollux et les résultats sont decevants, problèmes de fluidité à certains passage, le jeu tourne à 60 fps au lieu de 85 voir 90 fps. Là j'utilise les gris de TIGCC, la seule façon d'exploiter ta méthode est de réaliser ces propres fonctions de niveaux de gris, or j'ai essayé et les niveaux de gris clignotte monstrueusement.

Un coup tu me dis que le jeu va 10x plus vite et la fois d'après tu me dis que ça va plus lentement, faudrait peut-être savoir... Et ensuite il n'y a pas de "clignotement monstrueux" lié à la méthode dont j'ai parlé. Reprends les grays de TIGCC et modifie juste ce qu'il faut, il n'y a aucune raison pour que ça clignote.

J'ai 10x plus de frames lorsque je n'utilise pas les grays de TIGCC et que je créer ma propore fonction de niveaux de gris mais ça clignotte.
Dans le cas ou j'utilise les niveaux de gris de TIGCC, les gris sont vraiment plus beau mais je perd 20 fps.

Bah de toute façon si tu fais un jeu en niveau de gris tu ne peux pas te passer d'une méthode de gris type TIGCC. La seule chose que tu peux améliorer, c'est la vitesse de l'affichage (tracé de sprites, et surtout scrolling).

ok je vois

Arkanoid avance doucement, je viens de finir de ripper les 20 sprites des raquettes pour le jeux et de développer une gestion des collisions avec les briques non buggé. Mais ce pose un problème, mes sprites pour la raquette font 48x9 pixels, pensez-vous que découper le sprite en une section de 32 pixels puis une autre de 16 pixels soit le plus performant? Ou de créer une gestion de ce type de sprite soit la meilleur solution?

J'ai un petit problème que je ne comprend pas:
J'utilise des matrice de 13*18 définissant les niveaux.
Donc par exemple MAP_LEVEL1 [18][13] pour le niveau 1

Je créer donc une autre matrice qui sera modifié de cette façon:
static unsigned short LevelMap [18][13]={};

Jusque là pas de problèmes mais ce qui devient bizarre c'est ici, pour copier MAP_LEVEL1 dans LevelMap je faisais memcpy (LevelMap,*map,18*13);

map correspondant à la carte passé en argument soit:
void SetMap (unsigned char map[18][13]) {memcpy (LevelMap,*map,18*13);}

Pourtant ça fonctionnait correctement, là ce n'est plus le cas, ma map est affiché bizarrement avec des briques manquante... et ce depuis que j'ai ajouté un #define puis que je l'ai enlevé. J'ai donc réinstallé TIGCC et rien à faire.

Quel est le define que tu as ajouté/enlevé ?
Sinon, normalement tu ne dois pas faire d'indirection sur ta map pour obtenir son adresse, mais cependant, ça ne devrait pas gêner puisque ça devrait renvoyer l'adresse de la première ligne, qui est la même que celle de la map elle-même.
Je me trompe ?

Non tu ne te trompe pas.
En tout cas cette ligne fonctionné avant et le bug vient d'elle maintenant et je ne vois pas pourquoi. Peut être parce que le static ... n'est plus trop accepté.

Voici mon défine pourtant banal:
#define BLOCKS_STARTZONE 8

memcpy(LevelMap,map,sizeof(map)); devrait marcher... Tu as défini map comme un tableau de short.

(et d'ailleurs tu peux remplacer *map par map, ce qui a plus de sens puisque ton memcpy porte sur sizeof(map) et pas seulement sur sizeof(*map)=sizeof(map[0]))

Non mes map sont des tableaux de char, j'ai essayé ta ligne et ça ne fonctionne pas. sizeof (map), ne mesure que la taille du première élement du tableau? Soit ici 1 octet?

Donc j'ai essayé ça: memcpy(LevelMap,map,18*13); Rien à y faire.

Vous voulez les sources du jeu? Le problème est vraiment bizarre.

En attendant j'utilise cette méthode:

for (int i=0;i<18;i++)
{
  for (int j=0;j<13;j++)
  {
    LevelMap [i][j]=map[i][j];
  }
}

Lente est vraiment crade.

Voilà comment s'affiche la map avec memcpy:


Au lieu de: