1

Salut à tous,

Alors alors , dans les docs c'est bien indiqué que l'on peut modifier la vram pdt le display, mais.. ca sous entend peut etre qu'il ne s'agit que des petits modifs concernant le shrink,vert/horizontal pos (SCB234) ?
mais peut etre pas du lourd comme les data en SCB1 ?

quoiqu'il en soit , Je me retrouve avec des glitches lorsque j'update la vram avec une vingtaine de (nouveaux) sprites (SCB1234)

Comme je debute sur neogeo je me pose pas mal de questions sur le coté dynamique de la chose ^^

Ca n'est peut etre pas une bonne idée de vouloir mettre à jour la vram pdt que le LSPC est en train de bosser sur le rendu, est ce qu'a ce moment la , il est préférable de synchroniser le bazar pour effectuer les transferts ? (genre bufferiser les cmd et les enoyer pdt l'attente du vblank par ex)

Peut être aussi que les tranferts en VRAM prennent trop de temps machine et que cela entraine les 'glitches' , pour le moment je n'ai pas trop d'outils pour timer mon code et le rastertime associé.

D'un autre coté si ce n'est pas possible de mettre à jour la vram avec un nombre élevé de sprites c'est un peu embetant pour animer de manière décente plein de sprites à l'écran.

Je veux dire par la que si il faut priviligier un maximum d'éléments statiques en VRAM plutot que d'aller piocher dynamiquement les sprites dont on a besoin c'est un peu domache ^^

PS: je bosse sous mame smile
avatar

2

A quoi ressemblent les glitches?

Je code pas pour la néo geo, et j'arrive pas à me rappeler si c'est elle, mais il y a une console ou tu peux écrire en mémoire vidéo vu que le CPU à la priorité, mais du coup le processeur graphique lit ce qu'il y a sur le bus à ce moment, ce qui donne des artefacts de couleur. Sinon jouer avec la liste de sprites tandis qu'elle est manipulée n'a jamais bien marché sur les consoles 8-16 bits parce qu'ils font des opérations internes sur les sprites (ils copient la liste sur un autre buffer, etc.) et il valait mieux le faire dans la VBLANK.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

3

Rien n'interdit de modifier la VRAM durant le display, mais si tu modifies un sprite actuellement à l'écran tu vas avoir tu tearing/artifacts.

La technique classique sur la machine est de diviser les ressources sprites en deux (onscreen/ offscreen). Tu draw tout tes sprites dans le bloc offscreen, et tu swap les blocs pendant le vblank.

4

Hello les gars et merci pour les infos,

wow il est trop bien ton jeu de bagnoles , je suis fan!! ;-) j'en avais porté un à l'époque sur commodore64 (crazy cars 3) et j'ai tjrs voulu remettre les couverts mais j'ai jamais eu le temps ^^

Oui c'est ce que j'ai remarqué pour les sprites dynamiques et c'est finalement la technique indiquée par HPMAN qui fonctionne, (sorte de double buffering de sprites)

Bon du coup ca limite pas mal de nombre de sprites animés en même temps mais bon ^^

Et sinon (je me doute de la réponse, mais j'ai pas encore de hw à dispo) est ce que ca a du sens d'optimiser du code quand on bosse sous mame ? smile)
avatar

5

Hormis les timer IRQ, mame est plutôt précis donc pas de soucis.

6

Je déterre un topic, sorry

Qu'est ce que vous entendez par offscreen/onscreen ?

Dans le kit neothunder la commande wait_vbl() attend la synchro du rayon en haut d'écran
C'est dans ce bloc que vous voulez faire les updates de sprites pour éviter les glichs ?
Merci d'avance pour vos réponses