Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

Merci pour ta réflexion, car je viens de remarquer que je voulais faire un sprite_player.x alors qu'il fallait récupérer la valeur directement dans le tableau de sprites sprites[0]->x

Je voulais simplement récupérer la position du joueur afin de définir un point de départ pour les bullets :p

[lincruste]

Un simple sprite.x ? Ça marche pas ?

la syntaxe à point comme ça ça fait très POO, ce serait très étonnant que le sdk de stef fonctionne comme ça.
D'ailleurs je me demande comment ces valeurs sont stockées, si c'est un cache, si ça se lit dans la vram, aucune idée.

[Tryphon]

Le SGDK de Stef est très bien écrit, il utilise beaucoup les struct et j'ai vérifié, c'est bien comme ça

C'est un cache. La structure Sprite de SGDK est beaucoup plus complète qu'un simple sprite hardware.

[lincruste]

j'ai vérifié, c'est bien comme ça

fortiche

[Invité]

Galère galère le C quand t'es habitué au C++. Quand je tente de supprimer un sprite via SPR_releaseSprite(bullets[i]) tout l'écran s'efface et le programme se bloque Sûrement un problème dans le tableau

[Tryphon]

Vraisemblablement une confusion entre pointeur et objet. Comment as-tu défini bullets ?

[Invité]

Vraisemblablement une confusion entre pointeur et objet. Comment as-tu défini bullets ?

Code:


Sprite* bullets[100];


J'ai mis 100 pour être tranquille pour mes tests

Code:

static void bullet_update()
{
    int i;
    for(i=0;i!=bulletCount;i++) {
        bulletposy[i] -= BULLET_SPEED;

        SPR_setPosition(bullets[i], bulletposx[i], bulletposy[i]);

        if(bullets[i]->y < 0) {

            SPR_releaseSprite(bullets[i]);
            bullets[i] = bullets[i+1];
            bulletposx[i] = bulletposx[i+1];
            bulletposy[i] = bulletposy[i+1];
            bulletCount -= 1;
        }

    }



Dès que le premier bullet sort de l'écran tout plante

edit : j'ai compris l'erreur, j'ai mis des -1 a côté des i, maintenant ça ne bloque plus !

edit2 : bon bah ça marche ! J'ai demandé à parcourir le tableau entier et c'est nickel, reste plus qu'à intégrer un petit timer :p

[Tryphon]

À première vue, j'ai l'impression que si la bullet supprimée n'est pas la dernière, ton code va dupliquer la bullet[i + 1] dans bullet[i] et supprimer la dernière.

Je ne pense pas que c'est ce que tu veux faire. Je dis peut-être une bêtise, j'ai mal au crâne

[Invité]

Hum je vais faire des tests, car sans timer quand j'appuie sur le bouton ça me lance une tonne de bullets, mais aucun souci, ça ne plante pas. Je dois attendre que tous les bullets soit supprimés pour pouvoir retirer. J'ai testé en définissant le max à un bullet et ça ne plante pas non plus, il fait son petit chemin et se fait supprimer du tableau.

[uran]

À première vue, j'ai l'impression que si la bullet supprimée n'est pas la dernière, ton code va dupliquer la bullet[i + 1] dans bullet[i] et supprimer la dernière.

Je ne pense pas que c'est ce que tu veux faire. Je dis peut-être une bêtise, j'ai mal au crâne

J'suis un peu du même avis (et dans le même état...)
Celle supprimée est celle de l'index "i" (pas super parlant comme nom de variable au passage) et il recopie la boulette i+1 à la place de celle qui vient d'être supprimée.
Cependant, ça duplique donc la "i+1" et supprimer la dernière qui sera balayée.
Du coup on se retrouve avec un doublon de boulettes, celle que l'on ne veut plus de supprimer, mais la dernière du tableau qui ne sera plus actualisée.

[Invité]

À première vue, j'ai l'impression que si la bullet supprimée n'est pas la dernière, ton code va dupliquer la bullet[i + 1] dans bullet[i] et supprimer la dernière.

Je ne pense pas que c'est ce que tu veux faire. Je dis peut-être une bêtise, j'ai mal au crâne

J'suis un peu du même avis (et dans le même état...)
Celle supprimée est celle de l'index "i" (pas super parlant comme nom de variable au passage) et il recopie la boulette i+1 à la place de celle qui vient d'être supprimée.
Cependant, ça duplique donc la "i+1" et supprimer la dernière qui sera balayée.
Du coup on se retrouve avec un doublon de boulettes, celle que l'on ne veut plus de supprimer, mais la dernière du tableau qui ne sera plus actualisée.

Donc la solution serait i-2 étant donné que la bullet courante est -1 ? J'ai essayé et ça fonctionne.



Vous moquez pas de mes sprites, c'est du fait-maison ! Par contre, j'ai toujours pas compris pourquoi le fond est toujours visible

[uran]

Ben non, le solution est de supprimée le sprite en index i, et ne plus s'en occuper tant qu'il n'est pas recréé.
J'utiliserais un attribut du genre vivant que je testerais lors du scan du tableau de sprite bullet.

Code:

if(Bullet[i].Alive == true)
{
    //refresh X/Y/SPEED/.. Bullet
}

pareil pour recréé une nouvelle, tu scan jusqu'à avoir un emplacement dispo, si il y en a. Le nombre de bullet étant limité et fixe(à créer "MaxBullet", en plus du nombre de bullets existant (ici "bulletCount").

Enfin c'est une façon à moi de faire...

[Tryphon]

Si tu tiens absolument à retirer la bullet, il faut décaler toutes celles qui suivent celle que tu retires.

L'idéal serait d'avoir une deuxième variable j qui compte le nombre de bullets effacée, comme ça tu fais :

bullets[i] = bullets[i + j];

pour toutes les bullets. Tu as juste à incrémenter j à chaque bullet à effacer.

Mais perso je pense que je ferais comme Uran.

[Fax]

+1 pour la solution de Uran. C'est exactement comme ça que je fais dans mon jeu.

Pour ton fond ça doit venir d'un VDP_setFillRect () qui prend en argument la couleur rose de ta palette. Parfois aussi si une image est trop grosse, le sgdk l'inore et on se retrouve avec un fond uni au lieu de notre image.

Et tes sprites sont beaux ^^

[uran]

J'suis assez d'accord avec Tryphon et Fax

[Invité]

Oui, elle est pas mal comme méthode, il me semble que j'utilisais le même procédé en C++ pour mon jeu. Par contre, si je ne me trompe pas, que je supprime ou pas le sprite dans le tableau n'a aucune incidence sur les performances?

[uran]

Cela dépendra du traitement que tu fais quand le sprite existe, si c'est rapide et court, je dirais que ça ne sera pas trop perceptible, par contre si c'est tu mets un tas de trucs tu risques de sentir la différence.

Sinon pour faire ça bien, tu mesures le temps de traitement quand ton sprite existe, et tu mets une tempo de même durée dans le traitement de quand il n'existe pas pour compenser.

[Invité]

Aussitôt dit, aussitôt fait !

J'ai donc créer une structure appelée "Bullet" histoire d'avoir un code propre et organisé. Dedans j'ai mis le sprite comme ça je suis tranquille. J'ai donc fait en sorte que dans le bullet sort de l'écran, il se met inactif et sera appelé en cas de besoin. J'aime bien cette façon de recycler les choses.

Maintenant que j'ai pu réaliser le système de bullet, je vois mieux comment travailler sur la suite. J'apprécie vraiment le SGDK de Stef, c'est un régal de le découvrir. Demain je pense mieux structurer mon code et peut-être bossé sur quelques sprites.

Je pense que je vais aussi créer un topic dédié histoire de ne pas trop polluer.

[Invité]

Me revoilà d'attaque ce matin :)

Je voulais savoir si c'était normal que Code Blocks n'auto-complète pas avec SGDK. Ce n'est pas super évident quand on connaît pas sur le bout des doigts le nom des fonctions et je dois sans cesse regarder le source.

edit : si quelqu'un pourrait m'expliquer comment marche le timer du SGDK, se serait vraiment sympa, car j'ai un peu du mal à l'utiliser. Merci :)

edit2 : j'ai écris ce petit bout de code qui fonctionne assez bien :

Code:



if(value & BUTTON_A)
        {
            if(bulletCount < MAX_BULLETS)
            {
                int i;
                if(getTimer(500, 3000) > 3000)
                {
                    for(i=0; i != MAX_BULLETS; i++)
                    {
                        if(bullets[i].active == 0)
                        {
                            bullets[i].position_x = player.last_position_x+8;
                            bullets[i].position_y = player.last_position_y;
                            bullets[i].active = true;

                            bulletCount++;
                            break;
                        }
                    }
                }
            }
        }


[Stef]

Pour que Code:Blocks parse les fonctions de SGDK le plus simple c'est d'ajouter un projet SGDK qui contient toutes les sources de SGDK (repertoires 'src' et 'inc'). Moi je l'utilise souvent car je touche la lib ^^ mais je pense que c la manière la plus simple d'avoir l'auto complétion. Pour les fonctions timer, tu es regardé la documentation des fonctions ? car là vu les paramètres que tu lui envoies j'ai un petit doute ^^ de mon côté je vais voir si je n'ai rien cassé dessus car on m'a remonté un problème il y a peu.

[Invité]

Je t'avoue que j'ai pris l'info sur un forum anglais, mais effectivement en lisant la doc, mes paramètres sont dans les choux.

Un truc me chiffonne à propos de la musique et sons sur Mega Drive. Dans l'exemple SOUND, je vois qu'il est possible de faire tourner des morceaux en WAV. Je croyais que la Mega Drive n'était pas capable de lire un fichier pré-enregistré. Du coup, pourquoi réaliser des morceaux avec le synthé de la Mega Drive ? N'est-il pas mieux de directement lire un fichier audio qu'on a réalisé avec un programme comme FL Studio ?

[Invité]

ca va prendre grave de rom pour un résultat mouaif-cracra.
alors qu'une zique FM a un poids assez négligeable en comparaison.

[Invité]

Idem pour les sound fx ?

[Invité]

je crois que c'est obligé pour les sfx par contre (du moins la derniere fois que j'ai demandé a stef). mais comme tu restes sur des sons assez courts, le probleme de la place se pose moins.

[lincruste]

Idem pour les sound fx ?

[Stef]

Si tu utilises les drivers sons inclus avec SGDK alors oui tu n'as pas le choix, les bruitages sont des samples (wav) mais c'est effectivement pas très gênant car les bruitages sont en général assez courts et ça bouffe donc pas trop de ROM.
Je te conseille d'utiliser le driver XGM, ça te permet d'avoir 4 voies PCM (avec la musique FM / PSG à côté) et ça prend un fichier VGM en entrée pour la musique (qui est un format facile à produire).

[Invité]

@Stef merci pour tes explications :)

Hier, j'ai un peu travailler sur le scrolling, ça marche, car rien de plus simple, mais je rencontre un problème avec mon background. Lorsque je veux afficher un background en 320x244 sur le PLAN_A ou PLAN_B, pas de problème, mais dès que je passe sur du 640x244 ou plus, c'est le drame. Sur le PLAN_A le background s'affiche très mal comme si SGDK voulait écraser l'image pour que ça rentre dans du 320x240 et sur le PLAN_B, l'image est décalée sur la droite avec une partie fixe en haut et une partie qui scroll.

[Tryphon]

T'es au courant que le plan A et le plan B font au max 512x512 ?

Si tu veux faire du 640, il faut que toi même tu mettes à jour le plan en dessinant la colonne de tiles qui doit apparaître...

[Stef]

Et surtout maintenant par défaut SGDK règle la taille des tilemaps à 64x32 par défaut (soit 512x256 pixels) pour ne pas consommer trop de VRAM. Tu peux le changer mais il te faudra reconfigurer l'arrangement de la VRAM dans ce cas. Sinon en gros tu dois mettre à jour la tilemap au fur et à mesure que tu te deplaces dans la carte (tu peux voir ça comme un rouleau), la fonction VDP_setMapEx(..) est pratique pour mettre à jour des sous parties de tilemap :)

[troudki]

Hello Stef
est ce qu'il y a une roadmap du SGDK pour 2018 ? un poll avec des suggestions de prochaines features ?
as tu prévu d'être soutenu par une campagne type "patreon" ?
on soutient déjà quelques artistes et créateurs via ce mécanisme. Ce qui marque notre soutient à leur créativité, effort dans le temps et la continuité.
D'ailleurs j'ai pris le jeux de Henk Nieborg qui va sortir sur megadrive.
A+

[Invité]

Le meilleur moyen de soutenir Stef et ses efforts pour améliorer son Sgdk, c'est de lui faire un don sur sa page Github Via Paypal.
https://stephane-d.github.io/SGDK/

Noël arrive, alors c'est le moment de lui faire un petit don pour l'encourager et saluer ses efforts, son écoute et la qualité de son travail.