demo26 d'ExtGraph... - Page 2

Tiens, salut TImad/trust/JackosKing et Thibaut

@PpHd: Sasume dit qu'il y avait un bench genlib/extgraph/xlib, mais il n'existe plus dans la dernière version de genlib... Tu n'aurais pas une sauvegarde dans un coin ? J'ai bien retrouvé ce programme, moi
(Au pire, sans vouloir fâcher "JS", on peut enlever XLib, si les perfs ne sont pas représentatives de la dernière version beta unreleased... Ceux qui la connaissent savent qu'XLib dispose de la routine de sprite 16 la plus rapide, même si sa taille est également hors normes !)

C'est bon en fait, tout est là : http://www.yntoo.com/t3/dl.php?f=genlib-v09922b.zip&d=archives/Librairies/Genlib/Old/

./30: Parce qu'avec un double buffer, tu peux te dermerder pour que le temps de synchro soit nul.

Oui, mais moins facilement qu'avec un triple... non ?

Oui, mais de toute façon il n'est pas intéressant de faire tourner son jeu à plus de 30 fps, si ?
Donc au final la synchro n'est pas un pb...
De plus, j'imagine que dans tout jeu qui se respecte, il est de toute façon nécessaire de solliciter le processeur pour divers calculs entre deux frames (IA, physique, etc.) donc l'attente de la synchro est encore moins présente...

Oui mais l'idée c'est justement de supprimer ce temps d'attente...OK c'est pas tout le temps nécessaire, mais si ton jeu est chargé en temps de calcul autant éviter de perdre du temps en attendant la synchro.

> Oui, mais de toute façon il n'est pas intéressant de faire tourner son jeu à plus de 30 fps, si ?
Non, et je dirais même 20 FPS, l'écran étant plutôt mauvais

ben si, pour des raisons de motion blur : si tu affiches deux frames entre lesquels un objet a avancé de 30 pixels, l'oeil va rien "comprendre", il va juste voir l'objet apparaître et disparaître à plusieurs endroits de l'écran ; si tu peux afficher des frames intermédiaires, même avec l'écran baveux, ça permet de voir que l'objet est allé du point a au point b ^^ (par contre l'inconvénient c'est qu'on peut perdre en lisibilité, mais c'est un peu inévitable avec un écran comme ça)

évidemment, ça dépend du type de mouvement que tu as : si chaque objet se déplace de moins de 2 pixels par frame, ça sera fluide même à 15 fps

./37: Il faut bien assurer une synchro pour eviter que ton jeu ne saccade, et tu peux mixer les deux synchros.

./39: 30 pixels/image * 20 images/s = 600 pixels/seconde. Donc ton truc va passer moins de 1/3 de seconde a l'ecran. Et tu verras juste une fusée... Revois tes arguments, non ?

c'était pas un chiffre à prendre au sens littéral, un peu comme si je disais "50000 sprites à l'écran" pour dire "plein de sprites à l'écran"...

50000, tant que ça ?? Eh bé !

Meme une NES ou un GB n'en est pas capable

Suffit de faire des sprites de 1 pixel par 1 pixel
Ca me rappelle les bench de sony, cette astuce

JackosKing :
Pour l'échange des pointeurs ca ne marchait que sur HW1 il me semble non?

Il me semble que oui.
En fait, l'écran de la HW2 est géré complètement différemment. Quand tu écris dans la ram à $4C00, il écrit dans la ram *et* dans un ptit bout de ram non accessible autrement.
L'écran va lire ce ptit bout de ram pour s'afficher (ça économise le bus de données, et je crois que c'est pour ça que la 92+ est plus rapide)

Du coup, même si tu changes le pointeur de l'écran, sur la hw1 l'écran changeait la zone à afficher, alors que sur la hw2, le contenu de la ram d'affichage ne change pas. C'est juste qu'il faudra écrire à $5C00 (?) au lieu de $4C00 pour écrire dessus

Salut Flanker

Il est en effet possible de changer l'endroit où le support écran du HW2 lit les données (4C00, 5C00, 6C00, 7C00), mais absolument pas pratique, car AMS met toutes ses variables internes dans cette zone. ExtendeD utilise cela pour un de ses programmes (Sim ?), mais c'est très lent, car il faut tout sauver/restaurer à chaque fois.

Lionel Debroux :
Il est en effet possible de changer l'endroit où le support écran du HW2 lit les données (4C00, 5C00, 6C00, 7C00), mais absolument pas pratique, car AMS met toutes ses variables internes dans cette zone. ExtendeD utilise cela pour un de ses programmes (Sim ?), mais c'est très lent, car il faut tout sauver/restaurer à chaque fois.

C'est peut etre débile mon idée, mais :

Quand on lance un prog asm (pas une app flash) on est pas contraint, tant que l'application tourne, de respecter "completement" l'AMS. Cad que empeche toute execution du code d'ams "sensible" a l"organisation mémoire.

Donc on pourrais copier ces variables de l'AMS dans une autre région mémoire, et donc derriere utiliser ces zones...

Apres faudrais vraiment en avoir une utilitée...

quand c'est ton propre code asm et que tu ne fais appel à aucune fonction système, effectivement, ça marche

Godzil
:

Lionel Debroux :
Il est en effet possible de changer l'endroit où le support écran du HW2 lit les données (4C00, 5C00, 6C00, 7C00), mais absolument pas pratique, car AMS met toutes ses variables internes dans cette zone. ExtendeD utilise cela pour un de ses programmes (Sim ?), mais c'est très lent, car il faut tout sauver/restaurer à chaque fois.

C'est peut etre débile mon idée, mais :

Quand on lance un prog asm (pas une app flash) on est pas contraint, tant que l'application tourne, de respecter "completement" l'AMS. Cad que empeche toute execution du code d'ams "sensible" a l"organisation mémoire.

Donc on pourrais copier ces variables de l'AMS dans une autre région mémoire, et donc derriere utiliser ces zones...

Apres faudrais vraiment en avoir une utilitée...

ben oui mais le controleur ne rechargerait pas pour autant les zones memoires 5C00 & Cie : Pour autant que je me souvienne, la RAM est recopiée dans la memoire interne du controleur juste quand on ecrit dans la zone écoutée (4c00, 5c00, etc..)

Flanker :
quand c'est ton propre code asm et que tu ne fais appel à aucune fonction système, effectivement, ça marche

et que tu as remplacé toutes les interruptions par les tiennes ^^

Oui Pen². Je crois qu'en réalité le contrôleur mémoire de l'écran se déclenche quand le bus d'adresse contient l'adresse de l'écran et que le mode écriture apparaît sur le bus de contrôle. Le contrôleur lit alors ce qui arrive sur le bus de données.

Donc en fait, les données ne sont pas "recopiées dès qu'on écrit", elles sont "reçues à la fois par la RAM et le contrôleur de l'écran". S'il n'y avait pas physiquement de RAM à $4C00, ça ne changerait rien, ça marcherait tout aussi bien.

En effet, ça fonctionnerait si le programme n'appelle aucune fonction d'AMS... mais comme c'est la recopie dans les zones qui déclenche la mise à jour, ça ne changerait pas grand chose, malheureusement...