Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Stef]

Il renvoie 0 (FALSE) normalement...

[Tryphon]

Si je veux faire un effet de cycle de palette, il faut que je modifie les palettes pendant le VBlank pour éviter les CRAM dots non ?

Du coup, il vaut mieux le faire en utilisant le DMA ?

D'où ma question : y'a-t-il une façon de faire ça simplement en SGDK ou dois-je écrire ma propre routine ? Je n'ai pas vu de paramètre DMA ou DMA_QUEUE dans les routines de gestion de palettes.

[Tryphon]

Mon client retire sa dernière question : j'avais pas regardé le bon fichier.

Y'a un paramètre location dans DMA_queue, je pense que c'est le passage à aller (comme disent les Angliches)

[Stef]

Non mais tu as raison, les méthodes de gestion de palette ne le permettent pas, tu as obligé de passer par la méthode DMA_queue(..) directement...
C'est vrai que c'est un peu génant car souvent on veut charger les palettes pendant le VBlank (ce que font les routines de fading).

[Tryphon]

Ton DMA_queue est vraiment pratique (j'ai juste mis 5 minutes à comprendre que la destination s'exprimant en octets, la couleur 1 de la palette 3 est en 0x62 et pas en 0x31 ).

Après si tu veux, tu peux rajouter un paramètre transferMethod (comme à VDP_loadTiles) à la commande VDP_setPaletteColors...

Mais faudra que les utilisateurs de SGDK modifient leurs anciens codes. C'est vraiment dommage qu'il n'y ait pas de valeurs par défaut des paramètres en C...

[Stef]

Avec le DMA queue tu es tout en "raw", donc oui les adresses c'est du byte (même si le bit 0 sera ignoré dans le cas d'un DMA vers la CRAM ou VSRAM).

Sinon oui c'est tout le problème, j’essaie de préserver au mieux la retro compatibilité donc ajouter un paramètre c'est un peu génant :-/ Mais je trouverai bien des solutions :p

[TotOOntHeMooN]

Pas possible de procéder de la sorte :

oldFunctionName (x, y)
{
  return newFunctionName (x, y, 0)
}

newFunctionName (x, y, z)
{
  /* extended previous code */
  ...
}

defaultFunctionName ()
{
  return newFunctionName (0, 0, 0)
}

[Stef]

Ouais mais le problème c'est que originalFunctionName et newFunctionName doivent être différent, ce que j'aimerai éviter ici...

[Hpman]

Généralement les SDK déclinent en fonction, fonction2, fonction3 etc au fil des mises à jour pour garder la compatibilité.

Sinon fonction à nombre d'arguments variables, comme printf.

[TotOOntHeMooN]

Il est certain que c'est plus souple en C++ pour l'occasion, mais ça pourrait être :
- default (sans paramètre car ce que tout le monde utilise à 90%)
- standard (la fonction comme elle est aujourd'hui, son nom ne change pas)
- extended (la fonction propose tout les paramètres en avertissant qu'elle est sujette à évoluer)

EDIT: Effectivement, créer des fonctions au nombre d'arguments variable, comme printf, si possible...

[Stef]

C'est souvent ce que je fais : ajouter une fonction avec un Ex à la fin mais ça ne s'y prête pas toujours, et genre rajouter 2/3/.. à la fin je trouve ça pas terrible :p

Les paramètres optionnels c'est très lent en C (ça passe par une structure très lourde), donc je peux pas l'utiliser pour des méthodes qui doivent être rapide.

[TotOOntHeMooN]

ajouter une fonction avec un Ex à la fin mais ça ne s'y prête pas toujours, et genre rajouter 2/3/.. à la fin je trouve ça pas terrible :p

Effectivement. :p (rien à voir, enfin si Ex m'y fait penser, mais j'adorais programmer avec la lib Allegro sur PC ... ya 20 ans)

[Orion_]

désolé pour le petit hors sujet mais j'ai une question technique sur la Megadrive.
Je code une routine qui permet de transferer une ligne verticale de tile dans un des layer de la MD
pour éviter d'appeler la routine qui recalcule l'adresse de la VRAM a chaque ligne, je me suis dit que je pouvais simplement changer le registre $F d'auto incrémentation.
je transfer une ligne de tile de 16x16, donc en théorie ça devrait fonctionner comme cela:
Auto Increment initialement a 2
-> envoi d'un word en vram
Changement de l'Auto Increment a 128-2
-> envoi d'un word en vram (la on devrait être a la ligne suivante du coup)
Changement de l'Auto Increment a 2
-> envoi d'un word en vram
Changement de l'Auto Increment a 128-2
-> envoi d'un word en vram (encore a la ligne suivante)

or dans la pratique ça ne fonctionne pas, seul mon premier tile s'affiche bien, les autres ne s'affiche pas, et je n'arrive pas a débugger l'adresse de la vram courante (j'ai pas trouver d'émulateur qui l'affiche)
donc, est-ce que c'est possible ? est-ce que c'est émulé ?
ou est-ce que mon code est bugué ?

Code:


 bsr SetVramAddress

 lea VDP_DATA,a3
 lea VDP_CTRL,a4

 move.w #$8F02,d6 ; VDP Address Auto Increment = 2 (next tile)
 move.w #$8F7E,d7 ; VDP Address Auto Increment = 128-2 (next line)

 move.w -4(a1),(a3) ; Set Tile Upper Left
 move.w d7,(a4) ; VDP Auto Increment = 128-2 (next line)
 move.w -2(a1),(a3) ; Set Tile Upper Right
 move.w d6,(a4) ; VDP Auto Increment = 2 (next tile)
 move.w 128-4(a1),(a3) ; Set Tile Lower Left
 move.w d7,(a4) ; VDP Auto Increment = 128-2 (next line)
 move.w 128-2(a1),(a3) ; Set Tile Lower Right
 move.w d6,(a4) ; Restore VDP Auto Increment = 2 (next tile)


[Hpman]

Je pense que mame doit pouvoir t'afficher ce que tu veux dans le debugger:

m_vdp_address
m_regs.get()

[Stef]

Il y a un truc bizarre c'est que tu set l'auto incrémente *après* avoir écrit en VRAM, dans le doute tu devrais le mettre à 2 avant l'écriture (plutot que de le remettre à 2 à la fin) car si pour X raisons il a été redéfini entre temps ça va foirer.. Aussi pour que le 128-2 fonctionne il faut que ton plan soit en 64x64 mais j'imagine que c'est le cas.
Sinon pour le reste, ça devrait fonctionner même si c'est clairement pas la manière la plus rapide de faire ^^

[Tryphon]

Je peux pas te dire ce qui cloche dans ton code, mais : oui, c'est émulé, et heureusement parce que la plupart des jeux font comme ça pour updater une colonne de tile sur un scrolling horizontal.

Perso je fais comme ça mais je prépare une colonne complète en RAM (28+ tiles) et je les balance par DMA avec l'incrément à $8O. Puis la colonne des tiles de gauche.

[Orion_]

ben je suis désolé mais ça ne fonctionne pas:


Après j'avais pas penser a utiliser le DMA en conjonction avec l'incrémentation auto, c'est sur que ça serait plus rapide !
je vais tenter ça

[Invité]

Normalement faut régler l'auto-incrément en fonction de ton écran virtuel(a combien de tiles ton scrolling va boucler).
Sur MD c'est le registre $10 ( plane size) avec les bits 0/1 qui le défini pour l'horizontal, et les bits 4/5 pour le vertical .
Donc comme tu as 3 valeurs
32,64,128 faudra régler l'auto-incrément en fonction.
Normalement (enfin sur PCE c'est comme ça,sans le -2 ) tu paramètres l'incrément au début, et une seule fois .

Sur ton exemple on dirait un plane size en 32 avec un incrément de 128,avec le viewer VRAM de l'émulateur tu peux voir ou ont été écrites tes valeurs .

[Orion_]

nan mais je suis pas mauvais a ce point la ok, mon plane est en 64x32 ...
et de toute façon sur mon screenshot ci dessus, l'incrément reste a 2, et ça ne marche pas, donc aucun rapport avec la taille du plane

[Invité]

dsl, c'était pas du tout dans ce but là  ,alors c'est ta commande pour paramétrer l'incrément qui n'est pas bonne(pourtant elle semble correcte) .

Essayes juste en paramétrant l'incrément 1 seule foi au début et pas entre chaque transfert..

[Hpman]

Tu peux poster la rom qui ne va pas, avec le breakpoint qui correspond?

[Tryphon]

Tu le fais pendant la période active ou pendant le VBlank ?

[Orion_]

Essayes juste en paramétrant l'incrément 1 seule foi au début et pas entre chaque transfert..

ben c'est ce que j'ai fait dans le premier essai du screenshot, et ça fonctionne
donc j'ai l'impression que paramétrer l'incrément met a zero un registre quelque part qui fait que les transfert suivant ne fonctionnent plus, peut être faut il re-paramétrer l'adresse VRAM après ça ?

Tu le fais pendant la période active ou pendant le VBlank ?

ça ne change rien, avant ou après

en tout cas j'ai essayer avec le DMA et ça fonctionne, donc c'est bon :)
je met l'incrément a 128, et je transfer mes 2 colones de tiles avec 2 appel au DMA (et en reparametrant l'adresse vram au début à chaque fois)

[Invité]

ben c'est ce que j'ai fait dans le premier essai du screenshot, et ça fonctionne
donc j'ai l'impression que paramétrer l'incrément met a zero un registre quelque part qui fait que les transfert suivant ne fonctionnent plus, peut être faut il re-paramétrer l'adresse VRAM après ça ?

Effectivement c'est bizarre, pour la VRAM je te dirai non car ça semble pas vraiment logique que ça change l'adresse de la VRAM, peut être qu'il faille re-paramétrer le VDP en lecture/écriture après l'auto-incrément..

Pour moi la bonne méthode au CPU ça serrait:

Code:

move.w #$8F02 , VDP_CTRL

Initialises l'adresse de la VRAM( je suis pas sur du code)
lea    VDP_CTRL , a0
move.l VRAM_ADR , (a0)

move.w #1 , VDP_DATA
move.w #2 , VDP_DATA
move.w #3 , VDP_DATA
move.w #4 , VDP_DATA


Ca correspondrait à ce que tu fais avec le DMA

[Orion_]

non mais ta pas compris ce que je voulais faire :/

[Invité]

non mais ta pas compris ce que je voulais faire :/

Envoyer une colonne de tiles en VRAM au CPU d'un trait en utilisant l'auto incrémentation,non ??

[Orion_]

oui, une colonne de 2x32 tiles, pas une ligne ...

[Invité]

oui, une colonne de 2x32 tiles, pas une ligne ...

Ah effectivement alors 
Mais le principe reste le même,j'ai mis un incrément de 2 pour rester dans ton exemple, sinon il faut passer l'incrément à $80,l'exemple que j'ai donné me semble pas mauvais, tu transfères ta première colonne de 32 tiles, tu changes l'adresse du VDP(sans toucher à l'incrément), et tu envoies ta deuxième colonne .

C'est bien comme ça ?:
1      1
.       .
.       .
.       .
32    32

Et pas :
1      
.       
.       
.       
32
1      
.       
.       
.       
32
?

[Stef]

ben je suis désolé mais ça ne fonctionne pas:


Après j'avais pas penser a utiliser le DMA en conjonction avec l'incrémentation auto, c'est sur que ça serait plus rapide !
je vais tenter ça

Clairement je ne comprends pas comment tu peux avoir une différence de rendu avec ces 2 morceaux de code. Tu n'as pas un soucis genre une interruption qui arrive au mauvais moment avec le 2eme code ? ou alors tu as écrit un premier word de set d'adresse dans le port CTRL (ce qui latch un registre interne pour être en attende du second word d'adresse) et du coup ton premier move.w xx, VDP_CTRL est interprété comme le second word d'adresse ce qui dérègle ton adresse de destination...

Enfin tu as résolut ton problème avec le DMA, qui est en plus bien plus efficace donc question réglée

[Invité]

Petite question concernant

Code:

int main(u16 hard)

, le compilateur m'indique :

src\main.c|3|warning: 'main' takes only zero or two arguments [-Wmain]|
src\main.c|3|warning: first argument of 'main' should be 'int' [-Wmain]|

est-ce normal ?

Merci

[Tryphon]

C'est quoi hard ?

main sur MD ne prend pas d'arguments. En C sur ordi, tu peux passer argv et argc qui permettent de récupérer des paramètres éventuellement passés en ligne de commande (donc superflu sur MD).