Re: POLE POSITION sur COLECO !

par Invité Dim 13 Sep 2015 - 15:48

Et apparemment ils hesitent pas non plus a transferer en VRAM meme apres la fin du vblank.

Oui si tu transfères les tiles des lignes du bas pendant le balayage ça peut être un bon plan, et ne pas se voir .

par upsilandre Dim 13 Sep 2015 - 15:54

TOUKO a écrit:
Et apparemment ils hesitent pas non plus a transferer en VRAM meme apres la fin du vblank.
Oui si tu transfères les tiles des lignes du bas ça peut être un bon plan, et ne pas se voir .

La route n'est pas dans la partie superieur de l'ecran donc les débordements passe certainement sans probleme (pas en emulation qui est timé sur le vblank et fait apparaître de leger glitch)

par bfg Dim 13 Sep 2015 - 17:05

Ca va pas t'aider mais check Safari Race sur SG1000. La console a ptet plus de ram par contre ... je sais plus ...

par upsilandre Dim 13 Sep 2015 - 17:26

La SG-1000 c'est exactement le meme hardware que la Coleco (CPU, GPU, SPU, RAM, VRAM). C'est pour ca que ca peut servir en cas de manque d'inspiration.

par Invité Lun 14 Sep 2015 - 7:57

Pas con pour Safari Race, je vais regarder :)

par Invité Lun 14 Sep 2015 - 9:43

De toutes façons maintenir un 60 fps pour la route risque d'être très dur .
A moins que ta routine de transfert actuelle soit optimisable, ou sortir du NMI tout ce qui peut l'être pour donner la priorité au transfert de tile ??.

Tu transfères combien de tiles à chaque foi ??

Sur la vidéo, on à l'impression que tu fais ton transfert hors vblank, carrément pendant l'affichage,car seule la route glishe pas le HUD .

La route n'est pas dans la partie superieur de l'ecran donc les débordements passe certainement sans probleme (pas en emulation qui est timé sur le vblank et fait apparaître de leger glitch)

tu oublies la maj du HUD aussi .

par upsilandre Lun 14 Sep 2015 - 11:50

Le hud tu le gère avant ou apres, les solution ne manque pas.
J'ai regardé Safari Race. Ils utilisent la meme technique que Hang On avec le meme nombre de tile pour la route.

Alors "meme technique" c'est vite dit car ils ont quand meme trouvé une alternative. Ils ont dissocié la mise a jour de la pattern 1bpp des tuiles de celle de la color map de chaque tuiles (qui equivaut aussi a 1bpp supplémentaire).
Du coup ils se concentrent principalement sur la mise a jour de la color map pour changer les couleurs des bordures et qui sert a donner la sensation de deplacement et qu'ils font en 5 frames (au lieu de d'une quinzaine sur Hang On).
Par contre la mise a jour des patterns par shifting qui permet de changer la forme de la route elle se fait de facon tres lente, juste un tout petit bout entre 2 cycles complets de changement de la color map. Du coup ca prend des dizaines de frames (environ une seconde).
Et puis que ce soit la color map ou les patterns ils ne font pas l'integralité du coté gauche puis l'integralité du coté droit comme sur Hang On mais les 2 cotés en meme temps.

Donc par rapport a Hang On ils ont un rafraichissement de la forme de la route qui est encore bien plus lent mais un rafraichissement des couleurs des patterns qui lui est bien plus rapide pour mieux ressentir le deplacement.
C'est plutot une facon intelligente d'exploiter le mode video tres particulier du TMS qui permet de dissocier forme et couleur de chaque ligne d'une tuile.

Mais surtout je me rend compte que finalement dans ces methodes ils n'utilisent pas de buffer RAM, apparemment ils vont juste chercher un octet en VRAM, le shift (ou l'inverse pour la color map), puis le remplace en VRAM, tout simplement (ils profitent que sur le TMS9918 on a toujours acces a la VRAM pendant l'affichage) et font ca a priori n'importe quand pendant l'affichage, une fois qu'ils ont traiter le coeur du jeu ils doivent passer tout le reste de la frame a faire ca.

Autre petite difference avec Hang On, la voiture du joueur n'est pas un sprite mais du background (pas de deplacement au pixel) ce qui demande aussi une mise a jour de la tilemap a cette endroit .

par Invité Lun 14 Sep 2015 - 12:09

Si l'affichage des tiles sur coleco est en 4bp, le réduire à 3 pour la route et le HUD va réduire la taille des transferts .
C'est forcement possible vu que safari race sur SG1000 gère en plus un parallaxe sur le décors de fond,et le HUD en semble 2bp pour réduire la taille des transferts .

par upsilandre Lun 14 Sep 2015 - 12:14

TOUKO a écrit:Si l'affichage des tiles sur coleco est en 4bp, le réduire à 3 pour la route et le HUD va réduire la taille des transferts .

C'est 1bpp les tiles coleco + l'equivalent de 1bpp (un octet par ligne) pour definir une palette de 2 couleur pour chaque ligne de chaque tile.
En gros t'as 2 tileset de taille equivalente, celui qui contient les patterns et celui qui contient les couleurs utilisés par ces patterns.

Sinon y a le mode 1 qui lui est juste un mode 1bpp classique mais c'est pas celui utilisé pour les jeux en général.

par Invité Lun 14 Sep 2015 - 12:15

Ah oui, alors le coup de réduire les bp c'est foutu .

par upsilandre Lun 14 Sep 2015 - 12:16

De toute facon dans ce jeu y a pas de transfère de tile RAM > VRAM. Ils modifient directement la VRAM.

par Invité Lun 14 Sep 2015 - 12:18

Je m'en doute, parce qu'avec juste 1ko de ram ça fait juste .
J'avais regardé vite fait le VDP de la coleco y'a un moment de ça, et j'avais déjà vu que tu pouvais transférer pendant l'affichage, c'est plus lent que pendant le vblank mais parfaitement possible .
Il doit y avoir un délais du style 17 cycles entre chaque écriture .

par upsilandre Lun 14 Sep 2015 - 12:26

TOUKO a écrit:Je m'en doute, parce qu'avec juste 1ko de ram ça fait juste .
J'avais regardé vite fait le VDP de la coleco y'a un moment de ça, et j'avais déjà vu que tu pouvais transférer pendant l'affichage, c'est plus lent que pendant le vblank mais parfaitement possible .
Il doit y avoir un délais du style 17 cycles entre chaque écriture .

C'est simple c'est la meme situation que sur SMS (qui est une evolution du TMS9918) et avec les meme timing et frequence que sur Master System. Si je ne m'abuse tu peux transférer aussi vite que sur une SMS (mais avec des data graphiques plus leger ce qui ouvre pas mal de possibilité)

par Invité Lun 14 Sep 2015 - 12:30

Oui, c'est de ça que je tiens mes 17 cycles de délai Wink

D'ailleurs d'après des codeurs SMS le CPU de la SMS n'est capable de n'utiliser que 20% de la BP du TMS, donc ça devrait pas poser de soucis sur coleco et ses tiles en 2bp .

En plus effectivement y'a moyen de jouer avec pour transférer juste les 1bp nécessaire .

par upsilandre Lun 14 Sep 2015 - 12:45

Moi dans mes notes j'avais 29 cycles d'attente entre chaque acces VRAM pendant l'affichage (17 cycle c'est plutot pendant le vblank).
Mais les cycles partent vite avec le Z80 donc t'as pas de mal a l'occuper pendant ce temps surtout que la y a du traitement a faire au moins pendant la phase entre la lecture et l'ecriture.

par Invité Lun 14 Sep 2015 - 12:52

En tout cas, merci de vos recherches, je viens aussi de regarder Safari et le coup de la palette de couleur, c'est pas con du tout ça quand le décors bouge pas ...

par Invité Lun 14 Sep 2015 - 13:36

alekmaul a écrit:En tout cas, merci de vos recherches, je viens aussi de regarder Safari et le coup de la palette de couleur, c'est pas con du tout ça quand le décors bouge pas ...

Mais même quand il bouge Wink

par upsilandre Lun 14 Sep 2015 - 13:41

Cela dit quelle que soit la solution on voit quand meme que ca rend pas terrible.

Y a une difference fondamentale entre ces exemples et les vrais jeux du genre qui utilisent un raster effect c'est qu'ici c'est le sprite du joueur qui se déplace lateralement sur la route qui elle reste tres statique comme les vieux jeux pré-raster effect alors que dans les vrais pole position (meme sur Atari 2600) ou Hang On (meme sur SMS) le joueur reste au centre de l'ecran, c'est la route qui se translate en meme temps quelle se déforme et ca donne une sensation bien differente et bien plus dynamique mais pas possible ici a cause du trop faible rafraichissement de la route.
Du coup c'est ca qu'il faudrait réussir a reproduire pour se distinguer.

par Invité Lun 14 Sep 2015 - 14:17

De toutes façon si alek code ça en C ça va être difficile à optimiser, il faut absolument une routine en ASM pour faire le moins de concessions possibles .

par Invité Lun 14 Sep 2015 - 15:06

Le C généré par sdcc est très propre touko, t'inquiètes pas.
Sinon, effectivement, je coderai la routine en ASM s'il faut, je connais bien le z80

par Invité Lun 14 Sep 2015 - 16:02

alekmaul a écrit:Le C généré par sdcc est très propre touko, t'inquiètes pas.
Sinon, effectivement, je coderai la routine en ASM s'il faut, je connais bien le z80

Nan mais j'en doute pas, reste à voir si ce genre de routine n'est pas plus optimisable en ASM ..

Mais au final, tu créais l'impression de défilement de la route avec du swap de tiles,même quand elle est droite ??? pale

par Invité Lun 14 Sep 2015 - 17:02

oui, swap de tiles avec 4 défilements et 3 types de courbes.

par Invité Lun 14 Sep 2015 - 18:08

bah déjà supprimes le défilement, remplaces le par le swap de couleurs pour le défilement des bordures de la routes et de l'herbe (avec un timer pour la vitesse) et laisses juste celui pour les courbes,ça limitera les transfert à la seule route qui courbe .
Tu as juste à organiser ta palette pour que les couleurs à swapper se suivent .
Faut juste penser a ne pas les utiliser pour autre chose que la route .

Gros avantage le swap peut être fait pendant l'affichage en RAM, il restera plus que la maj de la palette à faire pendant le vblank.

par upsilandre Lun 14 Sep 2015 - 19:20

Ca marche pas comme ca le mode 2. Pour le bg y a pas 2 palettes 16 couleurs comme sur SMS que tu peux mettre a jour pour faire du color swap et modifier toutes l'images d'un coup.
La juste pour la route de Hang-on ou rally y a 2500 palettes, une palette 2 couleurs pour chaque ligne de chaque tile. T'as d'un coté le tileset et de l'autre la color map qui fait exactement le meme poid que le tileset.
Donc pour la partie ligne droite j'imagine qu'il modifie juste la color map (mais c'est deja comme modifier un tileset) et pour la courbe faut modifier les 2.

par Invité Lun 14 Sep 2015 - 20:02

T'as d'un coté le tileset et de l'autre la color map qui fait exactement le meme poid que le tileset.
Donc pour la partie ligne droite j'imagine qu'il modifie juste la color map (mais c'est deja comme modifier un tileset) et pour la courbe faut modifier les 2.

CAD ??, t'as pas de color RAM en fait ??, C'est la couleur qui est paramétrée dans le tilemap et non une palette ??
Ah putin, c'est trop la merde alors .. Shocked

par Invité Lun 14 Sep 2015 - 20:04

non, je modie les 2 mais je pourrais effectivement optimiser en modifiant uniquement la colormap.
SInon touko, les timers, y'a pas, ça n'existe pas sur Coleco.
Et pour les courbes, bah oui, faut modifier le tileset en 1bpp et la colormap pour ce tileset, donc le double de boulot ...

par Invité Lun 14 Sep 2015 - 20:08

les timers, y'a pas, ça n'existe pas sur Coleco.

je parlais de timers software, des compteurs quoi tongue

Et pour les courbes, bah oui, faut modifier le tileset en 1bpp et la colormap pour ce tileset, donc le double de boulot ...

je comprends mieux le pk de l'animation du scrolling via les tiles Confused

par Invité Lun 14 Sep 2015 - 20:26

Ok pour les timers ^^ c'est déjà comme cela en fait :)
Faut que je réfléchisse à Safari Race et son implémentation de rendu de la vitesse, cette histoire de modifier uniquement la colormap me fait des nœuds au cerveau mais j'aime ça ...

par Fabf Lun 14 Sep 2015 - 20:58

upsilandre a écrit:Ca marche pas comme ca le mode 2.

Pourquoi tu utilises pas le mode 1 ?
Là tu peux juste changer les tiles déjà colorisées.
En plus il me semble que tu peux définir 2 jeux de tiles.

par Invité Lun 14 Sep 2015 - 21:02

alekmaul a écrit:Ok pour les timers ^^ c'est déjà comme cela en fait :)
Faut que je réfléchisse à Safari Race et son implémentation de rendu de la vitesse, cette histoire de modifier uniquement la colormap me fait des nœuds au cerveau mais j'aime ça ...

Et je suppose en plus que l'autoincrémentation de la VRAM est fixe ??