Re: Sgdk - Sega Megadrive / Genesis Development Kit

[troudki]

Scrolling Map
Je fais actuellement un test de map (réalisé sous mappy) dont la hauteur ne fait que 12 tiles x 120 de longueur 
Je souhaite scroller que cette map (qui ne fait pas la hauteur d'un écran) en définissant un mode
VDP_setScrollingMode(HSCROLL_TILE,VSCROLL_PLANE)
par contre j'ai un peu de mal avec la commande de scroll VDP_setHorizontalScrollTile . Avec quel arguments , je peux scroller que ma map de 12 tiles de hauteur et pas tout le plan ?
VDP_setHorizontalScrollTile(PLAN_A, tile??, -scrollH,len??,use_dma??)

[troudki]

Sound FM & PSG
Hello les pros SGDK
il y a t il moyen de connaitre le status d'un channel FM ou PSG en l'executant avec le driver XGM par exemple.
SGDK possède beaucoup de fonctions dédiés au PCM (sample) et je ne vois que des fonctions de SET & Write

[Stef]

Scrolling Map
Je fais actuellement un test de map (réalisé sous mappy) dont la hauteur ne fait que 12 tiles x 120 de longueur 
Je souhaite scroller que cette map (qui ne fait pas la hauteur d'un écran) en définissant un mode
VDP_setScrollingMode(HSCROLL_TILE,VSCROLL_PLANE)
par contre j'ai un peu de mal avec la commande de scroll VDP_setHorizontalScrollTile . Avec quel arguments , je peux scroller que ma map de 12 tiles de hauteur et pas tout le plan ?
VDP_setHorizontalScrollTile(PLAN_A, tile??, -scrollH,len??,use_dma??)

Normalement dans le fichier .h tu as la doxygen qui explique chaque paramètre mais je conçois que ça ne soit pas très clair :
- Le paramètre 'tile' référence le premier tile dont tu veux modifier la valeur de scrolling, en partant de 0 pour la premier ligne de tile (8 pixels du haut).
- Le paramètre 'values' est la tableaux contenant toutes les valeurs de scroll horizontaux à appliquer.
- Le paramètre 'len' spécifie le nombre de valeur à modifier, par exemple si la premier paramètre tile vaut 0 et que len vaut 12 alors tu vas modifier les valeurs de scroll pour les 8*12 = 96 pixels du haut de ton plan.
- Le paramètre 'use_dma' c'est juste pour permettre l'utilisation du DMA pour transférer les valeurs.

Sound FM & PSG
il y a t il moyen de connaitre le status d'un channel FM ou PSG en l'executant avec le driver XGM par exemple.
SGDK possède beaucoup de fonctions dédiés au PCM (sample) et je ne vois que des fonctions de SET & Write

Qu'est-ce que tu veux dire par l'état d'un channel FM ou PSG ? Savoir s'il est en train de jouer ? Le driver XGM conserve l'état de certain registres FM, l'enveloppe, l'état Key on/off mais c'est pas toujours suffisant pour savoir si un channel FM est actuellement en train de produire un son ou pas (hauteur actuelle de l'enveloppe). Pour le PSG, tu as une copie des registres donc là c'est facile.
Qu'est ce que tu veux dire par Set ou Write ? ça me parait être du très bas niveau or les drivers sont justement là pour interpréter des formats spécifique de musique (et donc haut niveau). Toutes les commandes "bas niveau" du chip YM2612 et PSG se trouvent respectivement dans ym2612.h et psh.h mais je doute que ça soit ça qui t'interesse...

[tetsuro]

Merci pour ton aide Stef, je vais tester tout ça et te tenir au courant si j'arrive de nouveau à avoir l'auto-complétion sur Code Blocks, et Bonne Année à toi :)

[Stef]

Merci ! bonne année à toi aussi et bon courage surtout

[troudki]

Hello Stef..
Merci pour ta réactivité..
Ta librairie est très bien structurée et documentée.. les samples sont aussi du grande qualité pour apprendre et illustrer certaines fonctions.
du coup, pour les autres fonctions, il faut les tester, comprendre le concept et s'appuyer également sur les nombreux sources disponibles sur le net.
J'ai commencé le SGDK il y a quelques semaines et je fais surtout des snippets avant de me lancer dans une réalisation.

Pour ce qui est du status des channels FM & PSG, j'ai vu dans la demo blowfish de sigflup , un effet d'affichage sur les status .

.. Pour l'apprentissage de SGDK , il ne manque qu'un repos de snippet  ou chacun pourrait déposer son code et  apprendre à son rythme car effectivement ca peut dérouter les novices les samples de la lib.

[Stef]

Merci Les samples aident mais effectivement sont très loin d'exploiter l'ensemble des méthodes du coup comme tu le dis pour le reste tu es obligé d'assimiler la logique de la librairie et ensuite comprendre ce que chaque méthode fait. C'est un process d'apprentissage assez long :-/

La démo blowfish utilise un driver spécial et il parse les commandes pour avoir l'état des channels FM mais c'est assez basic en fait. En gros a chaque événement "key ON" il génère un pic sur le channel en question, ça ne prend aucunement la gestion du l'enveloppe en compte mais ça peut être suffisant
Dans ce cas on peut trouver l'état des "keys" pour chaque operateur de chaque channel dans le driver XGM, ce qui permet d'en faire autant.

Edit: En fait je pensais à une autre démo où u vois l'état par channel (avec le driver GEMS), dans la démo que tu cites c'est encore plus simple puisqu'il affiche juste un état global pour la FM (n'importe quel key ON monte la barre en gros).

[troudki]

CODEBLOCK + SGDK
hello, il y a plein de tutos pour configurer SGDK avec IDE codeblock. C'est parfait pour le "Build" et générer le binaire mais est ce que quelqu'un a réussi à paramétrer et exécuter le binaire via un émulateur lorsqu'on fait un "Run" .

[tetsuro]

Effectivement ça serait vraiment intéressant pour les tests :)

[Stef]

CODEBLOCK + SGDK
hello, il y a plein de tutos pour configurer SGDK avec IDE codeblock. C'est parfait pour le "Build" et générer le binaire mais est ce que quelqu'un a réussi à paramétrer et exécuter le binaire via un émulateur lorsqu'on fait un "Run" .

J'utilise configuré un "tool" pour ça, j'avoue n'avoir jamais essayé de le configurer sur le "Run". Ce que j'ai pas mal tenté par contre c'est de pouvoir débugger avec un émulateur supportant GDB (comme le dernier GensKMod) mais j'ai jamais réussi à bien le faire fonctionner avec GDB... c'est vraiment dommage car si ça tournait ça serait vraiment génial comme outil de debug ! On pourrait débugger comme on debug avec un PC (breakpoint, inspection etc..)

[troudki]

On a scan line you can have 10 32 pixel wide sprites or 20 16 pixel wide sprites. Each sprite can only have 16 colors but they are out of the 4 different color tables. Color 0=transparent.

A quoi correspond un "scan line" ?
Chaque sprite peut s'afficher avec la palette de l'écran sprite mais peut également avec les palettes des autre plans (A,B,Windows) ?

[dub]

J'ai écrit en anglais moi, déformation professionnelle

Une scan line, c'est un ligne entière de l'écran visible. La vidéo comme les jeux affichent les pixels de gauche à droite, puis de haut en bas pour chaque ligne.

Donc si tu as un écran de 320*224 pour la MD, tu as 224 lignes.

Pour afficher les sprites, je parlais du nombre total de pixels par ligne autorisé par la MD, donc ce mode vidéo : 320 pixels donc si on met plus de 10 sprites de 32 pixels, la console n'affichera pas les pixels des sprites suivants (différent de l'affichage du plan). Uniquement pour la ligne en cours.

Après les palettes se partagent. Si tu utilises la même palette pour un plan et un Sprite, tu peux loader qu'une seule palette. le seul soucis que je connais, c'est la première couleur de la palette qui sert de transparence pour les sprites.

[troudki]

hello
Merci pour ces infos.. je continue à faire mes tests ..
il y a donc 4 palettes de 16 couleurs (donc 15 utiles) que les sprites peuvent partager.

"In Mode V. the VDP display has 4 planes:  SPRITE, SCROLL A/WINDOW, SCROLL B, and BACKGROUND."

les 4 Plans sont bien sprite,plan A,Plan B et Window ? Pourquoi aucune fonction de drawImage ou Bitmap n'accepte WPLAN ou WINDOW comme argument ?

[Stef]

En fait tu peux mettre la window en paramètre, j'ai juste oublié de le mettre dans la doc :p (Quoiqu'il faudrait que je regarde pour la fonction de drawImage, je ne sais plus comment je l'ai implémenté exactement..)

[troudki]

Bizarre ce Plan Window..
doit on initialiser autre chose pour afficher dans le plan window?

Code:

int main()
{
   VDP_init();

    VDP_drawTextBG(VDP_PLAN_WINDOW,"HELLO",TILE_ATTR(PAL1,0,FALSE,FALSE),10,15);

   while(1)
   {
      VDP_waitVSync();
   }
   return (0);
}

Avec VDP_PLAN_A ou B ça fonctionne.
est ce le plan window est lié au plan A ? (1 playfield can have a "fixed" window)
Est il vraiment utile ?

[Stef]

Le plan window est une partie fixe du plan A en réalité donc là où la window s'affiche, le plan A ne s'affiche pas. Avant de tenter d'écrire dans le plan Window, tu dois t'assurer de bien avoir configuré sa position et sa taille ar par défaut elle n'est pas active.

[Top l'âne]

A fond dans SGDK depuis le début du mois, j'aimerai quelques menues précisions.

u16, u8... Je conçois que ce sont des variables propre à cet environnement de travail. Mais finalement je les manipule dans le brouillard, quelqu'un pour m'éclairer un peu?


Je me suis penché sur la fonction random(); disponible dans maths.h.
J'arrive à obtenir le résultat souhaité, mais je le prends comme un heureux hasard (ah ah, quel bon jeu de mots^^).

La doc m'indique sobrement:

"returns a u16 integer."

cf ma première question donc.^^
Mais j'aimerai également savoir/comprendre comment je peux fixer la fourchette d'action de la fonction.
Typiquement obtenir un résultat entre 0 et 50.

[Invité]

u16, u8... Je conçois que ce sont des variables propre à cet environnement de travail. Mais finalement je les manipule dans le brouillard, quelqu'un pour m'éclairer un peu?

Ben u16 = unsigned 16 bits soit 2 octets
u8  = unsigned 8 bits soit 1 octet.

Tu peux utiliser (unsigned) char et (unsigned) short il reste dans la norme C mais la norme C ne définie pas char a 1 octet obligatoirement , c'est une valeur si possible mais char peut faire 2 octet ou 4 octets pareil pour short

Je me suis penché sur la fonction random(); disponible dans maths.h.
J'arrive à obtenir le résultat souhaité, mais je le prends comme un heureux hasard (ah ah, quel bon jeu de mots^^).

La doc m'indique sobrement:

"returns a u16 integer."

cf ma première question donc.^^
Mais j'aimerai également savoir/comprendre comment je peux fixer la fourchette d'action de la fonction.
Typiquement obtenir un résultat entre 0 et 50.

Alors par info je n'utilise pas SGDK mais , la méthode bourrin c'est de faire un modulo par exemple

Code:

 mavariable = random()%50;

Mais c'est assez lourd j’aurais conseillé de faire un mask plutôt du genre :

Code:

 mavariable = random()&0x003F;

ça donnerait un résultat entre 0 à 63 mais c'est beaucoup plus rapide que le modulo

J’aurais fait une soustraction par la suite pour avoir le chiffre de 0 à 50.

Code:

mavariable = random()&0x003F;
if(mavariable > 50) mavariable -= 50;

Après c'est par soucis optimisation a voir si la Megadrive on a besoin , mais vu que je code plus sur super nintendo en général je reste vigilant a ce genre optimisation.

Sinon pour Code:Block il est possible de lancer émulateur avec le bouton run Project ->set program arguments et de faire un truc du genre '& dgen marom.md' , mais c'est une commande que j’aurais écrit sur Linux , j'imagine que les commande windows serait différent.

[troudki]

Sous Windows Code:Block 13.12
j'utilise comme paramètres
${PROJECT_DIR}${TARGET_OUTPUT_DIR}rom.bin

[Invité]

Sous Windows Code:Block 13.12
j'utilise comme paramètres
${PROJECT_DIR}${TARGET_OUTPUT_DIR}rom.bin

euh...
On s'est mal compris moi je que je lis la c'est le code pour la sortie de ton binaire (on gros ou il va le mettre), nullement la configuration pour que le run lance emulateur + la rom.
De plus si tu fait ça sur Project ->set program arguments ça va rien donner , sachant qu'il va lancer rom.bin comme un exécutable et il mettra en argument ${PROJECT_DIR}${TARGET_OUTPUT_DIR}rom.bin
Grosso modo sur windows mon code marcherai pas parce que :
1) je sais pas si sur windows la command & et reconnu (qui signifie tout simplement et)
2) que dgen soit votre émulateur et si sur windows il reconnais cette commande sinon j'imagine qu'il faudrait un chemin absolu +.exe (ou qu'on puisse rajouter des commandes)
3) marom.md est un argument pour l’exécutable (ici notre émulateur) on supposant que tout les émulateurs laisse le premier argument pour la rom sinon la command -h ou --help peut donner plus d'info (ou voir le site officiel tout simplement de votre émulateur).

[Top l'âne]

Et puis le Z80, à quoi ça me sert de l'économiser ? Là il gère tout: la musique, les bruitages, avec les 4 voies PCM... si je peux faire du 14 Khz autant en profiter non ? D'ailleurs je t'avais dit que c'était possible, de gérer la musique et 4 voies PCM, le tout sur le Z80, maintenant tu en as la preuve
Après le PCM, ce n'est pas du mod non plus, c'est juste du PCM brut sans support d'enveloppe ni de pitch mais sur MD, ça serait dommage de vouloir faire du mod quand tu as la FM + le PSG. Le PCM reste important pour les drums et les SFX qui sont difficiles à reproduire via la FM.

Quand je remonte le fil du topic à la recherche d'indices sur la partie son de SGDK et que je tombe là dessus, je me dis que je trouve ce principe complètement glucose.








Et bref, j'ai réussi à me faire les dents sur la partie affichage de mon prog, je voudrai m'atteler à la partie son, un truc dément, genre trois bips en cadence de tir pour flatter le cornet, esprit fin 70's, mais à la lecture du doxy, je sèche sévèrement.
Je suis allé me promener un peu chez Spritesmind, mais de l'aveu de Kanneda un tuto sur la partie son fait défaut.

Une chance de me voir mettre le pied à l'étrier par un connaisseur?


@kannagi: merci pour tout camarade, j'ai retrouvé après coup un point de doc concernant les variables.
Pour les méthodes de random, je me suis contenté de "bourriner", vu que ça fonctionne en l'état, et surtout parce que je ne sais pas ce qu'est un mask et que je préfère comprendre ce que je fais dans la mesure du possible.^^
Masque binaire? C'est là dessus que je dois me renseigner pour creuser la question?

[dub]

Dans les samples du sgdk de Stef, tu as un source pour la musique.
Ca devrait aller avec le code pour comprendre le fonctionnement.

https://github.com/Stephane-D/SGDK/tree/master/sample/sound

[vingazole]

Pas évident à expliquer le truc du masque binaire mais je vais essayer :

Dans un premier temps je vais rappeler la table de vérité du ET binaire (noté "&" en C) :
0 & 0 = 0
0 & 1 = 0
1 & 0 = 0
1 & 1 = 1

Pour un bit quelconque b (valant 0 ou 1), on a donc :

b & 0 = 0

b & 1 = b

On peut utiliser cette propriété pour forcer à zéro certains bits (chiffres binaires) d'un nombre.

Par exemple si on fait un ET binaire entre un nombre de 16 bits quelconque représenté par ses bits b0, b1, ..., b15 avec le nombre binaire 0000000000111111 (63 en décimal, 003F en hexadécimal) :

    b15 b14 b13 b12 b11 b10  b9  b8  b7  b6  b5  b4  b3  b2  b1  b0
  &   0   0   0   0   0   0   0   0   0   0   1   1   1   1   1   1     (63)
  -----------------------------------------------------------------
  =   0   0   0   0   0   0   0   0   0   0  b5  b4  b3  b2  b1  b0

(car b0 & 1 = b0, b1 & 1 = b1, ..., b5 & 1 = b5, b6 & 0 = 0, b7 & 0 = 0, ..., b15 & 0 = 0)

On a alors conservé la valeurs des bits b0 à b5 de notre nombre et forcé à zéro tous les autres (b6 à b15) en utilisant le masque binaire 0000000000111111.



Allez, un peu de maths maintenant !  



Appelons A notre nombre de 16 bits, la valeur de A est la somme des puissances de 2 affectées des coefficients b correspondants :


A = b0 x 2^0 + b1 x 2^1 + ... + b5 x 2^5 + b6 x 2^6 + b7 x 2^7 + ... + b14 x 2^14 + b15 x 2^15

où 2^0 ("deux à la puissance zéro") vaut 1, 2^1 = 2, 2^2 = 4, 2^3 = 8, etc...


On peut regrouper les bits 0 à 5 d'une part et les bits 6 à 15 d'autre part :

A = b0 x 2^0 + b1 x 2^1 + ... + b5 x 2^5 + (b6 + b7 x 2 + b8 x 4 + ... + b15 x 2^9) x 2^6


Si on pose R = b0 x 2^0 + b1 x 2^1 + ... + b5 x 2^5, Q = b6 + b7 x 2 + b8 x 4 + ... + b15 x 2^9 et 2^6 = 64, on obtient :

A = R + Q x 64 avec R < 64 : R est donc le reste de la division euclidienne (appelé aussi modulo) de A par 64.


Comme notre nouveau nombre R obtenu par masquage est compris entre 0 et 63, il faut juste lui soustraire 50 dans le cas où il est plus grand que 50 pour obtenir un nombre compris entre 0 et 50.



Nb : le 68000 possède des opcodes donnant le quotient et le modulo pour les divisions (signées et non signées), inutile de se prendre trop la tête

[troudki]

.. avoir l'état des channels FM mais c'est assez basic en fait. En gros a chaque événement "key ON" il génère un pic sur le channel en question, ça ne prend aucunement la gestion du l'enveloppe en compte mais ça peut être suffisant
Dans ce cas on peut trouver l'état des "keys" pour chaque operateur de chaque channel dans le driver XGM, ce qui permet d'en faire autant.

pour avoir l'état du driver XGM

    Z80_loadDriver(Z80_DRIVER_XGM, TRUE);
    Z80_requestBus(TRUE);
    pb = (u8 *) Z80_DRV_STATUS;

Pour  l'état des "keys" pour chaque operateur de chaque channel  .... là c'est un peu tordu pour moi ..

Quelqu'un a déjà essayé ce genre de manip ?

[Top l'âne]

@vingazole: merci d'avoir pris le temps de me faire cette démonstration. Dans l'état actuel de mes connaissances, ça va déjà trop loin. Faut que je prenne encore un peu d'xp.^^

@dub: rhaaa mais oui merci. J'avais déjà eu ce dossier sample sous les yeux mais il m'était sorti de l'esprit tant j'étais resté focus sur le doxy. Ca tombe bien, je voulais dégrossir bientôt l'approche du scrolling.
Mais pour en revenir à mes recherches du moment, la partie son, j'ai lancé hier le .cbp.
Hélàs, il apparait que l'include d'un ressources.h me fait défaut. Je l'ai bien cherché partout dans le dossier sound, mais peau de zob.
D'après l'arborescence du projet codeblocks ce ressources.h devrait se situer dans le dossier res, ce qui ne manque pas de m'étonner d'ailleurs, ne devrait il pas exister un dossier inc pour le contenir?



Heu... Help?

[Stef]

En fait quand tu compiles le projet (avec le makefile fourni dans SGDK) il va te générer automatiquement le fichier resources.h à partir du fichier resources.res qui se trouve dans le répertoire res.
Le fichier resources.res est un fichier qui déclare tes ressources, ce genre de fichier (.res) est automatiquement transformé (via l'outil rescomp) en structures C (avec un fichier .h associé, ici resources.h) que tu vas pouvoir utiliser directement dans ton code source.
Le fichier rescomp.txt présent dans le répertoire bin de SGDK t'explique la syntaxe pour déclarer tes différentes ressources (graphiques ou sonores). C'est très important de bien maitriser cette gestion des ressources pour bien utiliser SGDK ;-)

En gros tu peux voir que le driver XGM necessite soit du WAV (pour les SFX)

[Stef]

pour avoir l'état du driver XGM

    Z80_loadDriver(Z80_DRIVER_XGM, TRUE);
    Z80_requestBus(TRUE);
    pb = (u8 *) Z80_DRV_STATUS;

Pour  l'état des "keys" pour chaque operateur de chaque channel  .... là c'est un peu tordu pour moi ..

Quelqu'un a déjà essayé ce genre de manip ?

En fait ce status ne te retourne que l'état MUSIC PLAY et SFX PLAY pour chaque channel. C'est assez simple, si tu veux des informations plus fines c'est plus compliqué...

[Top l'âne]

Bon, je ne suis pas parvenu à utiliser correctement les samples (erreurs de compilation), mais après une bonne heure de bidouille j'ai quand même obtenu des résultats. Je ne suis pas encore perdu pour la cause.^^
Affichage d'un bitmap (la lune du tuto) et lecture de pistes son.
Ca va me suffire pour mes impératifs du moment, le reste viendra avec la pratique.

Merci pour le SAV Stef.

[Top l'âne]

Je viens de concrétiser mon premier homebrew il y a quelques jours. (Hourra)
Ces six semaines de labeur laissent quelques questions en suspend.

De manière générale, y a t'il plusieurs versions de la doc doxy? Une récente à attraper quelque part?

J'ai noté par exemple une fonction malheureuse: VDP_setTileMap();
Alors que VDP_setTileMapXY(); utilisée dans le tuto et dont je me suis servi n'apparait pas dans ma doc.
Ou par exemple le SDN_startPlaySfx repéré dans les samples mais également absente de ma doc.


Par ailleurs, les tests sous émulateurs de mon bin sont 100% concluants alors que le passage en Everdrive par Tetsuro s'est avéré catastrophique. Avez vous des pistes de réflexions à me soumettre à ce sujet?
(de toute manière j'aurai mon propre Everdrive très prochainement, je pourrai décortiquer les soucis de mon prochain projet en allant)

Question de C pour finir.
J'ai créé mon propre typedef struct Sprite_Def pour le jeu en lui même dans mon jeu.h.
J'ai voulu le réutiliser pour mon écran titre pour y animer un alien.(#include "jeu.h" bien sûr)

J'ai eu des warnings contraignants, si je me souviens bien, "multiple declaration of...".
J'ai contourné le problème en créant une variation de syntaxe typedef struct Sprite_Deff pour mon intro.c.

Si je veux n'avoir à créer qu'une seule structure Sprite_Def, où me conseillez vous de la déclarer?

[Invité]

Je suis étonner que tu n'a pas appris le préprocesseur en C.
ton probleme et tout simplement que quelque part tu appelle 2 fois jeu.h donc il y a "multiple declaration of..." en gros un .h doit ressembler a ceci :

Code:

#ifndef _JEU__
#define _JEU__

//include ,define , struct ect

#endif

Par ailleurs, les tests sous émulateurs de mon bin sont 100% concluants alors que le passage en Everdrive par Tetsuro s'est avéré catastrophique. Avez vous des pistes de réflexions à me soumettre à ce sujet?

a froid comme ça , impossible de savoir ce qu'il s'est passer , mais en gros les registre Megadrive ne doivent être utilisé que a certain moment , Il est probable que  l'envoie des sprite en VRAM se fait pendant le VBLANK , tout les émulateurs laisseront probablement a tout moment l’accès de la VRAM sans causer de bug (normal) , mais sur du hard réel ça peut poser quelque souci
Mais ça peut être aussi d'autre registre matériel qui ne peut etre utilisé que pendant le VBLANK.

[Top l'âne]

Merci Kannagi.

Moui, je me pensais solide sur les directives de préprocesseur. De ce que tu me dis j'avais établi un bon diagnostique mais visiblement j'ai cafouillé sur la résolution du problème. A revoir.^^

J'ai pigé la démonstration concernant le VBLANK. Je ne m'en étais guère soucié jusqu'à présent. Je vais creusé ça.