Re: Sgdk - Sega Megadrive / Genesis Development Kit

[philip]

Oui c'est très fort. :)

[dub]

Hello les pros du sgdk.

J'ai un problème, je test le sgdk et tout fonctionne comme je l'entends. Les plans, les tilemap et tout et tout.

Mon problème est que j'ai l'impression d'être limité à 7 sprites par ligne. J'ai vérifié le debug avec la VDP sprite, il y a mes 20 sprites mais pas à l'écran. J'ai certainement raté qqchose. Je poste mon code si vous pouvez m'aider.

Code:


// sprites structure
Sprite sprites[20];

Code:

int main()
{
    u16 palette[64];
    u16 ind;

// initialization
    VDP_setScreenWidth320();
// init sprites engine
    SPR_init(256);


Code:

    camposx = -1;
    camposy = -1;
    posx = FIX32(48);
    posy = MAX_POSY;
    movx = FIX32(0);
    movy = FIX32(0);
    xorder = 0;
    yorder = 0;
 
 sprposx = 10;
 sprposy = MAX_POSY;
 
    // init scrolling
    updateCamera(FIX32(0), FIX32(0));

Code:

    // init sonic sprite
    SPR_initSprite(&sprites[0], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[1], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[2], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[3], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(20);
 SPR_initSprite(&sprites[4], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(25);
 SPR_initSprite(&sprites[5], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[6], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[7], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy + sprposy), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[8], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy + sprposy), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[9], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy + sprposy), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 
 
 
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[10], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy + sprposy), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
  SPR_initSprite(&sprites[11], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 SPR_initSprite(&sprites[12], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[13], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[14], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[15], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[16], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[17], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy ), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[18], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy + sprposy), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 sprposx += FIX32(15);
 SPR_initSprite(&sprites[19], &sonic_sprite, fix32ToInt(posx - camposx + sprposx), fix32ToInt(posy - camposy + sprposy), TILE_ATTR(PAL2, TRUE, FALSE, FALSE));
 
    SPR_update(sprites, 20);

Code:

    while(TRUE)
    {
        handleInput();

// update sprites (only one to update here)
        SPR_update(sprites, 20);

        VDP_waitVSync();
    }


J'ai aussi cette erreur lors du compil.

[dub]

J'ai vérifié dans le debug. Il m'affiche 16 sprites. Alors que j'en init 20 ?



Je vais refaire un test plus parlant.

[dub]

J'ai ajouté 20 sprites sur une taille de 320.
La deuxième ligne en bleu est affiché sous les sprites rouge transparent ms le dixième sprite bleu n'apparait pas. ni sous les autres comme si j'étais limité en superposition ?

J'ai vérifié dans le debug, les positions x et y  pour être sur d'être dans la zone écran et les tailles en pix et tiles ont l'air correct. C'est grave docteur. Qu'es ce qu'ai mal compris dans la doc. J'ai initialisé une place assez grande pr les sprites pourtant.

Ou alors ça vient du la compilation avec l'erreur sur le pointer.

Je vais poster sur gendev.spritesmind.net pour avoir d'autres infos.

[dub]

Je confirme, je suis un "énorme" boulet.

Voilà ma réponse dans ma face de truffe.
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.


Et Bam, seulement 10 sprites pour du 32pix. Comme quoi ça me servira de savoir un lire un jour.


P.S. Mais j'ai toujours mon erreur de compil avec le spriteInit et son pointeur.

[Ricco59_59]

Cette rubrique programmation est truffée de choses exceptionnelles, de programmeurs/graphistes talentueux...
que du bonheur pour le lecteur que je suis...
bravo à tous

[pckid]

Je pensais que Stef, suivais aussi ce thread, car dub semble filer à tout allure.

[philip]

Je pensais que Stef, suivais aussi ce thread, car dub semble filer à tout allure.

Stef lui a répondu sur le fofo gendev.spritesmind 

320 pixels de sprites, c'est le point fort de la machine. 

Sgdk est un outils remarquable. 

[pckid]

Je pense que c'est l'outil le plus abouti pour developper, toute console confondu

[dub]

Oui, Stef est un homme occupé avec tous les beaux outils qu'il nous fait

J'étais passé du côté obscure pour poster en anglais sur son forum et j'ai posté la réponse ici, pour aider d'autres nullos comme moi.

[Stef]

Je vois seulement le message, je n'ai pas assez fréquenté la section programmation du forum dernièrement, désolé !

[pckid]

Stef une petite question sur le driver son de la megadrive, est ce que c'est le Z80 qui gere la puce son de la console ?

Puis je prendre ton driver pour le mettre sur le kit neogeo ?

[Stef]

Stef une petite question sur le driver son de la megadrive, est ce que c'est le Z80 qui gere la puce son de la console ?

Puis je prendre ton driver pour le mettre sur le kit neogeo ?

Oui sur MD c'est généralement le Z80 qui va gérer le son et alimenter le chip FM (YM2612) mais tu peux très bien utiliser le 68000 pour ça aussi (dans ce cas il emprunte le bus du Z80 car le YM est connecté dessus).
SGDK embarque plusieurs drivers sons mais ils sont spécifique à l'architecture de la Megadrive et ne pourront pas fonctionner sur NeoGeo. En fait tu as un driver audio (MVS) qui est à la base dérivé d'un driver son NeoGeo donc à mon avis c'est plutot de ce côté qu'il faut creuser.
tu trouveras plus d'infos sur ce driver MVS ici :

http://gendev.spritesmind.net/page-mvst.html
http://trackerbase.blogspot.fr/2014/02/mvs-tracker.html
http://www.pascalorama.info/article.php?news=30&cat=22

Sinon j'ai trouvé ça sous le nom de "sound driver NeoGeo" :
http://www.spritesmind.net/share/neo.zip

depuis cette page http://neogeocdworld.info/html/aide/programmation.htm

Il est difficile de remettre la main sur le driver son MVS d'origine de la NeoGeo alors que tu trouves facilement la version modifiée pour la MD :-/

[pckid]

Merci Stef,

Je vais voir tes liens. La neogeo , il y a pas mal de barrières c'est pas facile.
Et puis des fois les drivers qui fonctionnent sur emulateur ne fonctionne pas avec le vrai hard.

Encore merci

[emultion]

Topic très intéressant !

Je me suis déjà demandé s'il y avait déjà eu des tentatives "homebrew" pour faire des cartouches moddées, c'est à dire avec des puces additionnelles pour décupler les performances de cette chère Megadrive

[tetsuro]

Je me lance tout juste sur SDGK, le stef qui répond sur ce forum c'est le créateur c'est ça ? En tous cas je vais éplucher ce sujet pour y apprendre un maximum d'infos, ce sujet est une bonne idée, mais plus très actif j'ai l'impression :)

[dub]

Oui, c'est Stef, l'unique. Grand merci à notre magicien numérique pour son sgdk

Le sujet se réactive quand on pose des questions !!!

[pckid]

Topic très intéressant !

Je me suis déjà demandé s'il y avait déjà eu des tentatives "homebrew" pour faire des cartouches moddées, c'est à dire avec des puces additionnelles pour décupler les performances de cette chère Megadrive

Dans le monde du Homebrew en fonction de la puissance du projet, les développeurs choisissent la machine adéquate.

Seul la puissance mémoire d'une cartouche a été dépassé, mais pas les performance graphique ou processeur.

On pourrait branche une cartouche de type Fpga sur une megadrive et brancher un cable hdmi sur ce type de cartouche avec son nouveau processeur.
Mais cela ne serait plus une megadrive.
La seul cartouche qui augmente un peu les capacité en jeu indé , c'est la ng dev team , avec son proc en plus pour détecter les collisions.

[Stef]

Je me lance tout juste sur SDGK, le stef qui répond sur ce forum c'est le créateur c'est ça ? En tous cas je vais éplucher ce sujet pour y apprendre un maximum d'infos, ce sujet est une bonne idée, mais plus très actif j'ai l'impression :)

Et voilà, le sujet se réactive, coup de chance car ça faisait longtemps que je n'étais pas venu dans la section programmation :p
SGDK c'est une librairie pour te faciliter le développement sur Megadrive, ça t'offre des accès à plus haut niveau pour utiliser les capacités de la machine. Je te conseille de regarder les petits exemples fournis dans le répertoire "sample" de SGDK pour voir un peu comment ça marche.
Réellement malgré tout, ça me semble primordiale de bien comprendre comment la Megadrive fonctionne avant de se lancer dans le développement sur cette machine et si tu veux utiliser SGDK je dirais qu'il te faut connaitre aussi le langage C (sans forcément le maitriser mais au moins connaitre les bases). Apprendre 2 choses en même temps (le langage C et l'architecture de la MD) c'est vraiment difficile et tu risques de t'y casser les dents. J'ai vu aussi que tu t’intéressais à l'assembleur 68000 et Z80, je dirais que tu n'as pas forcément besoin de ça pour l'instant, en pur C tu peux déjà faire beaucoup de choses avec SGDK

Oui, c'est Stef, l'unique. Grand merci à notre magicien numérique pour son sgdk

[tetsuro]

Merci Stef pour ta réponse,

Je connais bien les bases du C, j'ai fait un petit Hello World avec ton SDGK sur MD, j'ai déjà manipulé la SDL et en ce moment je suis les cours de BFG sur la Dreamcast. Je n'ai pas peur de me casser les dents, car je suis attiré par la programmation sur Megadrive. Mon but n'est pas seulement de faire un jeu pour faire un jeu, car si c'était le cas j'utiliserais Game Maker, d'ailleurs j'ai déjà réalisé plusieurs petits jeux sur PC et 2 sur Android, j'était le graphiste et le concepteur, pas le programmeur? Donc si mon seul but étais de faire des jeux j'aurais continué comme ça, mais une chose m'appelle dans le fait de programmer proche du hardware.
Je sais bien que je suis loin d'avoir le niveau, mais je voudrais acquérir ces compétences car personnellement ça ne me fait pas trop triper de seulement manipuler des fonctions déjà écrites par d'autres. J'aime comprendre comment ça se passe. Mais je ne compte pas bruler les étapes, je veux réaliser un petit jeu avec ton SDGK et petit à petit approfondir, voir comment ça fonctionne.

1. - D'ailleurs SDGK est écris avec quel langage ?
   
2. - Tu as tout codé totu seul ou récupéré des codes ici et là que tu aurais modifié ?
   
3. - Tu as appris les 68k et Z80 et potasser les docs MD ?
   
4. - J'aimerais bien en savoir un peu plus sur le parcours de SDGK :)
   

[Stef]

Ok, bon au moins ça fait plaisir de voir ton enthousiasme et j'encourage ta vision qui consiste à bien comprendre comment fonctionnent les choses, je suis pareil et ça me semble important :)

SGDK c'est quoi déjà ? A la base c'est un ensemble d'outils qui te permet de développer sur Megadrive. Ca comprend un compilateur C pour 68000 (GCC, classique) ainsi qu'un assembleur pour le Z80, le tout fonctionne sous Windows mais il est aisé de trouver les équivalents linux / osx...
Bien sur tu peux aussi coder en assembleur sur 68000 quand cela est utile.
Sinon à côté de ces outils qui sont la base, j'ai aussi développé une librairie pour faciliter le développement: elle donne accès à des fonctions de haut niveau pour exploiter les capacités hard de la machine (manipulation des sprites, des arrières plans, musique & SFX...) mais tout cela (et notamment la gestion des sprites) se fait parfois au détriment des performances. Heureusement la librairie te permet aussi de travailler à bas niveau si tu le souhaites, ainsi tu peux exploiter au maximum les capacités de la machine mais tu as plus de code à écrire.
SGDK est écrit à 90% en C et 10% en assembleur pour les méthodes "critiques" (car le code généré par le compilo C n'est pas toujours optimisé), j'ai tout écrit "from scratch", je voulais absolument tout controler ce qui se passe :p

En fait avant SGDK j'ai écrit un émulateur pour le Megadrive (Gens), cette expérience m'a permit de me familiariser avec cette machine... puis j'ai commencé à vouloir développer dessus, mais lorsque j'ai commencé (en 2004 je pense) il n'y avait aucun outil potable. Ca me paraissait important de pouvoir développer en C car l'assembleur est bien plus long à produire et complexe à maintenir. A l'époque le seul compilateur C dispo pour la Megadrive (le fameux sgcc) était complètement buggué ! Mais à un point que ça en était ridicule, tu ne pouvais rien faire avec... du coup j'ai entrepris de compiler mon propre GCC avec les bin utils, ensuite j'ai commencé à écrire mes première macros pour faciliter mes développements... et à force ça a donné SGDK :)

[tetsuro]

Merci Stef pour tes réponses fournies et ta réactivité, ça fait plaisir :)

- Je peux coder en ASM 68K et Z80 avec SDGK ? Il reconnaitra ?

Je ne savais pas que Gens était de toi, super boulot.

[Stef]

Merci Stef pour tes réponses fournies et ta réactivité, ça fait plaisir :)

- Je peux coder en ASM 68K et Z80 avec SDGK ? Il reconnaitra ?

Je ne savais pas que Gens était de toi, super boulot.

Merci :p
Pour l'assembleur oui ça fonctionnera tant que tu respectes la syntax des assembleurs intégrés
Les fichiers assembleurs 68000 utilisent l'extension .s (tu peux en trouver dans le répertoire src) et les fichiers assembleur Z80 utilisent l'extension .s80, mais je te rassure, y'a peu de chance que tu en fasses :p

[tetsuro]

Oui j'ai récupérer les sources de jeux commerciaux Megadrive abandonnés par la société mais retrouvées par le programmeur de l'époque, les projets de A à Z, j'ai look par curiosité mais forcément je ne comprend rien, des fichiers partout, des extension bizarres, mais je les garde bien au chaud quand j'aurais un meilleur niveau, je dois déjà être capable de maitriser ton SDGK :)
Pourquoi j'ai peu de chance d'en faire ? Tu parles de quoi de Z80 et ASM68 ? Ça ne me fait pas peur, j'ai déjà acheté un livre sur le 68000 et suivi un tuto en Z80 pour un petit jeu sur Game Boy

[Stef]

Normal que tu ne comprennes rien aux sources des jeux, souvent y'a des outils annexes pour traiter des fichiers de ressources spécifiques, et sans eux tu ne peux pas faire grand chose... puis souvent c'était en pur assembleur.
Sinon je parlais du Z80, l'assembleur 68000 pourquoi pas si tu le juge utile (mais à mon sens tu en as pas besoin pour commencer) mais le Z80 est utilisé spécifiquement pour la gestion du son et réellement avant d'écrire ton propre driver y'a beaucoup à apprendre (pas sur le Z80 mais plutot le chip sonore de la MD) et surtout les drivers son inclus dans SGDK suffiront dans la majorité des cas

[tetsuro]

J'ai un problème avec SDGK sur Code Blocks, c'est normal qu'il n'y ai pas d’auto-complétions ?
Jusque là toutes les bibliothèques que j'ai installé ont l'auto-complétion qui fonctionne, du coup c'est très désagréable avec SDGK ça rend la tache ardue pour remplir les paramètres de fonctions qu'on devrait connaitre par cœur.
D’autres personnes ont aussi déjà eu ce problème ?
Pour info, hors l'auto-complétion SDGK fonctionne bien, j'arrive à build et j'ai suivi à la lettre tes tutos d'installation.

[pckid]

Hello Stef,

Tu as vu avec Dub, pour améliorer dans ton kit, les listes chainées quand on a beaucoup de sprite ?
c'est pour notre jeu, car je me dis comment fonzie a fait dans son cas.

Je crois que Dub est passé par asm, mais du coup on a plus l'aisance des fonctions de base.

merci à toi.

[dub]

non, en fait j'utilise les fonctions haut niveau de Stef.

Après, je me suis amusé à tester des fonctions en asm pour voir la différence mais ça reste du prototypage. J'ai encore bcp à apprendre sur l'asm.

[Stef]

Hello Stef,

Tu as vu avec Dub, pour améliorer dans ton kit, les listes chainées quand on a beaucoup de sprite ?
c'est pour notre jeu, car je me dis comment fonzie a fait dans son cas.

Je crois que Dub est passé par asm, mais du coup on a plus l'aisance des fonctions de base.

merci à toi.

Oui justement c'est le genre de chose qui va changer
Allocation de sprites, meilleur gestion des liens (avec un possibilité de trier les sprites facilement).
Normalement tout ça sera bien plus facile à utiliser

J'ai un problème avec SDGK sur Code Blocks, c'est normal qu'il n'y ai pas d’auto-complétions ?
Jusque là toutes les bibliothèques que j'ai installé ont l'auto-complétion qui fonctionne, du coup c'est très désagréable avec SDGK ça rend la tache ardue pour remplir les paramètres de fonctions qu'on devrait connaitre par cœur.
D’autres personnes ont aussi déjà eu ce problème ?
Pour info, hors l'auto-complétion SDGK fonctionne bien, j'arrive à build et j'ai suivi à la lettre tes tutos d'installation

Chez moi ça fonctionne mais parce-que j'ai toujours le projet "SGDK" dans ma liste (un projet qui permet de compiler la librairie SGDK en elle même). A mon avis, il faut que tu indiques un chemin "include" dans ton projet qui pointe vers le répertoire "sgdk/inc" pour que l'auto completion trouve bien les headers utilisés dans ton code... Mais heu, bizarrement là je n'arrive pas à trouver où tu indiques ça dans les propriétés de ton projet   Comme j'ai pas installé de compilateur particulier dans mon code::blocks j'ai l'impression que je n'ai pas accés à ces options
L'autre moyen c'est que tu te fais un projet SGDK qui contient les fichiers sources et includes de SGDK, ainsi la complétion automatiques trouvera toujours ses méthodes

[troudki]

La seul cartouche qui augmente un peu les capacité en jeu indé , c'est la ng dev team , avec son proc en plus pour détecter les collisions.

il existe ce type de mod sur la Mega Drive, des fonctions déportées dans des proc spécialisés dans la cartouche (comme le SNES) ?

[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??)