Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

maitrisant le pouvoir obscure de la VBlank, mais ceux là jouent dans les Marvel.

Nah, le vblank n'a rien de sorcier, je t'assure .
Tu pensais d'ailleurs la même chose pour les pointeurs 

il suffit juste de se sortir de la tête qu'un SDK fait tout,et le fait forcement bien. 

[ichigobankai]

Ca c'est clair et qu'importe le SDK.

Le vblank, c'est quand même assez basique ;
ca se déclenche "bêtement" tjs au même moment, juste surveiller la charge "avant".
C'est plus simple a comprendre & assimiler que les pointeurs à mon sens.
(qui sont d'ailleurs bcp plus simple en ASM qu'en C... ^^ )

=> Les hommes qui codent en ASM en buvant des bières et qui aiment aussi les gros seins sont vrais.

Merde j'étais pas loin, j'aime pas la bière

[Invité]

Tututut. 
Facile à dire, mais difficile à faire. Pour moi, il y aura eu un avant et un après VBlank. J'ai réalisé que c'est un ton au dessus et je préfère me teare .. euh taire. Je ne cherche juste qu'à la respecter sans approfondir de peur de m'y perdre. Il y a ceux qui la maitrise et il y a les autres.

VBlank, de mon moniteur tu te planques,
Des lignes de codes aux sprites en prise au tearing,
Ma logique n'est plus si solide comme un Tank,
Mais malgré tout, j'attends le moment ou ça fera DING,
Et la je pourrais dire que finalement, je l'aime ma VBlank !

[Invité]

C'est plus simple a comprendre & assimiler que les pointeurs à mon sens.
(qui sont d'ailleurs bcp plus simple en ASM qu'en C... ^^ )

Je plussois   

Facile à dire, mais difficile à faire. Pour moi, il y aura eu un avant et un après VBlank

LOL .
Faut se dire que tout ce qui touche directement à l'image doit être fait dans le vblank et pis c'est tout 

VBlank, de mon moniteur tu te planques,
Des lignes de codes aux sprites en prise au tearing,
Ma logique n'est plus si solide comme un Tank,
Mais malgré tout, j'attends le moment ou ça fera DING,
Et la je pourrais dire que finalement, je l'aime ma VBlank !

J'ai l'impression que c'est ton cerveau qui a fait vblank là !!! 
je t'assure que c'est une notion très simple à comprendre, rien de gourou là dedans 

[TotOOntHeMooN]

Sérieux, mais c'est quoi tout ce tearimes ?!! 

[Invité]

Un Alexandring ! 

Bon, revenons à Sgdk que Shingo maîtrise de plus en plus, et ça fait plaisir de voir son projet évoluer comme ça.

[Invité]

Et bien je ne pensais pas que cette petite phrase ferait réagir autant ^^

L'ASM j'aimerais l'apprendre, mais je tombe toujours sur des tuto qui expliquent le fonctionnement sans aller dans la pratique.

Oui le SGDK je commence à mieux me débrouiller, mais c'est pas encore ça.

Là j'aimerais faire du scrolling par ligne afin de faire bouger les vagues de la mer à différentes vitesses.

Hors, je n'ai pas encore compris comment préparer mes tables.

[ichigobankai]

L'asm c'est loin d'être aussi compliqué que ce que bcp de monde pense, par contre y'a autant d'asm différents que de processeur (bon j'exagère un peu, car c'est lié à la famille). Mais la "logique", elle, reste la même.

Je ne vais pas te jeter la pierre, j'ai mis longtemps à m'y mettre car moi aussi ca me paraissait bien compliqué.

Mais hacker/désassembler des jeux (SMS, MD, etc.) il y a quelques années m'a ± poussé a enfin franchir le pas... Au final c'est quasi plus simple que le C, sauf que tu écris -un peu- plus de ligne (et encore ca dépend)

Après les tutos la dessus, perso je n'en ai pas utilisé. Si tu veux vraiment t'y mettre faut un bon gros listing détaillés des opcodes 68k (noms, description/utilité, porté, cycles, ...) et un debuggeur pour suivre ca pas à pas.

pour le Z80, j'utilise celui-ci http://z80-heaven.wikidot.com/instructions-set et http://www.z80.info/z80undoc.htm (pour les non documentés)

[TotOOntHeMooN]

Quand je vois tous les primates qui codent en assembleur, c'est sur que ça n'a rien de compliqué ! 

[Invité]

Y a t-il un moyen d'avoir le source en ASM généré par SGDK ?

[TotOOntHeMooN]

Y a t-il un moyen d'avoir le source en ASM généré par SGDK ?

Normalement, GCC -S pour générer les fichiers .s avec l'assembleur tout moche qui va avec.

[Invité]

@ToToontHeMooN merci ^^

Quelqu'un aurait-il un exemple très simple à partager pour l'utilisation du VDP_setHorizontalScrollLine(VDPPlan plan, u16 line, s16* values, u16 len, TransferMethod tm) ?

[Stef]

Y a t-il un moyen d'avoir le source en ASM généré par SGDK ?

Normalement, GCC -S pour générer les fichiers .s avec l'assembleur tout moche qui va avec.

J'ai même rajouté un target "Asm" dans le makefile pour avoir le listing ASM :p

[Stef]

@ToToontHeMooN merci ^^

Quelqu'un aurait-il un exemple très simple à partager pour l'utilisation du VDP_setHorizontalScrollLine(VDPPlan plan, u16 line, s16* values, u16 len, TransferMethod tm) ?

Je pense qu'elle parle d'elle même : tu donnes un tableau (et sa taille) qui va contenir la valeur de scroll pour chaque ligne =)
Dans le sample donuts tu as un exemple, que je résume ici :

Code:

#define TABLE_LEN       220

s16 scroll_PLAN_B[TABLE_LEN];
fix16 scroll_PLAN_B_F[TABLE_LEN];
fix16 scroll_speed[TABLE_LEN];

...

/* Set the proper scrolling mode (line by line) */
VDP_setScrollingMode(HSCROLL_LINE, VSCROLL_PLANE);

...

  for(i = 0; i < TABLE_LEN; i++)
  {
    scroll_PLAN_B_F[i] += scroll_speed[i];
    scroll_PLAN_B[i] = fix16ToInt(scroll_PLAN_B_F[i]) & 0x1FF;
  }

  VDP_waitVSync();

  // send hscroll table to VDP
  VDP_setHorizontalScrollLine(PLAN_B, 2, scroll_PLAN_B, TABLE_LEN, TRUE);



[Invité]

Merci @Stef tu assures. Je sais pas pourquoi je bloque avec ce scrolling.

Avec ton sample, cela me semble plus clair.

Donc dans ce cas là, on fait tu scrolling par ligne depuis la ligne 2 jusqu'à 220. scroll_PLAN_B c'est l'array contenant la position du scroll.

Jusque là c'est assez simple, je bloquais par ce que je voulais utiliser un FIX16 pour le scroll, mais je ne voyais pas comment convertir par la suite l'array. Donc j'ai utilisé un S16 à la place, mais le scrolling était trop rapide.

Là on bouge les lignes 2 à 220 à la même vitesse et dans le même sens. Si je souhaite varier la vitesse et le sens pour plusieurs lignes, il me faudra simplement jouer avec scroll_speed n'est ce pas ?

Autre question, je vois que tu utilises souvent dans ton code de l’hexadécimal, pourquoi ?

[ichigobankai]

le & 0x1FF ?
c'est un masque (bits)

[Stef]

Yep c'est un masque car mon plan devait faire 512 pixels de longueur (& 0x1FF  -->   & 511 du coup la valeur boucle entre 0 et 511) et l'hexa c'est quand même bien plus visuel que le décimal pour définir des masques binaires :p
Mais en réalité c'est facultatif ce masque car de toute façon le scrolling hard boucle sur la taille du tilemap, j'imagine que je l'ai mis pour faire joli (ou pour rendre le code plus clair je ne sais pas) ^^

Donc dans ce cas là, on fait tu scrolling par ligne depuis la ligne 2 jusqu'à 220. scroll_PLAN_B c'est l'array contenant la position du scroll.

De la ligne 2 jusqu'à la ligne 221 (on commence à la ligne 2 et on envoi un tableau de 220 en taille donc ligne 2 --> 221 inclus).

Jusque là c'est assez simple, je bloquais par ce que je voulais utiliser un FIX16 pour le scroll, mais je ne voyais pas comment convertir par la suite l'array. Donc j'ai utilisé un S16 à la place, mais le scrolling était trop rapide.

Justement ici j'ai des valeurs en fix16 (pour permettre un scrolling plus lent que 1px/frame, ce qui est très souvent le cas) que je converti en s16 pour envoyer au VDP, d'où les 2 tables...

Là on bouge les lignes 2 à 220 à la même vitesse et dans le même sens. Si je souhaite varier la vitesse et le sens pour plusieurs lignes, il me faudra simplement jouer avec scroll_speed n'est ce pas ?

Non, je bouge les lignes 2 à 221 selon les steps indiqués dans la table dédiées, du coup chaque ligne bouge indépendamment (dans le même sens certes mais pas obligé). Je l'ai pas mis dans le code ici mais dans le sample tu verras qu'il y a une partie qui va juste initialiser cette table de steps.

[TotOOntHeMooN]

Enlèves ton mask Stef, on t'as reconnu ! 

[Stef]

je suis démasqué

[Invité]

J'ai toujours du mal à utiiser ces opérations binaires ... Ca ne vient pas spontanément.

[Invité]

J'ai enfin compris comment fonctionnait le scrolling par ligne, hourra ! Merci @Stef

[Invité]

Salut tout le monde.

J'aimerais masquer les sprites qui passe devant ma Window. Comme vu avec @StudioVetea il suffit de définir la priorité d'un sprite à FALSE.

Sauf que ma Window est transparente et j'aimerais simplement afficher un rectangle noire qui remplirait l'espace utilisé afin de masquer les sprites.

J'ai tenté d'utiliser VDP_setTileMapRectEx(); mais ça n'a rien donné puisque je vois un rectangle noir qui ne masque pas les sprites avec en plus plein de tiles mélanges dont celle destinées à la palette.

Merci pour votre aide :)

[Hpman]

Bah fait simplement une window non transparente?

[Invité]

Oui, mais comment ne pas la rendre transparente ? Je ne vois que créer un png avec un fond...

[Stef]

Bah fait simplement une window non transparente?

+1
Pourquoi ne fais tu pas une window non transparente dans ce cas ? tu remplis ta window comme un plan... tu met une image dedans, et ensuite tu "écris" ton score à l'emplacement voulu (comme tu le fais déjà actuellement)
Oui bien sur il te faut une image pour la remplir (ou tu met une couleur pleine avec les "plain tiles" réservé par SGDK mais c'est un peu moche)

[Invité]

Oki effectivement c'est la solution la plus simple. Merci les bros !

[fourchette]

petite question sur le bitmap engine. je souhaiterais dézoomer une image (172x172) sur le plan A, en utilisant le double buffer, tout en gardant un fond rempli sur le plan B. est ce possible ?

[Stef]

De mémoire le bitmap engine utilise une résolution de 256x160 pixels, en double buffer ça te fait déjà plus de 40 Ko de bouffé en VRAM ! ensuite si tu retires les tables / tilemap / font, alors il te reste plus grand chose pour les tiles de plan B :-/ Il faudrait que j'optimise l'organisation VRAM car là je pense qu'il doit te rester 100 ou 150 tiles pour le fond :-/ tu peux écraser la font pour en gagner 96... en enlevant le double buffer tu gagnes beaucoup de VRAM (mais tu auras du tearing).

[Invité]

@Stef je me demandait pourquoi on a une palette au début de la VRAM... J'ai remarqué que ce n'est pas le cas sur la plupart des jeux...

[Tryphon]

C'est pas une palette, ce sont des tiles pleines. Tu te sers souvent de celle pleine de 0. Les autres, si tu ne t'en sers pas, tu peux les écraser si tu veux...

[fourchette]

De mémoire le bitmap engine utilise une résolution de 256x160 pixels, en double buffer ça te fait déjà plus de 40 Ko de bouffé en VRAM ! ensuite si tu retires les tables / tilemap / font, alors il te reste plus grand chose pour les tiles de plan B :-/ Il faudrait que j'optimise l'organisation VRAM car là je pense qu'il doit te rester 100 ou 150 tiles pour le fond :-/ tu peux écraser la font pour en gagner 96... en enlevant le double buffer tu gagnes beaucoup de VRAM (mais tu auras du tearing).

je voudrais éviter le tearing. en serrant un peu le fond devrait faire 100-120 tiles ça pourrait peut être le faire.