nKaruga

[pierrotdu18]

Si vous voulez suivre, c'est ici : http://www.omnimaga.org/pixel-art-and-d ... #msg387518

J'ai fait deux nouveaux ennemis, et un boss!

[matref]

Énorme bonne nouvelle : avec l'aide de différents testeurs et d'ExtendeD, j'ai pu régler le problème de vitesse !

Il suffisait en fait d'implémenter un frameskipping 1/2 (ne dessiner les choses à l'écran qu'une frame sur deux, bien qu'on déplace les objets et teste les collisions à chaque frame) et un keyskipping 1/4 (ne tester les touches qu'une frame sur quatre, en fait c'est carrément lent des touches d'Nspire). J'avais déjà testé, mais apparemment j'ai dû mal le faire parce que ça n'avait pas changé grand-chose.

Résultats, ça va viiiiiiiiiiite, même beaucoup trop vite sur caltos GS

Image : http://www.mirari.fr/toLw

Test : http://www.omnimaga.org/ti-nspire-projects/(ndless)-nkaruga/?action=dlattach;attach=17743
Commandes : https://github.com/matrefeytontias/nKaruga/blob/master/README.md

[Lepzulnag]

J'ai hâte d'y jouer !

Sinon, c'est super bon à savoir que les touches nSpire soient si lentes ! Tu viens de résoudre un de mes problèmes

Comme toi, je suis actuellement sur un moteur de jeu (je travaille très peu hélas Mais bon les vacances commencent alors il y a de l'espoir !) et j'avais du faire face à un problème de vitesse qui me perturbait vraiment beaucoup : le jeu était plus rapide quand j'appuyais sur une touche, même si celle-ci n'avait aucun effet ! Comment appuyer sur une touche inutile pouvait-il accélérer le programme ?

J'étais très perturbé, et avais finalement trouvé une solution (sans comprendre pourquoi ça marchait) en augmentant le temps pendant lequel, dans la boucle, le programme ne fait rien (c'est pas tout à fait ça, mais en gros c'est l'idée).

Mais grâce à toi, je suis maintenant presque certain que c'est à cause d'un any_key_pressed que ce problème de vitesse avait lieu ! Le temps d'affichage + le temps de détecter l'appui d'une touche dépassait le temps d'attente de ma boucle, résultat : le temps d'attente était donc inutile ; la calculette travaillait sans pause (la pauvre ). Appuyer sur une touche raccourcit la durée de traitement de la fonction any_key_pressed, et c'est sûrement cela qui causait l'accélération de mon programme !

Donc : bonne continuation pour ton jeu, et merci pour l'info technique

[matref]

Mais de rien c'est effectivement sûrement ça le problème. Au pire teste

[critor]

Je ne sais pas si ça aide, mais nDoom n'utilise pas any_key_pressed et n'a aucun problème de vitesse à ma connaissance.

[matref]

Pareil, j'utilise seulement isKeyPressed.

[matref]

J'ai ajouté l'écran titre (vite fait) que m'a fait pierrotdu18, et en ai profité pour réarranger un peu tout ça pour pouvoir (plus tard) faire des menus imbriqués.



J'ai aussi rendu les patterns plus mieux en ajoutant un timer par vague

[Hayleia]

Très bien
Par contre, quand tu parles de frameskipping, tu zappes tous les dessins pendant une frame ou tu dessines quand même mais juste sans copier le buffer à l'écran ? Je suppose que c'est la deuxième solution* mais je demande quand même.

*surtout en lisant ça dans le code :

Code: Select all

if(!skipFrame)
{
   updateScreen();

   if(displayBg)
   {
      //faire des trucs
   }
   else
      clearBufferW();
}


[matref]

Ah non, je dessine vraiment rien du tout. Ça évite que tous les sprites aient une traînée d'eux-même derrière eux.

[Hayleia]

Ah ok, ben j'ai bien fait de demander alors O.o
Du coup, ça marche bien ici mais ça marcherait moins bien pour des jeux où la collision se base sur le pixel. D'un autre côté, ce genre de jeu ne doit exister que sur z80 alors c'est pas trop grave