Nouveau petit projet SGDK

Salut les pti loups !

Je sais ça fait un bail.
Je me lance dans la réalisation d'un petit jeu pour apprendre à utiliser SGDK, j'avais potassé ça un peu l'année dernière mais sans plus et avant je ne m'occupais que des graphs pour "Alien Hates Japan". Donc c'est mon premier bain dans le SGDK en tant que "programmeur".
Bon j'ai réalisé les tutos basiques sur le Wiki de Stef.
Mais déjà j'ai des questions, ben oui, lol.

Je ne cherche pas à déplacer un sprite mais une tile que je créer. J'y arrive mais : 
- 1. L'écran ne rafraîchi pas et donc la tile créer une "traînée" (lol). 
- 2. Le déplacement est trop rapide, j'incrémente de 1, je m'attends à un déplacement pixel par pixel et plutôt fluide hors j'ai un déplacement qui parait aller de 16 en 16 
- 3. Et pour finir mes positions x et y ne se font pas, la tile reste à 0,0.

Je colle mon magnifique code (attention il est copyright  ): 

Code:

#include <genesis.h>

const u32 myTile[8];

int main()
{
    // Start positions
    u32 x = 64;
    u32 y = 163;

    // Load tile in VRAM
    VDP_loadTileData((const u32*)myTile, 1, 1, 0);

    VDP_drawText("Move tile test (08/01/2019)", 1, 1);

    while(1)
    {
        // Display tile
        VDP_setTileMapXY(PLAN_A, TILE_ATTR_FULL(PAL2, 0,0,0,1), x, y);

        // Pad
        u16 value = JOY_readJoypad(JOY_1);
        if(value & BUTTON_RIGHT) x += 1;
        else if(value & BUTTON_LEFT) x -= 1;

        VDP_waitVSync();
    }
    return(0);
}

// Create tile
const u32 myTile[8]=
{
    0x77777777,
    0x77777777,
    0x77777777,
    0x77777777,
    0x77777777,
    0x77777777,
    0x77777777,
    0x77777777,
};


Merci d'avance pour votre aide les copains 

Tu confonds donc les propriétés d'un tile et ceux d'un sprite, mauvais départ ^^

Un tile est FIXE sur un background (grille),
pour le faire "déplacer" il faut déplacer le background complet (aka scroll)

Pour faire "bouger" un tile (et non un sprite), il n'y a pas 50 solutions :
- maj de la tilemap (remplacer un tile par un autre à une coordonnées X/Y)
- recharger le tile dynamiquement en VRAM (par une autre version, ce qui l'animera)
- scrolling
- effet de type raster (flamme, vague, route, ...) / que je placerais dans les scrolling "particuliers"

ps. la position de ton tile doit etre comprise grosso modo entre [0..32] sur X et [0..30] sur Y (enfin le nb de tiles X/Y de la MD)

Ensuite pour le faire bouger de "case en case", il faut aussi effacer la position précédente...

Salut Tutsero :)

Heureux de voir que tu te re-plonges dans SGDK :p

Alors par rapport à ta question, disons ce n'est pas la façon normale de "déplacer" un tile ^^
Soit tu veux déplacer des objets librement et indépendamment au pixel près dans quel cas tu utilises des sprites, soit tu veux déplacer un background complet (scrolling) dans quel cas tu changes les valeurs de scrolling du background après avoir charger les tiles du décor :)

Aussi les tutoriaux ne sont pas à jour et limite je déconseille de les utiliser (oui je devrais les virer je sais ). Inspire toi plutot ce que tu peux trouver dans les samples inclus dans SGDK, ils sont bien commentés et permettent d'utiliser correctement les différentes méthodes (comprendre par là que tu seras bien plus efficace).

L'exemple 'sprite' est assez complet, je te conseille de le potasser un peu :
https://github.com/Stephane-D/SGDK/tree/master/sample/sprite

Edit: grilled par Ichigo

Bon j'ai testé cet aprem et grâce à votre aide j'ai réussi un premier déplacement de sprite , mais j'aimerais un avis sur ma façon de faire car je navigue entre les tutos datés et récents.
J'ai vu qu'il y avait une autre façon de update son sprite avec SPR_update(); quand moi j'utilise VDP_updateSprites(); (sans vraiment savoir comment il marche) , c'est quoi le mieux ?

Mon nouveau code :

Code:

#include <genesis.h>

const u32 mySpriteTiles[4*8]=
{
    0x77777777,
    0x70000000,
    0x70000000,
    0x70000000,
    0x70000000,
    0x70000000,
    0x70000000,
    0x70000000,

    0x70000000,
    0x70000000,
    0x70000000,
    0x70000000,
    0x70000000,
    0x70000000,
    0x70000000,
    0x77777777,

    0x77777777,
    0x00000007,
    0x00000007,
    0x00000007,
    0x00000007,
    0x00000007,
    0x00000007,
    0x00000007,

    0x00000007,
    0x00000007,
    0x00000007,
    0x00000007,
    0x00000007,
    0x00000007,
    0x00000007,
    0x77777777
};

u32 x = 150;
u32 y = 90;

int main()
{
    VDP_drawText("Sprite tiles display test (08/01/2019)", 1, 1);

    VDP_loadTileData((const u32*)mySpriteTiles, 1, 4, 0);

    while(1)
    {
        VDP_setSprite(0, x, y, SPRITE_SIZE(2,2), TILE_ATTR_FULL(PAL0,1,0,0,1));

        VDP_updateSprites(1, TRUE);

        // Pad
        u16 value = JOY_readJoypad(JOY_1);
        if(value & BUTTON_RIGHT) x += 1;
        else if(value & BUTTON_LEFT) x -= 1;

        VDP_waitVSync();
    }
    return(0);
}

Et pour finir je ne comprends pas trop la logique de cette ligne :

Code:

u16 value = JOY_readJoypad(JOY_1);

@ichigobankai: Merci pour ton aide copain. Eh oui au début on est pressé et on saute des étapes, mais j'ai potasser et testé cet aprem et je commence à comprendre les différences.
Et comment tu fais pour refresh un background par exemple ?

@Stef: Merci pour ta réponse poto, oui j'ai un peu galéré pour tes tutos Wiki car obsolètes, je l'ai bien vu :) Mais ça donne des bases quand-même donc merci quand-même pour le travail que t'avais fait, c'est mieux que rien. 
Je sais qu'on te l'a déjà dit milles fois, mais merci pour ton formidable travail pour SGDK, tu as crée une chance à des gens comme moi de se lancer dans le dev de machines rétros.

On ne refresh jamais un background complet (enfin sur SMS ca n'est pas possible), juste des bribes.
Quand tu scrolles ton background tu prépares/charges (hors-screen) la partie qui va être visible ensuite (en général une colonne ou rangée de 8 ou 16 pixels -cad 1 ou 2 tiles * la hauteur ou largeur-)

Si tu veux changer l'écran au complet, tu feintes (enfin perso c'est ce que je fais), avec un fondu enchainé (en modifiant les palettes donc) et pendant que l'écran est rempli d'une seule couleur, charger les nouveaux tiles/tilemaps. Quelques frames de plus à 60fps, c'est peanuts

Merci pour tes infos Ichigo.

@Stef ou @ichigobankai ou quelqu'un d'autre bien sur lol : 

Dans la fonction VDP_loadTileData(); j'ai du mal à comprendre deux choses :

- 1. Le concept d'index. Je comprend un peu l'idée, mais j'ai du mal à visualiser, ou peut-on voir cet index ? Comment le gérer quand j'aurais plein de tiles ou sprites ? J'ai look sur GENS KMOD dans VDP mais la tile ne change pas de place même si je met 13 ou 1 en index par exemple. Quels sont les intérets de jouer avec cet index et les positions ?

- 2. Je ne comprend pas trop aussi le mode de transfert, dans le Doxy il est dit qu'il faut mettre "CPU/DMA/DMA_QUEUE" et dans le Wiki il y a écrit 0, et aussi je ne sais pas trop ce que c'est le DMA etc. Je devrais potasser la doc Genesis ? Mais elle est orientée ASM...

Vous connaissez une doc ou un site qui explique les bases du fonctionnement de la MD (VDP, DMA, VRAM,...) ?

Salut Tetsuro ! passe sur le discord du Studio Vetea à l'occas' , y'a l'élite Française qui t'aidera avec plaisir  

@Tetsuro, l'index c'est bien ce que tu as décrit ;
Le numéro de placement de ton tiles en VRAM (ou de la couleur d'une palette en CRAM)

La fonction VDP_loadTileData(*adr, index, nb_tiles, transfer_method)
je suppose que les CPU/DMA/DMA_QUEUE c'est des defines avec des valeurs 0/1/2 (je dis ca sans regarder la doc)
le DMA (Direct Memory Access) c'est pour les transferts "rapides". Apparement à utiliser plutôt pendant un vblank.
https://segaretro.org/Sega_Mega_Drive/DMA

Savoir quelle sont les emplacements de tes tiles en vram peut te permettre de les mettre à jour / remplacer sans tout écraser (en mettant a jour juste ce dont tu as besoin, gain de temps/bande passante tout ca).
Pour un background ca n'est pas forcément nécessaire de savoir ou est chaque tiles. Par contre pour un personnage (en sprite) qui l'on rechargerait de façon dynamique toutes les x frames, là ce serait important de connaitre le nombre maximum de tiles à reserver.

Faudrait que je me mette à  coder sur MD/tester le SGDK... enfin dès que j'aurais terminé mes 2/3 trucs SMS en cours

Moi je te conseillerais la lecture de ce document, qui est toujours ma référence sur le VDP :

genvdp.txt par Charles McDonalds

Merci les potes j'ai commencé à potasser vos docs 

- C'est quoi les "nametables" ? (les nametables des données de scrolling par exemple).

- Et je ne comprends pas bien le fonctionnement du placement des sprites sur le plan de 512x512, qui débute à 128x128 qui est la taille de l'écran 320x224 avec des zones visibles et cachés, je saisi pas, vous pouvez m'éclairer ?
- Si vous avez d'autres docs et liens je suis preneur !

@ShiningBZH:
Lol la vidéo, ça donne vraiment envie de venir. Oui je suis déjà sur le discord de Vetea mais j'avais oublié cette option lol, donc j'y repasserais, merci de m'y avoir fait penser. Mais je me dis que c'est tourné beaucoup autour de lui et ses jeux et je me voyais pas trop venir en mode noob poser des questions hors sujet des jeux Vetea :)

@ichigobankai:
Merci une fois de plus pour ta réponse, tu as l'air de bien t'y connaitre pour quelqu’un qui n'a pas programmé sur Megadrive.
Pour le dernier flag de la fonction VDP_loadTileData(), j'ai regardé en détail le Doxy et il ne met pas les valeurs numériques, d'autant plus que dans CodeBlocks en survol il est écrit qu'il attends une constante define. Mais oui tu as surement raison, ça doit être 0/1/2 et il doit trouver ça tellement logique qu'il ne l'a pas écris
Moi j'aimerai bien me mettre plus tard à la prog SMS, tu codes en C ou ASM et c'est quoi tes projets ?

@Tryphon:
Merci pour le lien, j'ai commencé sa lecture de ce pas !

les "nametables" d'après ce que je sais, c'est la définition (parametres) de tes plans A et B.

Sur MD, les plans peuvent/sont plus grands que la zone affichable.
D'après le wiki de SGDK :

Each plane can be a maximum of 4,096 tiles in memory (at dimensions 32x32, 32x64, 64x64, or 32x128, with up to 40x28 visible on screen)

Je ne sais pas si tu peux définir toi même la taille des plans ou si c'est Stef dans le SGDK qui l'a fixé.

Tes sprites ont des coordonnés vis à vis du plan complet et non de la zone seulement visible (ils peuvent donc être hors screen, mais quand même définit/être animé/se déplacer etc.)

pour répondre a qq questions, je n'ai pas développé avec le SGDK, par contre j'ai hacké quelques jeux MD/68000. Concernant la SMS y'a 2 projets posté ici, à toi de les trouver ^^ . Pour finir je code en C et ASM.

Il faut que tu comprennes comment fonctionne l'affichage de ces machines avant de coder dessus, franchement essayer d'apprendre les 2 en même temps je trouve que c'est très difficile.
Il y a plein de sites qui expliquent ça assez bien :
https://www.schmid.dk/blog/2017-08-06-genesis-tiles/
https://megacatstudios.com/blogs/press/sega-genesis-mega-drive-vdp-graphics-guide-v1-2a-03-14-17

L'idée c'est que sur MD tu as 2 plans de background définis par un tilemap (ou namestable, playfield...). Ce tilemap n'est ni plus ni moins qu'une table représentant ton plan sous forme de bloc de 8x8 pixels (qu'on appelle tile ou character) et où chaque tile est identifié par son index (sa position en VRAM).
Encore une fois c'est vraiment important d'avoir une bonne vision de comment fonctionne ces machines avant de te lancer dans la programmation sinon c'est certain tu vas galérer Aussi SGDK te donne beaucoup de méthodes de haut niveau qui te permettent de t'abstraire un peu de tout ça, genre les méthodes VDP_drawImage(..) ou le couple VDP_loadTileSet(..) + VDP_setMap(..) mais il faut utiliser les ressources pour ça (et donc comprendre leur fonctionnement). Pour ça je te renvoie encore à l'exemple 'sprite' fournis dans SGDK.

ichigobankai a écrit:les "nametables" d'après ce que je sais, c'est la définition (parametres) de tes plans A et B.

Sur MD, les plans peuvent/sont plus grands que la zone affichable.
D'après le wiki de SGDK :

Each plane can be a maximum of 4,096 tiles in memory (at dimensions 32x32, 32x64, 64x64, 128x32, or 32x128, with up to 40x28 visible on screen)

Je ne sais pas si tu peux définir toi même la taille des plans ou si c'est Stef dans le SGDK qui l'a fixé.

Par défaut SGDK les met à 64x32 (pour économiser un peu de VRAM) mais l'utilisateur peut bien sûr modifier ce paramètre.

Tes sprites ont des coordonnés vis à vis du plan complet et non de la zone seulement visible (ils peuvent donc être hors screen, mais quand même définit/être animé/se déplacer etc.)

En fait la position des sprites n'est pas "connecté au plan" (ou alors tu voulais dire le plan sprite), c'est juste que les sprites ont une position allant de -128 jusqu'à 768 (ou un truc dans le style) et peuvent donc être effectivement en dehors de l'écran.

@ichigobankai:
Merci copain pour tes explications, ça me donne des pistes de réflexions et je potasse !
Je suis tombé sur tes projets, mais je vais relook ça.

@Stef:
Merci pour tes explications et tes liens.
Ce n'est pas parce que je pose des questions que je ne comprends rien , j'ai la manie de TROP tout vouloir comprendre avant de me lancer, mais je teste, je sais programmer, j'ai même codé en ASM, j'ai déjà réussi tes tutos et samples, mais dès que j'ai un doute je demande car j'ai cette chance et j'en profite 
Mon gros défaut c'est d'avoir exploré milles choses sans jamais vraiment les approfondir. Mais je veux changer ça et aller au bout de ce petit projet.
Et ça ne me fait pas peur que ce soit difficile, c'est stimulant. Je créer ma propre doc de mon côté pour m'y retrouver et mieux assimiler. En tous cas merci d'être toujours dispo pour les noobs avec ton level, c'est génial.

tetsuro a écrit:@Stef:
Merci pour tes explications et tes liens.
Ce n'est pas parce que je pose des questions que je ne comprends rien , j'ai la manie de TROP tout vouloir comprendre avant de me lancer, mais je teste, je sais programmer, j'ai même codé en ASM, j'ai déjà réussi tes tutos et samples, mais dès que j'ai un doute je demande car j'ai cette chance et j'en profite 
Mon gros défaut c'est d'avoir exploré milles choses sans jamais vraiment les approfondir. Mais je veux changer ça et aller au bout de ce petit projet.
Et ça ne me fait pas peur que ce soit difficile, c'est stimulant. Je créer ma propre doc de mon côté pour m'y retrouver et mieux assimiler. En tous cas merci d'être toujours dispo pour les noobs avec ton level, c'est génial.

Je ne doute pas que tu sais programmer Je voulais dire programmer sur MD et en même temps apprendre comment fonctionne la MD.
Si en plus tu devais apprendre le langage C alors honnêtement je te dirais de ne pas aller plus loin, ça ne servirait à rien ^^
Mais tu vois, ta première question où tu essayais de bouger un 'tile' montrait clairement que tu n'étais pas très familier de la machine (clairement on ne fait jamais de cette manière ^^) d'où l'importance de la connaitre un peu (la partie video au moins) avant d'aller plus loin

Pourtant j'ai appris le 68k comme ça lol, en même temps que la prog Atari ST et son fonctionnement, ça été dur c'est vrais, mais quand je suis motivé rien ne m'arrête :) (Puis j'ai lâché c'est dommage)
J'avais même commencé à apprendre le Z80 du CPC sur un livre en anglais alors que mon level d'anglais est bas.
C'est dire la motivation, quand je l'ai :)
Je dois rester focus, Je dois rester focus, Je dois rester focus... à copier 100 fois 

Haha oui je crois que c'est le plus important, quand on s'éparpille dans trop de choses (à cause d'une trop grande curiosité) on ne peut pas appronfondir..

Oui tu as vu juste, je suis trop curieux, trop gourmand, avide de savoirs dans ce domaine, tout savoir, alors je butine ici et là, je veux tout faire en même temps, mais à la fois je ne fais rien à cause de cette façon d'être.
Mais là ça me fatigue, quand je me rend compte qu'au final avec mon bagage de savoir je ne sais pas faire un jeu jusqu'au bout.
T'es déjà passé par cette étape j'ai l'impression :)

Ah bah j'ai un peu le même problème mais j'en suis conscient du coup je me limite beaucoup, je suis assez réaliste sur ce que je suis capable de faire (avec le peu de temps libre dont je dispose) donc j'évite de m'engager dans trop de choses

Je fais un petit hors sujet, je me trompe où c'est beaucoup moins vivant ici depuis que la clique est partie ? (Vetea, TOUKO, etc)
Comme ils sont tous sur le Discord de Vetea ils n'ont peut-être plus l’intérêt de venir ici.
C'est cool en sois le Discord, j'y suis aussi, mais un forum ça laisse des traces, des aides, des sujets, là où un Discord est assez volatile, ce qui est dommage dans un sens, c'est une perte pour les débutants qui viendraient sur Gamopat par rapport à quand j'ai connu Gamopat y'a 3 ans.

Bah si, Vétéa, Touko et les autres continuent à poster ici...

(c'est quoi un discord ?)

un messenger amélioré ^^
J'échange aussi sur quelques discord mais rien de très avancé (dans l'interface elle même), car c'est vite perdu dans les limbes.
C'est pour du coup de pouce/blabla rapide.
Si tu veux poster du code, faut mettre ca sur pastebin (ou autre) et filer le lien à celui qui doit lire.
L'avantage de discord c'est que c'est multipatformes (c'est meme non obligatoire à installer, ca existe direct en ligne)

Tu peux poster du code aussi de la manière suivante :
```
Ton code

```
Sinon Ichigo a bien résumé.
Et oui on continue à poster avec notre aller/retour avec Touko. 

oui c'est vrai les `xxxx`permettent de poster en mode console.
Mais bon quand mon pote me file des trucs à vérifier qui font 1000 lignes en C c'est pas über pratique ^^

C'est comme slack alors ?

J'ai jamais aimé. Je préfère un forum, voire un wiki

Sinon si on te file un code de 1OOO lignes en C, c'est qu'il est mal organisé

Tu devrais essayer Tryphon, c'est bien, on y est tous pour discuter en direct, comme un forum ça laisse trace des dials, pour dial en direct avec Stef et Vetea ça change. Ça te coûte rien d'essayer, tu y sera bien accueilli tout comme je l'ai été.


Sinon pour en revenir au sujet :)
J'arrive à créer un sprite, à le déplacer, à créer des tuiles, à mieux comprendre le concept du VDP et ses RAM.
Là je vais m'attaquer au scrolling.

Une question justement, le scrolling on peut le réaliser en code pur sans utiliser les fonctions du SGDK, mais est-ce que ça serait pertinent d'après vous ?
Comment vous le faites vous ? Quelles fonctions vous préférez ou quel algo ?
Je faisais mes propres scrollings en LUA, mais on est pas en LUA :)

Yo, voilà j'ai réalisé un scrolling sur 2 plans qui scrollent à vitesses différente (un parallaxe ça s’appelle je crois).
Je voulais votre avis sur le code, il fonctionne mais je veux savoir si il est bon pour une MD, dans le sens MD friendly, car la rom fonctionne sur ma MD+Everdrive.

Code:

// Test scrollings - 12/jan/2019 - (by Tetsuro)

#include "genesis.h"
#include "bgb.h"

int main()
{
    // SGDK variables types
    s16 xb = 0;
    s16 yb = 0;
    s16 xa = 0;
    s16 ya = 0;

    // bgb.png palette
    VDP_setPalette(PAL0, sea.palette->data);
    // bga.png palette
    VDP_setPalette(PAL1, tree.palette->data);

    // Load pictures in VRAM
    VDP_drawImageEx(PLAN_B, &sea, TILE_ATTR_FULL(PAL0, 0,0,0,1), xb, yb, 0, CPU);
    VDP_drawImageEx(PLAN_A, &tree, TILE_ATTR_FULL(PAL1, 0,0,0,384), xa, ya, 0, CPU);

    while(TRUE)
    {
        // Update scollings
        VDP_setHorizontalScroll(PLAN_B, xb);
        VDP_setHorizontalScroll(PLAN_A, xa);

        // Pad
        u16 value = JOY_readJoypad(JOY_1);
        if(value & BUTTON_LEFT)
        {
            xb++;
            xa = xa +2;
        }
        else if(value & BUTTON_RIGHT)
        {
            xb--;
            xa = xa -2;
        }

        // TV
        VDP_waitVSync();
    }
    return(0);
}


Sinon j'ai vu aussi que les plans bouclent automatiquement, j'ai cru lire sur la doc que c'était une feature MD, c'est ça où c'est une feature SGDK ?

C'est une feature MD (et d'ailleurs à ma connaissance toute console). En général, vu que ta carte est plus grande que ton plan, tu traces petit à petit les colonnes qui apparaissent à l'extrémité droite (pour voir comment ça marche, prends un ému type Gens et active le Plane Explorer).

Ton code est correct. Déclare ton u16 value au début du main, pas dans la boucle (c'est pas beau).

Ce n'est pas ça un parallaxe : un parallaxe c'est quand tu fais scroller des LIGNES à des vitesses différentes sur UN SEUL plan (enfin je crois).

Coucou Tryphon, j'ai testé de déclarer le u16 dans le main et ça ne fonctionne pas, le pad ne répond plus, il faut le déclarer dans le while, Stef dit de faire comme ça, j'ai suivi :)
J'ai regardé pour le parallaxe car j'avais un doute et si si, un simple défilement sur 2 plans ou plus est un parallaxe : https://en.wikipedia.org/wiki/Parallax_scrolling

Y a aucun problème pour gérer tes variables locales dans une boucle, t'inquiètes pas.

Tu peux aussi remplacer les xa=xa+2 par xa+=2 ( ou xa-=2 )
Les syntaxes du C ...
Bravo en tout cas pour tes avancées !