Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

XD c'est tout moi. Je pense que je n'aurais pas le choix, je devrais définir le comportement des ennemis un à un. L'idéal serait que je me développe un petit outil qui me permettrait de tester et générér le comportement des ennemis si je veux mettre en place des vagues travaillé. Au boulot !!!!

[uran]

Sympa la routine!

T'en aurais du d'autre du même acabit?

Cela permet de se faire une lib un peu plus haut niveau sans se soucier de réinventer la poudre à chaque fois!

[Tryphon]

C'est déjà d'assez haut niveau SGDK...

[uran]

C'est déjà d'assez haut niveau SGDK...

Euh, moi je dirais que c'est un driver qui permet de coder en C sur MD avec les outils qui vont bien.

Le haut niveau permet de s'affranchir de savoir comment ça marche en bas, typiquement ce qu'a proposé shingosama. Ca simplifie pas mal la lecture du code par la suite, commentaires ou pas commentaires.

Après je suis d'accord que pour l'optimisation ça va compliquer la chose!

[Tryphon]

Un driver ?

Moi je dis que t'as pas dû coder bas niveau souvent pour dire ça. Il y a des commandes bas niveau (exemple, ce qui commence par VDP_) mais le sprite engins est clairement haut niveau (au point que je ne l'utilise pas).

[uran]

Un driver ?

Moi je dis que t'as pas dû coder bas niveau souvent pour dire ça. Il y a des commandes bas niveau (exemple, ce qui commence par VDP_) mais le sprite engins est clairement haut niveau (au point que je ne l'utilise pas).

Je fais juste ça quotidiennement sur de l'embarqué mais bon ...
Allez ne tergiversons pas sur des points de détails.
Je dis juste que quelques fonctions "plus" haut niveau seraient sympa à se partager pour se simplifier la vie.

[Invité]

Uran bosses avec moi et code en C, Assembleur 
, etc ... pour nos bancs de test et carte de commande.
Faut pas venir me chercher mon copain sur ce sujet et commencer a étaler sa science telle la confiture sur le fil du pain.
Avec Sgdk, y en a pour tout le monde, du haut, du bas et quelque soit ton niveau, et bien tu peux t'amuser.
Bon sur ce, je vais chercher des croissants.

[uran]

Uran bosses avec moi et code en C, Assembleur 
, etc ... pour nos bancs de test et carte de commande.
Faut pas venir me chercher mon copain sur ce sujet et commencer a étaler sa science telle la confiture sur le fil du pain.
Avec Sgdk, y en a pour tout le monde, du haut, du bas et quelque soit ton niveau, et bien tu peux t'amuser.
Bon sur ce, je vais chercher des croissants.

Tu m'en ramènes demain ?

[Invité]

Si tu aimes les miettes, oui sans problème ! 

[Tryphon]

Un driver ?

Moi je dis que t'as pas dû coder bas niveau souvent pour dire ça. Il y a des commandes bas niveau (exemple, ce qui commence par VDP_) mais le sprite engins est clairement haut niveau (au point que je ne l'utilise pas).

Je fais juste ça quotidiennement sur de l'embarqué mais bon ...
Allez ne tergiversons pas sur des points de détails.
Je dis juste que quelques fonctions "plus" haut niveau seraient sympa à se partager pour se simplifier la vie.

J'aurais dû préciser : "bas-niveau sur megadrive.

Je ne pense pas qu'enrichir encore SGDK soit une bonne idée, pour plusieurs raisons :

1) plus une solution est générique, moins elle est souple et légère. Or, sur les vieilles machines, la légèreté est primordiale. Là on parle quand même de rajouter une couche SUR le Sprite Engine, qui lui-même est bâti sur le VDP_sprite, ça commence à faire

2) SGDK est une bibliothèque statique, entièrement incluse lors du build dans la ROM, même si tu n'utilises que la moitié des fonctions

3) une partie du plaisir de coder sur les vieilles machines, c'est quand même de réinventer la roue Si t'as pas envie de te prendre la tête, tu prends Unity ou Gamemaker et zou ! (bon, ça c'est une question de goûts)

4) c'est déjà un boulot de fou pour Stef de gérer SGDK. Il faudrait d'autres devs, mais QUi ? Il y a peu de devs dun niveau de compétences similaire, et la plupart de ceux que je connais (sik, r57shell, gasega...) font leur propre cuisine

Par contre, un truc sympa, ça serait des exemples de codes postés et critiqués par des utilisateurs dans lesquels on pourrait repiquer. Par exemple dans le wiki.

[Invité]

Et la possibilité de bosser avec le Mega CD

[Invité]

Et bien grâce à certaine remarque, Stef a grandement amélioré son SgdK en y implantant, par exemple, la gestion du Yorder, et ça c'est déjà énorme car l'utilisateur n'a se soucier de rien.

SgdK est aussi plus véloce qu'avant ( enfin son code compilé ), etc ...
Moi j'y connais rien la dedans, enfin je n'ai pas envie de perdre mon temps et mon énergie à comprendre du Hardware d'il y a 25 ans, j'ai déjà à faire ça avec mon boulot avec du Hardware actuel, et le Devkit de Stef est un super compromis pour des personnes comme moi.

Les autres Jedis des codes obscurs font ce qu'ils veulent, réinventer la roue, etc, ça me va aussi très bien et chacun trouve son compte ( comme le dirai Fréderic, private Joke avec mon ami Uran )
C'est sûr qu'arracher les tripes d'un Hardware dépassé pour en tirer le maximum est très gratifiant en soi, et peu satisfaire les élites du milieu, mais penser aux pauvres codeurs du Dimanche et autres manouches du code qui, de leur côté, font aussi vivre ces consoles mortes au travers de super DevKit comme celui de Stef.

Après, si vous voulez aider Stef et l'encourager à poursuivre ses efforts avec son super Devkit, ben passer par la case Paypal et faites lui un don, car c'est bien le nerf de la guerre n'est ce pas ?
En tout cas, moi je lui suis reconnaissant par le temps qu'il passe la dedans, en plus de son boulot de dingue, donc il a droit de temps en temps à son petit don des Studio Vetea.

@Uran : Trop tard pour les miettes mon ami ...

Et pour terminer ...


Bon Dimanche sous vos applaudissements, y a l'homme qui tombe à pic en ce moment ...

[Stef]

Ne vous inquiétez pas, il y a encore pas mal de fonctionnalités haut niveaux que je souhaite ajouter à SGDK (comme la gestion des maps) tout en m'efforçant de maintenir un niveau de performances "acceptables" sur cette machine. Comme le dit Tryphon, la flexibilité et la généricité se paient sur les performances, et sur une vieille console comme la MD, on peut pas dire non plus qu'on en a à revendre donc je pense qu'il faut trouver un bon équilibre entre les 2, ce que je m'efforce de faire...

Et encore merci Vetea pour tes encouragements et ton support pour SGDK en général

[Invité]

@Stef n'oublies pas d'intégrer la gestion des collisions et différentes fonctions pour calculer rapidement la trajectoire de vecteurs 2D.

Je voudrais m'occuper de l'allocation des sprites dans la VRAM, mais comment savoir si un emplacement est libre ?

[Stef]

Tu peux définir des "regions VRAM" pour l'allocation en VRAM, le sprite engine utilise ça en interne pour allouer les tiles en VRAM.

Il faut utiliser les fonctions VRAM_xxx :

Tu créés une nouvelle "region" VRAM comme suit :

VRAM_createRegion(VRAMRegion *region, u16 startIndex, u16 size);

et ensuite tu alloues / libères des blocs VRAM ainsi:

s16 VRAM_alloc(VRAMRegion *region, u16 size);
void VRAM_free(VRAMRegion *region, u16 index);

[Invité]

@Stef merci ! C'est bon de cette manière  ? :

Code:

    VRAMRegion* region;
    VRAM_createRegion(region, 1, 10);
    SPR_setVRAMTileIndex(player.sprite, 1);

J'ai bien veiller à ne pas utiliser l'allocation 0, car j'avais lu un message venant de toi disant que le SGDK en avait besoin pour fonctionner. D'ailleurs j'ai essayé et c'était pas très joli

Une question que je me pose, pourquoi au début de la VRAM on retrouve une palette de couleur ? Puis-je écrire dessus ?

[Stef]

@Stef merci ! C'est bon de cette manière  ? :

Code:

    VRAMRegion* region;
    VRAM_createRegion(region, 1, 10);
    SPR_setVRAMTileIndex(player.sprite, 1);

J'ai bien veiller à ne pas utiliser l'allocation 0, car j'avais lu un message venant de toi disant que le SGDK en avait besoin pour fonctionner. D'ailleurs j'ai essayé et c'était pas très joli

Une question que je me pose, pourquoi au début de la VRAM on retrouve une palette de couleur ? Puis-je écrire dessus ?

Hmm c'est pas vraiment comme ça qu'il faut l'utiliser :p
Déjà tu as des constantes pour définir l'emplacement VRAM "utilisateur" :
TILE_USERINDEX : premier index de tile
TILE_USERMAXINDEX : dernier index de tile
En gros c'est le premier et dernier index que tu as le droit d'utiliser, car la palette comme tu le dis, ce sont les "plain tiles", il y en a 16, il ne faut pas les écraser (enfin surtout le premier on va dire).

En gros l'organisation de la VRAM dans SGDK c'est comme ça (en "emplacement tile" soit $000-$7FF) :

Code:

ADDRESS START  --> ADDRESS END               FUNCTION
---------------------------------------------------------------
000            --> 00F                       SGDK RESERVED
TILE_USERINDEX --> TILE_USERMAXINDEX         USER SPACE
TILE_FONTINDEX --> TILE_MAXINDEX             FONT
TILE_MAX_NUM   --> 7FF                       TABLES AND TILEMAP

Ensuite il faut savoir que le sprite engine va allouer ses tiles en haut de la VRAM, juste en dessous de la "font" :
index = TILE_FONTINDEX - size;

La mémoire de la font est également réserver et ne doit pas être modifier par l'utilisateur, du coup on a :
TILE_USERMAXINDEX = TILE_FONTINDEX - 1

comme on peut le voir sur mon schéma ci-dessus.
Donc à toi de définir le premier index de ta région VRAM selon ce que tu as alloué au sprite engine et au background (car il faut bien mettre les tiles des background quelque part) !

Ensuite quand tu définis une région VRAM de cette manière (note la différence avec ta version) :

Code:

VRAMRegion region_BG;
VRAMRegion region_spritesFixed;

VRAM_createRegion(&region_BG, TILE_USERINDEX + 0, 768);
VRAM_createRegion(&region_spritesFixed, TILE_USERINDEX + 768, 256);

J'alloue une première région pour les background de 768 tiles puis juste après j'alloue une région de 256 tiles pour les sprites en allocation fixe.

Ensuite quand tu veux allouer un certain nombre de tiles dans ces régions tu fais :

Code:

// allocate 16 tiles for a sprite
ind = VRAM_alloc(&region_spritesFixed, 16);
SPR_setVRAMTileIndex(player.sprite, ind);

...

// release allocated tiles for sprite
VRAM_free(&region_spritesFixed, ind);

Même chose pour les backgrounds...
bien sur tu n'es pas obligé de passer par ça, si tu connais l'organisation de la VRAM tu peux toi même fixer un peu manuellement les indexes de tes backgrounds et de tes sprites fixes, les VRAMRegion sont juste des outils pour gérer ça (un peu) plus facilement.

[Invité]

Merci @Stef pour ces explications

J'ai juste une petite interrogation concernant les sprites animés. Par exemple, une explosion dont l'animation vient juste de démarrer puis une seconde qui débute quelques secondes après, dans ce cas bien précis, je suis obligé de laiser le SPR choisir automatiquement un emplacement libre dans la VRAM ?

[Stef]

Pour les sprites animés, à moins que ces animations soient beaucoup dupliquées (et c'est le cas des explosions) il vaut mieux laisser le sprite engine gérer la VRAM.

[Invité]

Encore merci @Stef ! J'ai fais quelques essais et ça marche au poil. Pour les explosions par exemple, je peux créer un région et appeler à chaque fois VRAM_alloc() afin qu'il trouve un emplacement où y placer le sprite :)

C'est clairement moins le bordel et on évite tout risque de "fuite".

[Stef]

Encore merci @Stef ! J'ai fais quelques essais et ça marche au poil. Pour les explosions par exemple, je peux créer un région et appeler à chaque fois VRAM_alloc() afin qu'il trouve un emplacement où y placer le sprite :)

C'est clairement moins le bordel et on évite tout risque de "fuite".

La région VRAM, tu dois la créé une seule fois et effectivement ensuite tu l'utilises pour allouer / libérer proprement la VRAM si j'ose dire
Mais pour tes explosions, tu ne peux pas précharger tout les tiles pour chaque frame d'animation en VRAM à l'avance (en sauvegardant les indexes pour chaque frame) et ensuite tu changes les VRAM index de tes sprites ?

[fourchette]

@Stef
Je suis passé du SGDK v1.31 à la v1.34, et j'ai constaté un problème de tempo pour les musique en XGM. Avec la v1.31, avec un affichage à 50hz, la musique était bien synchro avec le 50hz. Avec la v1.34, si je ne force pas le tempo, la musique est synchronisée sur 60hz.

Autre point mais pas spécifique à une version, sur un morceau, alors que je demande une seule boucle, j'ai un sample (sur le canal FM 6) qui boucle 1 fois de trop.
Pour être plus précis, le morceau dure 5 sec, un premier sample est lancée au début, dure 2s, suivi d'un 2nd sample, lui aussi de 2s, puis plus rien sur la dernière seconde, mais bien que j'aie demandé un stop, le 1er sample est rejoué une fois alors que tout les reste bien arrêté. Est ce que c'est normal ? Y a-t-il quelquechose que je puisse faire coté code ?
Note : je ne suis pas l'auteur du VGM, le musicien m'a précisé qu'il n'a pas demandé de boucle. Et le VGM est créé sur deflemask.

[Invité]

si tu as le fichier DM, mettre un note_off sur la track 6, quand le sample doit s'arreter ? (je suppose)

[Stef]

Je sais qu'il existe parfois des problèmes avec les loops mais dans le cas présent il n'y a pas de loop donc je ne vois pas vraiment ce qui pourrait poser problème... sinon pour le tempo, en fait avant il y avait un bug au contraire (le tempo de la musique changeait selon la region de la console) ce qui n'est plus le cas actuellement... la musique se joue à la même vitesse qu'on soit en 50 ou 60 hz (ce qui est mieux je pense)

[fourchette]

@kaot:
merci pour l'info, je vais essayer d'obtenir et regarder le ficher DM

@Stef
à priori ça venait de mon rom_head.c qui avait de nouveau sauté au changement de version de SGDK... je n'avais pas fait attention.

[Stef]

Le changement de rom_head.c te cause des soucis ?? peut être qu'il ne l'avait pas recompilé mais c'est juste le header de la ROM donc c'est bizarre que ça puisse faire ça

[fourchette]

J'ai finalement résolu mon problème de sample. Sur le pattern Deflemask, j'ai laissé le filtre 1701 sur la première ligne et décalé le sample sur la seconde.

Est ce que ce comportement est normal ? Faut-il toujours faire comme ça : filtre 1701 pour activer le DAC et ensuite balancer son sample, soit ne pas tout mettre sur la même ligne ?

[Hpman]

Question plutôt relative à GCC mais ca peut éventuellement servir sur MD donc voila:

Y'a des techniques particulières de prévues dans GCC pour compiler des banks de données?
La pour l'instant je compile les banks à part et retranscrit la mapfile en defines pour retrouver les données dans le code principal. Ça fonctionne au poil mais il a peut être d'autres techniques?

Question bonus, on peut y dire de gérer une variable en format BCD?

[Invité]

J'ai finalement résolu mon problème de sample. Sur le pattern Deflemask, j'ai laissé le filtre 1701 sur la première ligne et décalé le sample sur la seconde.

Est ce que ce comportement est normal ? Faut-il toujours faire comme ça : filtre 1701 pour activer le DAC et ensuite balancer son sample, soit ne pas tout mettre sur la même ligne ?

non
ca te fait louper le 1er "temps" rythmiquement. Apres si ca ne boucle pas, osef, mais c'est étrange comme problème.

en pratique tu peux meme alterner dac on/off avec des notes sur la meme ligne que les 17XX.

[Stef]

@HpMan> je n'ai jamais fait perso avec GCC pour la compilation par bank, ça m'étonnerait qu'il y ait des choses particulières pour ça, GCC c'est quand même un compilo assez haut niveau (incompatible avec les CPU 8 bit il me semble).

Pour les valeur BCD, je ne pense pas, tu as peut être des méthodes pour les simuler mais je pense rien qui n'utilisent directement les instructions BCD du CPU :-/

[Invité]

Coucou,
Bon ben après une petite rechute avec BEX pour mon projet BOBC SE ( bientôt publié par CG  ), je vais me remettre tranquille avec SgdK.
Du coup, pas de mise à jour depuis la SGDK 1.33 (November 2017) ?

Je vais réaliser le même tuto "Metal Slug" que j'avais fait avec BEX pour me remettre sur les rails, et après la publication de BOBC SE, me remettre sur mes "chantiers".
Certainement Papi Commando Reload'ed', avec l'apport d'un nouveau graphiste talentueux qui a aussi collaboré sur BOBC SE concernant la Cover et autres petits trucs ...

A bientôt.