jibax Le 25/07/2003 à 00:50 tu peux faire un tableau qui represente la map (mais ca revient au meme qu'une liste de coordonnées)
moi j'avais fait un curseur qui se déplacait dans le tableau de coordonnées(c'est la methode classique, non?
ou enregistrer que les directions, avec la position a l'instant t et la longueur ca doit suffire....
Hmm, dans vos snake, vous stockez les obstacles dans une map ou pas ?
En fait je posais cette question parce que je me suis rendu compte qu'avec la méthode de yAro, si c'est bien celle que je pense, on pouyvait économiser pas mal de mémoire et permettre au snake une longueur quasi infinie donc. Je vais essayer ça dans mon snake et voir ce que ça donne
Zeph Le 01/08/2003 à 15:45 La méthode avec les memmove est très mauvaise. Et je ne vois pas pourquoi la méthode classique (qui doit être expliquée dans ce topic je crois) ramerait quand le serpent s'allonge ?
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
classique == tableau des coordonnées ?
de tout les points du serpent ?
Proud to be CAKE©®™
GCC4TI importe qui a problème en Autriche, pour l'UE plus et une encore de correspours nucléaire, ce n'est pas ytre d'instérier. L'état très même contraire, toujours reconstruire un pouvoir une choyer d'aucrée de compris le plus mite de genre, ce n'est pas moins)
Stalin est l'élection de la langie.
Ben selon moi, tu as ta map en mémoire. Là où est le serpent, tu marque donc "serpent", et tu marques "bonus" là où il y a un bonus, "mur" là où il y à un mur. Mais au lien de mettre simplement "serpent", tu mets "serpent_haut", "serpent_bas", etc... Et si tu utilise des 'char' pour faire ça tu peux faire un masque de bits qui dirait par exemple:
bit 0: mur
bit 1: serpent
bit 2: bonus
bit 3: super bonus
bit 4-5: direction (seulement pour le serpent)
...
Donc tu stocke:
-ta map (chargée en RAM pour pouvoir la modifier)
-la position de début du serpent
-la direction du serpent
-la longueur du serpent
-la position de fin
Et pour avancer, tu effaces le bloc de fin de l'écran, puis tu lis le bloc de la position de fin puis tu l'effaces (...), là tu mets à jour la position de fin à l'aide des bonnes infos comme tu le ferais pour la position de début.
Ensuite, tu fais avancer la tête (où dans l'ordre inverse si tu veux)
Je me suis pas trompé ?
Heu...
Tu dois aussi stocker tous les mouvements que le snake a fait entre temps non? Là tu l'as pas compté dans les éléments à stocker.
Non, c'est ça l'astuce. Si tu regarde ce que j'ai écrit: la direction est stockée dans la map pour chaque bloc qui appartient au serpent...
Tu les stockes au fur et à mesure.
En BASIC ce serait lent parce que les matrices du BASIC sont des listes chainées et non pas des tableaux comme en C, mais au moins en BASIC, la vitesse serait la même tout le temps, elle ne diminuerait pas en fonction de la longueur du serpent, comme ça le ferait si tu utilisais une simple liste.
Comment se fait-il que next_expression_index soit énorme ?
Comment fonctionne précisément ce ROM_CALL ?
Si c'est un entier, une fraction ou un flottant, tu peux utiliser estack_number_to_Float. Si ça peut aussi être un truc du style pi/4 ou e^3, il faudra utiliser NG_approxESI, puis GetFloatArg ou estack_number_to_Float.
En gros NG_approxESI puis GetFloatArg fonctionnera à tous les coups (mais sera lent) ?
Oui.
Mais si l'expression est courte (un flottant seul par exemple), ça ne sera pas si lent que ça.
Puis ce n'est pas si lent que ca ... c'est un parcours d'arbre je pense (enfin, je verrais stocké ça comme ca moi)
)
.
)
