Scrolling - Page 1

J'ai lu dans d'autres posts que les jeux comme Bombermaze n'utilisent pas la methode du scrolling.

Or un jeu qui utilise le scrolling est forcement plus rapide qu'un meme jeu qui n'utilise pas cette fonction.

Le seul inconvenient du scrolling est qu'il necessite l'allocation d'une grande plage de memoire pour y stocker la tres grande image a visualiser partiellement. Une fois l'image créée, il n'y a plus de calcul a faire pour afficher une partie de cette image sur l'ecran (d'ou un gain de clock d'horloge enorme).

Mais alors comment se fait-il que Bombermaze (par exemple) ai besoin de pres de 80ko pour demarrer (alors qu'il est deja tres lourd en octets) ?

Non le scrolling esttrès lent par rapport à d'autres techniques plus optimisées pour ce genre de cas telles que les tableaux de tiles. L'image de fond est décomosée en multiples tiles 16x16 par exemple (avec un 68k le 16x16 ça marche bien ) et on réaffiche tout l'écran à chaque fois putôt que de décaller l'image existante. Ca va beaucoup plus vite, et c'est ce qui est utilisé par la plupart des jeux en 2D sur console. Et par la plupart des bons jeux TIs aussi (nan Kevin ne me tue pas c'était pour rire)

Parceque j'ai fait un scrolling (largeur 60 octets=480 pixels hauteur 300 pixels) avec niveaux de gris et j'atteint 200 images par seconde avec l'affiche d'un sprite suplementaire.
Mais je n'ai pas essayé avec des tiles.
Si l'image est tres complexe, le scrolling n'est pas la meilleure solution?

non, ça prendra au moins autant de place en memoire, dans l'immense majorité des cas ça en prendra plus, et en général c'est plus lent.
Pour la rapidité ça dépend du jeu en fait, mais en général tout recopier est considéré comme plus rapide.

Lorsque j'inclus des images animées (qui sont clippées et affichées a chaque boucle), on sent nettement (a partir d'une 50n d'images seulement que le programme a du mal)

a partir du moment ou l'image est complexe (fond anime, est sprites en mouvement par-dessus, par exemple), tout redessiner sera plus rapide qu'un scrolling, en general
(et moins gourmand en memoire)

A partir du moment ou l'image est riche en details, reafficher les multiples tiles va etre long.
Par contre, si le jeu est tres animé (et que l'image de fond est simple), la alors la methode des tiles est plus rapide.

Mon scrolling fait executer au processeur pas plus de 4300 operations.
Si dans l'image de fond il y a 200 tiles (tres peu), chaque calcul de position et affichage d'un tile doit prendre moins de 25 operations en moyenne. (moins de 6 si l'image est couverte de tiles).

PS: L'image de fond fait 64 octets de large pour 320 lignes (et pas 60*300 comme je l'avais dit; 60*300 est la partie visible de la memoire dans le jeu... mais ca c'est une autre histoire.).

deja, tu ne reaffiche que la partie visible a l'ecran.
et si tu fais quelque chose d'anime en 36 couches, exit le scrolling....

regarde CF ou SMA, pour voir ce qu'on peut faire sans scrolling
(je sais, c'est toujours les deux meme exemples qui sortent mais bon, c'est ca la qualite PpHd )

Es-tu sur de faire un VRAI scrolling ? 200 images / s c'est enorme.

possible sans VSà

vi mais en utilisant une méthode de tiles direct, enfin sans faire de scrolling quoi

Oui, évidemment, il faut que tu n'affiches que les tiles visibles
Ça te permet d'avoir des map bien plus grandes.

Si si, mon scrolling est un vrai scrolling vertical et horizontal qui fait rouler les bits sur eux meme et tout et tout...

Mais pour la vitesse, c'est une approximation car je chronometre le temps mis par le processeur pour balayer tout l'ecran de fond (64octets).

64octets*8 - 160pixels (taille de l'ecran)
= 352pixels parcouru en 2s25 avec une avance de 1 pixel par boucle de jeu.

Merde... j'avais sans doute mal chronometré avant (sans doute oublié d'enlever les 160 pixels de l'ecran): ca fait a peine plus de 150 images par seconde, mais c'est deja pas mal. Mais ca change rien au nombre d'instruction que comporte mon scrolling... ouf.

Effectivement si la carte est tres grande, il n'y aura plus assez de place pour allouer la memoire requise pour la sauver (surtout si il y a des niveaux de gris).

Mais mon but est de faire un Zelda tres rapide, dont les mondes ne sont pas trop grands car s'il faut gerer le mouvement (patrouille..) des ennemis qui se trouvent a l'autre bout de la carte.... ca risquerait de ramer un peu... et en plus c'est reposant de pouvoir changer d'ecran quand on est poursuivit, nan?

J'ai fait un editeur de map pour le Zelda en question qui utilise le scrolling mais comme j'ai pas de site, je ne sais pas où mettre la demo (pas jouable, mais qui permet de creer des terrains complets avec niveaux de gris, et images animées, ces terrains sont sauvés dans des fichier externes etc..).

Euh pour Zelda oublie le scrolling... rien que pour la place mémoire que tu économiserais en utilisant un tableau de tiles

tu auras besoin de memoire pour d'autres choses aussi...
par exemple, il faut que tu memorise des données sur tes ennemis, entre autre

Je sais, 64octets*320lignes*3niveaux de gris= 61440octets a allouer.
Plus les 2000 octets de l'ecran virtuel et toute la memoire pour gerer les donnees du jeu, les objets, les quetes, les ennemis... ca fait effectivement beaucoup.

2000 octets d'ecrans virtuels...
argh, et encore un truc qui sera jamais compatible avec les 92+ V200, comme c parti.


l'ideal est de reduire au maximum l'occupation mémoire
(en sachant qu'au final, on en consomme toujours trop alors, autant gagner des que c pssible)

Vous avez raison, je vais passer au tiles, ca permettra en plus de comparer les performances entre scrolling et tiles.

Mais j'espere ne pas avoir galeré sur mon scrolling pour rien, n'y a-t-il pas des applications (jeu si possible) qui ne peuvent se passer de scrolling?

pour un tunnel tout simple, le scrolling est la solution la plus simple et la plus appropriée, je dirai

J'allais le dire

Je ne suis pas encore un expert en ASM, j'ai commencé au debut de l'année scolaire, donc deja il faut que j'arrive a finir un jeu avant de penser a la compatibilité avec les ti92+ et V200...
Je vais faire comme si ca n'existait pas pour l'instant, mais j'y penserais dès qu'un premier jeu sera fini (et s'il est apprecié bien sûr).

Je n'avancerais pas de date pour le jeu car l'ecole bouffe presque toutes mes journées (de 8h00 du matin a 8h00 du soir, sans compter les DMs - je sais, je devrais publier ca dans une rubrique "grosse deprime").

si tu debutte tout juste, tu ferai mieux de commencer par des projets pas trop ambitieux
(j'ai vu beaucoup de debuttants arreter la programmation parce qu'ils n'arrivaient pas, en un mois ou deux, a developper le jeu de leurs réves )

la compatibilité, c dur a implanter une fois le programme terminé...
l'idéal, le moins prise de tete, et le plus simple, et de le faire au fur et a mesure.
cela dit, ceci est valable avec un peu d'experience... au debut, je ne saurai guere trop dire.

J'ai tout d'abord commencé a developper des fonctions (optimisées pour ne pas hesiter a les utiliser) que je pourrais utiliser dans de nombreux programmes.
Le Zelda n'est un assemblage particulier de quelques unes de ces fonctions, ainsi, arreter le Zelda ne me fera pas arreter la programmation en ASM.

bonne methode.

(meme si dans un an ou deux, tu te dira que tes fonctions sont encore optimisables (enfin, je pense))