Re: [MD] Gens et overscan

par upsilandre Mer 6 Juin 2018 - 0:31

Apres le probleme c'est que pour un scroling horizontal il faut un mode d'auto-incrementation spécial de l'adressage VRAM sinon faut recharger l'adresse a chaque acces et c'est encore plus lent. La megadrive a sans doute ce type de mode d''auto-incrementation (la Master System ne l'a pas par exemple) mais faut peut etre quand meme que tu le declare.

edit: apparement c'est le registre 15 du VDP qui s'occupe de ca

par Hpman Mer 6 Juin 2018 - 0:33

Tryphon a écrit:Bon, ben c'est bien le transfert qui ralentit tout, le reste de la fonction est quasi-invisible.

Ouais, assure toi tout de même que GCC n'ai pas juste tout viré, voyant que tu ne fais rien des données calculées Mr. Green

par **Tryphon** Mer 6 Juin 2018 - 8:58

Oui, je connais l'arnaque Mr. Green

upsi : oui, je connais (ça permet d'optimiser la copie de colonnes). DMA_queueBidule gère l'incrément. J'ai bon espoir d'avoir un truc assez véloce, qui me laissera du temps pour l'IA des persos.

D'ailleurs je me pose une question pour l'IA : elle est gérée par une state machine, avec des fonctions callbacks (des pointeurs sur fonctions dans la struct définissant un "objet"), donc en assembleur, ça se traduit par des jsr indirects.

Je crois que c'est fort lent, un jsr indirect.

Je peux remplacer par une sorte d'énorme switch, mais ça serait beaucoup moins lisible. Ça vaut le coup ?

par Hpman Mer 6 Juin 2018 - 10:26

Faut voir comment c'est gaulé exactement, mais un JSR c'est une 20aine de cycles, pas de quoi en faire une histoire.

par **TotOOntHeMooN** Mer 6 Juin 2018 - 10:27

Pas besoin de se prendre la tête avant de voir le résultat.

par Invité Mer 6 Juin 2018 - 10:31

Autant tout codé en ASM !! Wink

Personnellement, avec Papi Commando Reload, je n'ai jamais utilisé ces techniques d'Overscan et compagnie ... Je faisais à l'oeil avec le ShowFPS de SgdK pour voir si je n'avais pas trop de ralentissements ... Very Happy

par upsilandre Mer 6 Juin 2018 - 12:25

C'est quand meme bien de voir qu'est ce qui prend les ressources pour savoir quoi optimiser surtout quand tu passes par un sdk et que les choses sont donc plus abstraite.

par ichigobankai Mer 6 Juin 2018 - 12:36

Clair que voir la charge par frame et ainsi pouvoir avoir des fps constantes n'est pas complètement inutile.

par Stef Mer 6 Juin 2018 - 14:29

Tryphon a écrit:Je savais, mais je pensais pas à ce point...

Bon, je vais faire un cache en RAM et utiliser DMA_queueDma pour que la copie se fasse pendant la VBlank.

Ah clairement oui c'est comme ça qu'il faut faire Wink

On ne met jamais à jour directement en VRAM pendant la période active, c'est hyper lent même pour une seule ligne / colonne du tilemap. A la base tu l'utilises juste pour du raster effect, pour modifier quelques entrées de CRAM ou VSRAM, ou alors si tu fais une décompression live tellement lente que le transfert VRAM n'est pas le facteur limitant.
La manière classique c'est de décompresser / construire ta map pendant la période active et préparer dans un buffer la colonne ou/et la ligne de tilemap à mettre à jour et tu mets tout ça dans la queue DMA :)

D'ailleurs je me pose une question pour l'IA : elle est gérée par une state machine, avec des fonctions callbacks (des pointeurs sur fonctions dans la struct définissant un "objet"), donc en assembleur, ça se traduit par des jsr indirects.

Je crois que c'est fort lent, un jsr indirect.

Je peux remplacer par une sorte d'énorme switch, mais ça serait beaucoup moins lisible. Ça vaut le coup ?

Pour l'IA, perso j'utiliserai aussi des pointers de fonction également. Comme le dit hpman, même si tu as 20 appels par frame c'est pas la mort Wink

par **Tryphon** Jeu 7 Juin 2018 - 23:53

Merci :)

par **Tryphon** Sam 9 Juin 2018 - 0:29

Implémenté pour le premier plan, en effet, ça dépote ! Je ne vois même pas le jaune (faut que je joue en slow mode, y'a peut-être une ligne...).

Du coup les perfs sont encourageantes. Je touche du bois !