chronomètrage en dixièmes de secondes - Page 2

http://www.ticalc.org/archives/files/fileinfo/255/25568.html (et on peut faire mieux)

[edit: après l'avoir essayé, je constate que c'est à ~1fps . mais pour un snake c'est pas un problème]

Sauf que dans un Snake bien fait, la difficulté est donnée par la vitesse de déplacement du serpent, pas par le fait que le clavier met 1 seconde à répondre et qu'il faut donc deviner le bon moment pour appuyer la touche.

En C, on peut facilement faire un Snake à 90 fps (le maximum géré par le LCD, inutile d'essayer d'aller plus loin) même en optimisant purement pour la taille. En TI-BASIC, je pense que même 12 fps (le minimum pour un jeu fluide) restent une utopie.

En TI-basic tu veux dire?

Oui, évidemment. Un BASIC compilé peut facilement arriver à cette vitesse. (Reste à voir si ETP y arrive. )

lol
la réponse est oui sans hésitation.

Kevin Kofler (./32) :
on peut facilement faire un Snake à 90 fps (le maximum géré par le LCD, inutile d'essayer d'aller plus loin) même en optimisant purement pour la taille.

http://www.ticalc.org/archives/files/fileinfo/316/31689.html (bon il tourne pas à 90 fps parce que y a des temporisations, mais il le dépasserait largement sans)


Mais en Ti-basic pur on doit sûrement pouvoir faire un truc potable...

si potable=fluide, non (enfin j'aimerais bien qu'on me montre comment faire si oui ...)

Kevin Kofler (./32) :
En TI-BASIC, je pense que même 12 fps (le minimum pour un jeu fluide) restent une utopie.

[flash=640,380]http://www.mirari.fr/Vsp4?file=http://www.mirari.fr/xBhF[/flash]

tiens, une utopie (avec la collection des 305648 snakes en Basic qui doivent trainer sur ti-calc, t'avais vraiment besoin d'en faire un ? )

(sinon tu te compliques la vie, tu peux poster une vidéo comme ça quitte à récupérer le lien vers le lecteur flash pour lire directement sur yN ^^)

Et tu devrais mettre le lien de téléchargement pour pouvoir visualiser la vidéo avec un logiciel normal, pas tout le monde n'a Flash. Et tu devrais mettre une version Theora aussi...

Mais pour en venir au contenu de la vidéo, 2 secondes à chaque fois que le serpent consomme un fruit, tu appelles ça "fluide"?

Et puis rien dans ta vidéo ne prouve que c'est du TI-BASIC pur.

Les pauses d'une demi-seconde c'est seulement quand on passe au niveau supérieur (y a une animation), quand on gobe un fruit normal la pause est juste d'un ou deux frames... C'est normal qu'un serpent en train d'avaler quelque chose ralentisse

Et c'est du Ti-basic pur, par contre c'est vraiment pas du tout optimisé taille (boucles déroulées...) donc je pense pas que tu apprécieras


Bob> c'est pas un jeu, c'est juste un proof of concept, mais si quelqu'un veut en faire un vrai jeu tant mieux ^^ (pour mirari : ah oui, bien vu )

En tout cas, le mien n'a jamais de ralentissement . ôO
Je veux bien vos codes de snake, voir si je peux accelerer le mien

Si tu veux, je t'envoie le mien

Bravo Pollux

J'ai toujours programmé enn TI basic et je suis jamais jusqu'ici allé voir de fofo/tuto et pourtant des snakes fluides c'est facile à faire.
Rajouter le level, je vais essayer...
Très beau le snake <3

Le code correspondant au screenshot (je le poste seulement maintenant parce que j'avais pas encore réinstallé les outils de transferts TI-PC) : Fichier joint : utopia-gen.tig

La méthode utilisée est un peu bourrin, il y a un programme qui s'appelle utogen() qui génère le programme final utopia() en prenant en paramètre les longueurs de serpent aux différents niveaux, et la longueur de chaque niveau. Par exemple utogen({5,10,18},{2,3,∞}) génère un niveau 1 avec un serpent de longueur 5 qui a besoin de manger 2 pommes pour atteindre le niveau 2, au niveau 2 le serpent est de longueur 10 et a besoin de manger 3 pommes pour atteindre le niveau 3, et au niveau 3 le serpent est de longueur 18 et mange des pommes jusqu'à ce qu'il meure. L'inconvénient de la génération de programme c'est que ça donne un programme final très gros (la taille du programme est grosso modo proportionnelle à la somme des tailles des serpents à chaque niveau), mais c'est le seul moyen que j'ai trouvé pour éviter d'être ralenti par les tableaux, les chaînes, ou les indirections (les indirections sont particulièrement lentes parce que pour gérer les variables spéciales comme xmin le code de tokenisation est appelé systématiquement ).

Là le but était d'être le plus rapide possible sans faire de compromis, mais si on accepte de faire un snake 25% plus lent on peut rajouter des fonctions sympa, par exemple une longueur variable en passant par des tableaux, ce qui permet d'avoir un programme final assez petit, ou encore un joli serpent contigu, arrondi dans les coins, et avec une tête différente du corps (et sachant que le screenshot fait à peu près 13 fps sur HW1, un code 25% plus lent peut quand même atteindre 12 fps sur HW2).

Petite remarque, c'est vraiment très primitif, aucune gestion des vies, aucun niveau avec des obstacles, il manque le code pour supprimer les axes ou nettoyer les variables globales (je n'utilise pas de variables locales parce que ça donnerait un programme tokenisé beaucoup plus gros). Bref comme je l'ai dit c'est pas un jeu mais un simple proof of concept.

Et enfin pour l'aspect légal vous pouvez faire ce que vous voulez du code, considérez que la licence est aussi proche du domaine public que le droit français le permet

#Pollux#

Du code autogénéré dans lequel tout est codé en dur? C'est vraiment n'importe quoi...

Tu n'as pas une âme d'artiste

Kevin Kofler (./48) :
Du code autogénéré dans lequel tout est codé en dur? C'est vraiment n'importe quoi...

Je savais bien que ça te plairait

Moi je trouve ça plutôt génial
Et pour un tetris BASIC basique, combien de fps ?

Du code autogénéré dans lequel tout est codé en dur?

Je vois pas où est le problème

Thomas a fait ça pour le scaler du FAT-Engine. Sans ça, FAT-Engine n'atteindrait pas les performances qu'il atteint (10-15 FPS) sur un M68000 @ 10-12 MHz.
Sam Stearley avait commencé des modifs du scaler pour le rendre à la fois plus rapide et plus petit, mais à ma connaissance, il n'a jamais eu le temps de les finir.