Re: Sgdk - Sega Megadrive / Genesis Development Kit

[pckid]

J'ai une question de résolutions sur sgdk

Si j'ai bien compris la Megadrive en Pal affiche 320x240
Et 320x224 en 60hz, je pensais le contraire du aux bandes noires.

Aujourd'hui il faut partir sur le 60hz soit 320x224, que se passe t'il si on passe en 50hz ?

Quelle résolution choisissez vous pour vos jeux. ?
Merci

[TotOOntHeMooN]

J'ai une question de résolutions sur sgdk

Si j'ai bien compris la Megadrive en Pal affiche 320x240
Et 320x224 en 60hz, je pensais le contraire du aux bandes noires.

Aujourd'hui il faut partir sur le 60hz soit 320x224, que se passe t'il si on passe en 50hz ?

Quelle résolution choisissez vous pour vos jeux. ?
Merci

Alors, "normalement" :

320x224 = bandes noires en 50Hz
320x240 = pas de bandes noires en 50Hz mais pas compatible 60Hz

En gros, "tout le monde" fait du 320x224 (voir joue aujourd'hui en 60Hz) ... Sauf si tu veux gérer un mode spécial.
(car tu peux aussi faire du 256x224 et du 256x240 pour un look "8-bit")

[Invité]

J'ai une question de résolutions sur sgdk

Si j'ai bien compris la Megadrive en Pal affiche 320x240
Et 320x224 en 60hz, je pensais le contraire du aux bandes noires.

Aujourd'hui il faut partir sur le 60hz soit 320x224, que se passe t'il si on passe en 50hz ?

Quelle résolution choisissez vous pour vos jeux. ?
Merci

Que ce soit sur Md ou snes il y a un intérêt à utiliser le pal, outre le fait que tu gagnes 16 pixels en vertical, tu doubles presque le budget DMA pendant le vblank.
Donc c'est à voir en fonction de ton projet, privilégier le petit surplus de fluidité due au rafraîchissement, ou avoir un jeu plus riche niveau animations .

[tetsuro]

Yo @Stef, un petit retour pour te dire qu'à la page d'installation du SGDK avec CodeBlocks, t'as mis une vidéo tuto d'un YouTuber, son tuto ne fonctionne pas pour moi, c'est le tiens qui fonctionne, donc ne le retire pas ! :)
Et dans ta page des docs, tout les lies sont morts.

[Stef]

Merci, j'ai tout corrigé

[pckid]

J'ai une question de résolutions sur sgdk

Si j'ai bien compris la Megadrive en Pal affiche 320x240
Et 320x224 en 60hz, je pensais le contraire du aux bandes noires.

Aujourd'hui il faut partir sur le 60hz soit 320x224, que se passe t'il si on passe en 50hz ?

Quelle résolution choisissez vous pour vos jeux. ?
Merci

Alors, "normalement" :

320x224 = bandes noires en 50Hz
320x240 = pas de bandes noires en 50Hz mais pas compatible 60Hz

En gros, "tout le monde" fait du 320x224 (voir joue aujourd'hui en 60Hz) ... Sauf si tu veux gérer un mode spécial.
(car tu peux aussi faire du 256x224 et du 256x240 pour un look "8-bit")

Merci toto, tu penses que je peux le tester pour avoir la preuve avec une image de fonds?

[TotOOntHeMooN]

Je ne vois pas ce qui t'empèche de faire des tests, tu ne vas rien casser... Si tu pensais le contraire c'est juste parce que la fréquence F = 1/T (soit l'inverse de la base de temps).

[pckid]

Je ne vois pas ce qui t'empèche de faire des tests, tu ne vas rien casser... Si tu pensais le contraire c'est juste parce que la fréquence F = 1/T (soit l'inverse de la base de temps).

regardes la doc, c'est la que j'ai une confusion en page 2. (si genesis => 60hz)

https://segaretro.org/images/a/a2/Genesis_Software_Manual.pdf

[TotOOntHeMooN]

regardes la doc, c'est la que j'ai une confusion en page 2. (si genesis => 60hz)
https://segaretro.org/images/a/a2/Genesis_Software_Manual.pdf

Que se soit en deuxième page de la doc, ou en page 2 de la doc, je ne vois pas de quoi tu parles. Par contre, page 6, il est indiqué qu'en PAL (TV européennes en 50Hz) tu disposes de 30 CELLs de haut, soit 240 lignes. Résumé en page 7.

[pckid]

regardes la doc, c'est la que j'ai une confusion en page 2. (si genesis => 60hz)
https://segaretro.org/images/a/a2/Genesis_Software_Manual.pdf

Que se soit en deuxième page de la doc, ou en page 2 de la doc, je ne vois pas de quoi tu parles. Par contre, page 6, il est indiqué qu'en PAL (TV européennes en 50Hz) tu disposes de 30 CELLs de haut, soit 240 lignes. Résumé en page 7.

Donc la résolution est moins grande en 60hz (peut etre probleme de rafraichissement)

50hz  Pal_ affiche 320x240
60hz  Ntsc affiche 320x224

[TotOOntHeMooN]

Tout est expliqué dans la doc. (en 50Hz tu peux aussi bien utiliser 224 que 240)

Après, il est normal que si tu disposes de plus de temps pour parcourir une surface (l'écran), tu as le temps d'y tracer plus de lignes... Et que dans le cas ou tu décides d'en tracer autant, il te reste du vide avant d'arriver à la fin.

[pckid]

Tout est expliqué dans la doc. (en 50Hz tu peux aussi bien utiliser 224 que 240)

Après, il est normal que si tu disposes de plus de temps pour parcourir une surface (l'écran), tu as le temps d'y tracer plus de lignes... Et que dans le cas ou tu décides d'en tracer autant, il te reste du vide avant d'arriver à la fin.

Oui c'est normal pour le parcours, mais comme moi tu trouvais logique l'inverse.

on reste sur : 320x224 pour les deux fréquences.

merci à toi

[TotOOntHeMooN]

mais comme moi tu trouvais logique l'inverse.

Je ne trouve pas logique l'inverse, mais je comprends qu'on puisse le penser. (si l'on a pas fait d'électronique par exemple)
Rester sur du 224 permet de ne pas avoir à gérer de spécificité, sachant qu'aujourd'hui "tout le monde" joue en 60Hz.

[Orion_]

hop, je voulais vous faire part d'une petite info, jusqu'a maintenant j'utilisais le compilateur C: VBCC
parcequ'il était plus léger que GCC, qu'il était censé être plus rapide que GCC 2.x.x, et surtout qu'on pouvais assigner les paramètres d'une fonction directement à des registres (ultra pratique quand on a des fonctions en assembleur, ça évite de passer par la stack)
le problème c'est que le code généré était quand même pas top, même pas top du tout.
et après avoir fait un test avec le dernier GCC 8, le code généré est largement mieux, donc j'ai passé la journée a trouver un moyen de passer a GCC 8, et c'est carrément plus rapide.
sans changer mon code C, je gagne 14 lignes horizontales (HBL) de temps machine sur mon moteur de jeu actuel, qui pourtant n'est pas encore très intensif.
j'imagine que pour des jeux intensif comme un shoot'em up, ça peut carrément changer la donne, surtout si on vise du 60 fps.

On peut télécharger GCC 8.2.1 pour m68k ici (a prendre avec les binutils aussi)
http://tho-otto.de/crossmint.php

et voila comment je me suis débrouillé pour la compilation:

Code:

m68k-atari-mint-gcc-8.2.1 -mcpu=68000 -fomit-frame-pointer -ffreestanding -O2 -c Game.c
m68k-atari-mint-ld -nostdlib --oformat binary -T link.txt -o Game.bin cartbase.o Game.o

Le fichier link.txt
SECTIONS
{
  . = 0x0;
  .text : { *(.text) }
  .data : { *(.data) }
  . = 0xFF0000;
  .bss : { *(.bss) }
}


cartbase.o c'est un fichier assembleur avec l'entête et le boot de la megadrive.
pour le moment je le compile avec RMAC qui est un assembleur pour Atari Jaguar: rmac -fb -u cartbase.s
mais je vais voir si y'a pas moyen de switcher avec VASM de VBCC
si vous avez un entête compilé avec la syntaxe GCC, il faut utiliser AS.

concernant le binding assembleur, si vous utilisez déja la syntax GCC et la stack, aucun changement a faire.
si par contre vous le faite à l'ancienne avec des registres, voila comment je fait:

Pour un code qui ne demande aucun retour de valeur:

Code:

static inline void   SpriteDraw(s16 x, s16 y, u16 tile, u16 size)
{
   register s16   rx asm("d0") = x;
   register s16   ry asm("d1") = y;
   register u16   rtile asm("d2") = tile;
   register u16   rsize asm("d3") = size;
   asm volatile (
   "jsr   SpriteDraw"
   : "=r"(rx), "=r"(ry), "=r"(rtile), "=r"(rsize)
   : "r"(rx), "r"(ry), "r"(rtile), "r"(rsize)
   : "d4", "d5", "a0", "cc");   // ici ce sont les registres détruit par la fonction SpriteDraw
}

 .globl SpriteDraw
SpriteDraw: ; d0=x d1=y, d2=tile, d3=size
 ...
 rts


Pour une fonction qui renvoi une valeur c'est un peu différent:

Code:

static inline u16   ReadFromVRAM(u16 vram_adrs)
{
   register int   retvalue asm("d0");
   register u16   rvram_adrs asm("d0") = vram_adrs;
   asm volatile (
      "jsr   ReadFromVRAM"
   : "=r"(retvalue), "=r"(rvram_adrs)
   : "r"(rvram_adrs)
   : "a0", "cc", "memory");
   return (retvalue);
}

; ReadFromVRAM
; d0 = Vram Address
; return word data

 .globl ReadFromVRAM
ReadFromVRAM:
 bsr SetVramAddressRead
 lea VDP_DATA,a0
 move.w (a0),d0
 rts

Au final, avec cette méthode on peu continuer a passer les paramètres de fonctions par registre, ce qui fait gagner du temps, et on peu même spécifier quel registres sont détruit par la fonction appelée, ce qui permet a GCC d'optimiser au maximum le code en fonction des registres dispo !

voila, en espérant que ça puisse servir à quelqu'un, voir peut être même permettre de switcher SGDK sur GCC 8 (si ce n'est pas déjà fait)

[Stef]

Merci pour ton retour sur GCC 8 :)
En fait par le passé j'avais plusieurs fois tenté de passer à VBCC mais même comparé à GCC 3.4.6 je trouvais que le code généré était pas génial, du coup je suis toujours resté avec GCC pour SGDK.
Et depuis quelques temps SGDK est passé à GCC 6.3 qui a apporté un gros gain de perf, on m'a dit que GCC 7 et GCC 8 améliorait encore un peu les performances mais franchement je suis déjà assez satisfait de ce que produit GCC 6.3
Si le passage à GCC 8 n'alourdit pas trop les binaires j'y passerai surement aussi un moment mais disons que GCC 6 fait déjà bien le taf :)

Sinon voici les paramètres qui me permettent d'avoir le code le plus rapide (mais certainement pas le plus petit ^^) :
-m68000 -fno-builtin -O3 -fuse-linker-plugin -fno-web -fno-gcse -fno-unit-at-a-time -fomit-frame-pointer -flto

Le FLTO est facultatif mais très pratique quand même :)
En fait il y a encore moyen de gagner un peu en perf en utilisant aussi le flag -mshort (ça permet de passer en 16 bit sur les params en stack plutot que le 32 bit imposé par défaut), je le ferai peut être un jour dans SGDK (mais ça me demande beaucoup de changements).

[Orion_]

j'ai essayé tes paramètres et ça me fait gagner encore 3 HBL, merci :)
je pense que ce qui te ferais gagner le plus de temps serait de passer tes paramètres par registre, ça évite la double opération de passer les données sur la stack puis de les récupérer dans les registres.
j'ai édité mon post si dessus ce matin pour ajouter une optim qui permet de spécifier directement les registres pour les paramètres de la fonction, alors qu'avant j'avais mis du code asm en plus pour passer les paramètres vers les registres que j'avais besoin.
entre temps on m'a donné la bonne syntaxe ce qui m'a permis de virer ce bout de code en plus, et du coup j'ai encore gagné 2 HBL sans changer mon code principal.

[Stef]

j'ai essayé tes paramètres et ça me fait gagner encore 3 HBL, merci :)
je pense que ce qui te ferais gagner le plus de temps serait de passer tes paramètres par registre, ça évite la double opération de passer les données sur la stack puis de les récupérer dans les registres.
j'ai édité mon post si dessus ce matin pour ajouter une optim qui permet de spécifier directement les registres pour les paramètres de la fonction, alors qu'avant j'avais mis du code asm en plus pour passer les paramètres vers les registres que j'avais besoin.
entre temps on m'a donné la bonne syntaxe ce qui m'a permis de virer ce bout de code en plus, et du coup j'ai encore gagné 2 HBL sans changer mon code principal.

Oui effectivement le passage par registre plutot que sur le stack permet de gagner et j'avais déjà fait des macros pour ça (un peu comme les tiennes) mais au final avec le LTO tu n'as plus trop besoin de ça. Ce qui te bouffe du CPU sur le passage de paramètres, c'est les fonctions que tu vas appeler très souvent (au moins 10x par frame) et dans ce cas avec le LTO + l'optimisation, GCC va souvent inliner de lui-même ces méthodes (surtout les méthodes static) donc je ne m'embête même plus avec ça (enfin disons que j'en ai pas encore besoin pour l'instant)

[TotOOntHeMooN]

Ah ! Si tous les programmeurs passaient autant de temps à optimiser le game play et paufiner le game design que leur code...

[Orion_]

mais au final avec le LTO tu n'as plus trop besoin de ça

j'ai essayé l'option LTO mais GCC 8 me met une erreur, c'est le seul flag que je n'ai pas pu mettre dans tout ceux que tu m'a cité.

Ah ! Si tous les programmeurs passaient autant de temps à optimiser le game play et paufiner le game design que leur code...

rajouter du gameplay interessant et du game design demande plus de temps machine, donc c'est justement pour ajouter plein de petite chose en plus dans mon jeu que j'optimise d'abord le code généré.

[Stef]

mais au final avec le LTO tu n'as plus trop besoin de ça

j'ai essayé l'option LTO mais GCC 8 me met une erreur, c'est le seul flag que je n'ai pas pu mettre dans tout ceux que tu m'a cité.

C'est la plus difficile à faire passer il faut le plugin LTO pour GCC (chez moi c'est le fichier liblto_plugin-0.dll) sinon tu ne peux pas l'activer.

[Orion_]

désolé de polluer le topic mais j'ai encore une petite question technique
Je voulais faire un scrolling différentiel sur Megadrive en changeant la valeur du HScroll en milieu d'écran.
Bon, réflexe de programmeur Atari ST, j'étais parti sur une routine d'interruption horizontale quand je me suis souvenu en cours de route que la megadrive gère le scrolling par ligne grace a une zone mémoire dédié en VRAM ...
bref, le soucis c'est que je souhaite faire ça sur un seul plan, mais quand on active le scrolling par ligne, il faut mettre a jour 224 valeurs * 2 plans, ce qui fait beaucoup, surtout si un des plan n'utilise pas le scrolling par ligne, il faut quand même répéter la même valeur 224 fois.
Du coup je suis parti sur un truc plutôt vorace en place mémoire (à la démomaker) mais a mon avis le plus rapide (et puis on s'en fou, y'a de la place en ROM)
mais est-ce vraiment le plus rapide ? n'étant pas un spécialiste de la console, je pose la question :)

Code:


   ; d1/d2/d3 = HScroll Values for Layer B
   ; d4 = HScroll Value for Layer A

SetHScrollValues:
   move.w   #VRAM_HSCROLL,d0
   bsr   SetVramAddress

   lea   VDP_DATA,a0

   REPT   158
   move.w   d4,(a0)   ; A
   move.w   d1,(a0)   ; B1
   ENDR

   REPT   180-158
   move.w   d4,(a0)   ; A
   move.w   d2,(a0)   ; B2
   ENDR

   REPT   224-180
   move.w   d4,(a0)   ; A
   move.w   d3,(a0)   ; B3
   ENDR
   rts

[Stef]

Tu as aussi un mode de scrolling "par tile" donc si tu peux aligner ton scrolling différentiel sur un multiple de 8 pixels, tu n'as besoin que de remplir 224/8 lignes pour chaque plan.
Aussi je te recommande d'utiliser un buffer en RAM que ta balanceras via le DMA en VRAM, ça économisera un peu du faible budget "transfert VRAM" pendant le VBlank (l'air de rien ça bouffe pas loin de 1 ko par frame pour mettre à jour les 2 tables de scrolling complète).

Tu as aussi la possibilité d'utiliser le DMA Fill pour remplir ta table de scroll (si l'un de tes 2 plans n'a pas besoin du scrolling par ligne) mais le problème c'est que la VRAM se rempli "par byte" du coup il faudrait faire 2 DMA Fill avec les problèmes que ça pose (tu perds un peu l'intérêt du fill gratuit).

[Tryphon]

Du coup, c'est pas plus efficace sa première idée avec une HInt ?

[Stef]

Du coup, c'est pas plus efficace sa première idée avec une HInt ?

S'il y a très peu de coupure de scrolling (< 5 ou 6) oui c'est surement plus efficace (avec quand même les problèmes d'anticiper correctement les h-int, je l'avais évoqué dans un autre topic). Si tu peux utiliser le scrolling par tile par contre je pense qu'il faut l'utiliser quand même...

[Orion_]

Tu as aussi un mode de scrolling "par tile" donc si tu peux aligner ton scrolling différentiel sur un multiple de 8 pixels, tu n'as besoin que de remplir 224/8 lignes pour chaque plan.

ah, je ne savais pas ! j'avais commencer a modifier légèrement mes graphismes pour les aligner sur 8 pixels parceque je m'étais dit que cela me permettrait d'économiser du temps avec ma Hint que je déclancherais toute les 8 lignes et pas tout les lignes.
je vais regarder ça !

Aussi je te recommande d'utiliser un buffer en RAM que ta balanceras via le DMA en VRAM

Mais de toute façon il faudrat que je mette a jour ce buffer en RAM aussi, donc tant qu'a balancer des valeurs a coup de move.w en RAM, autant le faire direct en VRAM non ? parceque la on prend le surcout du setup DMA + transfer DMA.
(a moins que tu parle d'économiser du temps VBL, seul endroit ou on peut mettre a jour la VRAM ? dans ce cas ok je comprend)

[Stef]

Mais de toute façon il faudrat que je mette a jour ce buffer en RAM aussi, donc tant qu'a balancer des valeurs a coup de move.w en RAM, autant le faire direct en VRAM non ? parceque la on prend le surcout du setup DMA + transfer DMA.
(a moins que tu parle d'économiser du temps VBL, seul endroit ou on peut mettre a jour la VRAM ? dans ce cas ok je comprend)

Pour 2 raisons:
- Le transfert pendant le VBlank est *beaucoup* plus rapide, tu vas perdre énormément de cycles à faire un transfert pendant l'affichage (c'est possible mais définitivement déconseillé).
- Pendant le VBlank donc, le DMA transfère bien plus vite que le 68000 (même avec une routine super optimisée avec du move.l à gogo, tu resteras environ 2x plus lent que le DMA).

Donc en général ce qu'on fait c'est qu'on prépare tout les buffers en RAM pendant l'affichage avec le 68000 et au V-Blank on envoi tout ça au VDP via le DMA (avec un DMA queue si on veut vraiment tout bien optimiser).

[Orion_]

d'accord, merci pour l'info, je vais voir ça, je pense que j'ai encore de quoi optimiser mon code ailleurs avant d'attaquer des optims plus poussé coté hardware.
en tout cas, malgrès les pauvres 8mhz de la MD, et mon code de gameplay qui dépasse les 2000 lignes de code C maintenant, je vois qu'il me reste encore un bon 50% de temps machine, la MD déchire :p
J'ai pas trop l'habitude vu que sur Jaguar et ST on passe son temps a lancer le blitter pour l'affichage et ça bouffe 75% du temps machine ...

[Orion_]

en fait le mode "défilement par tile" ça ne change pas le nombre de donnée a transferer en VRAM
parceque je m'apperçois que les valeurs doivent être toute les 8 lignes ...
ça fait genre: A/B/_/_/_/_/_/_/_/A/B/_/_/_/_/_/_/_/A/B/_/_/_/_/_/_/_
donc ça fait moins de donnée a écrire en RAM (on laisse les blancs) mais lors du transfer en VRAM, faut quand même envoyer 224*2*2 octets ..
ou alors faire ça en 2 transfers avec un incrément de 8*2

EDIT: bon du coup ça fonctionne bien comme ça, et c'est rapide :)
et ça claque bien quand même le scrolling diff

Code:


   ; a0 = HScroll Values Table for Layer B
   ; d1 = HScroll Value for Layer A
   ; d2 = CurWorld

SetHScrollValues:
   move.w   #$8F20,VDP_CTRL      ; VDP Address Auto Increment = 32 (skip 8 lines * 2 layers * word)

   move.w   #VRAM_HSCROLL,d0   ; Layer A
   bsr   SetVramAddress
   lea   VDP_DATA,a1

   REPT   224/8
   move.w   d1,(a1)         ; Always Same Value for Layer A (Game Field)
   ENDR

   move.w   #VRAM_HSCROLL+2,d0   ; Layer B
   bsr   SetVramAddress

   lea   SetHScrollValuesPtr(pc),a2
   add.w   d2,d2
   add.w   d2,d2         ; *long
   move.l   (a2,d2.w),a2
   jsr   (a2)

   move.w   #$8F02,VDP_CTRL      ; Restore VDP Address Auto Increment = 2 (next tile)
   rts

SetHScrollValuesPtr:
   dc.l   SetHScrollValuesW0,SetHScrollValuesW1,SetHScrollValuesW2,SetHScrollValuesW3

SetHScrollValuesW0:
   move.w   (a0)+,d2
   move.w   d2,(a1)
   move.w   d2,(a1)
   move.w   (a0)+,d2
   move.w   d2,(a1)
   move.w   d2,(a1)
   move.w   (a0)+,d2
   move.w   d2,(a1)
   move.w   d2,(a1)
   move.w   (a0)+,d2
   move.w   d2,(a1)
   move.w   d2,(a1)
   move.w   (a0)+,d2
   move.w   d2,(a1)
   move.w   d2,(a1)
   move.w   (a0)+,d2
   move.w   d2,(a1)
   move.w   d2,(a1)
   move.w   (a0)+,d2
   move.w   d2,(a1)
   move.w   d2,(a1)
   move.w   (a0)+,d2
   REPT   5
   move.w   d2,(a1)
   ENDR
   move.w   (a0)+,d2
   REPT   3
   move.w   d2,(a1)
   ENDR
   move.w   (a0),d2
   REPT   6
   move.w   d2,(a1)
   ENDR
   rts


[Stef]

Et oui la MD elle déchire avec son "petit" 68000 :p

Sinon oui tu as bien compris la méthode, il faut régler le step correctement et le faire en 2 transferts (mais ça reste rapide quand même).

[Hpman]

J'ai un petit souci avec GCC:


C'est ma syntaxe ou GCC il fait nimp?

Parce que "(~x)>>4" c'est pas pareil que "~(x>>4)" 

[Tryphon]

Ben déjà, si c'est un define, c'est bizarre...