Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Tryphon]

Il est déjà important que tu saches précisément ce que tu veux :

* est-ce que tu veux que sprite aille jusqu'à target à vitesse constante ?

* est-ce que tu veux qu'il y aille en un nombre d'étapes prédéterminé ? (auquel cas sa vitesse sera d'autant plus grande que les deux sont éloignés)

* si target bouge pendant que sprite se déplace vers lui, est-ce que sprite doit ajuster sa direction ?

Ensuite faut traduire tout ça sur les coordonnées. C'est pas des maths bien compliquées.

[Invité]

Déjà si j'arriverais simplement à diriger un sprite vers la dernière position du joueur, se serait déjà pas mal, ça me permettrait de comprendre comment ça marche.

Autre question, je suis en train de faire un spritesheet de Maki (FF2) ce qui me donne une taille de 64x96 pixels pour chaque frame. La plupart des frames n'utilise pas tout cet espace et du coup, quand je fais un flip, il y a un décalage. La seule solution que j'ai trouvé et d'ajouter une ligne de frame supplémentaire. Est-ce comme ça qu'il faut faire ?!

[Hpman]

Faut centrer tes frames dans l'espace alloué ou garder trace de l'emplacement exact de la frame pour positionner selon l'orientation dans le programme.

[Invité]

Ah merci, je voyais pas les choses sous cet angle :)

[Tryphon]

Déjà si j'arriverais simplement à diriger un sprite vers la dernière position du joueur, se serait déjà pas mal, ça me permettrait de comprendre comment ça marche.

Je t'ai dit : c'est trop vague.

Quand tu veux déplacer un objet vers un point, en général, tu ajoutes à ses coordonnées x, y un déplacement dx, dy :

Code:

x += dx;
y += dy;

La question, c'est : comment calculer dx et dy ?

La première idée c'est de prendre dx = dest_x - x (et pareil pour dy) où dest_x et dest_y sont les coordonnées de la destination.

Le problème, c'est que ça t'envoie ton sprite sur la destination en 1 seule étape ! Ça va pas !

Si tu veux que le mouvement se fasse en N frames, tu divises :

dx = (dest_x - x)/N

Problème : une division est lente sur Megadrive. Solution : diviser par une puissance de 2, par exemple :

dx = (dest_x - x)/16

En effet, ce code est transformé par le compilateur en dx = (dest_x - x) >> 4, qui est équivalent et rapide.

Mais tu peux aussi vouloir que le mouvement se fasse à vitesse constante, par exemple 4 pixels par frames quelle que soit la direction. Là c'est le drame. En effet, la formule pour dx devient :

dx = (dest_x - x)/longueur * 4

où longueur est la distance entre l'objet et la destination. Et ça se calcule avec le bon vieux théorème de Pythagore :

longueur = sqrt( (dest_x - x)^2 + (dest_y - y)^2 )

Et bien sûr, la racine carrée est super-lente, et la division par la racine aussi. Si tu veux vraiment faire ça, doit y avoir moyen, mais dans ce cas dis-le parce qu'il faut réfléchir

Autre question, je suis en train de faire un spritesheet de Maki (FF2) ce qui me donne une taille de 64x96 pixels pour chaque frame. La plupart des frames n'utilise pas tout cet espace et du coup, quand je fais un flip, il y a un décalage. La seule solution que j'ai trouvé et d'ajouter une ligne de frame supplémentaire. Est-ce comme ça qu'il faut faire ?!

En général, quand tu définis un objet à l'écran, tu gardes en mémoire la position (x, y) de cet objet par rapport à un point particulier de cet objet (à une époque on appelait ça un hotspot, je sais pas si c'est toujours d'actualité).

Par exemple, pour un personnage, tu vas choisir un point situé au milieu de ses pieds ; tu peux aussi choisir au milieu horizontalement et verticalement, surtout si ton objet peut être flippé haut/bas.

Ensuite tu calcules la position des sprites qui composent l'objet par rapport à ce hotspot.

[Invité]

Merci @Tryphon je vais voir tout ça tranquillement en me replongeant dans mon code source :) Faudrait que j'avance un peu dans mon shmup mine de rien.

[Invité]

Excellent concernant l'offset d'un sprite, c'était assez logique !

Du coup, j'ai ajouté un offset de 32 pixels que j'utilise lorsque j'ai fais un flip horizontal. Ce qui me permet de voir marcher la belle, sublime et pulpeuse Maki marcher dans les deux sens

[Hpman]

Question GCC, j'arrive pas à compiler avec les infos de debug ( -g ), c'est pas dispo sur 68000, faut un gcc compilé avec la feature, j'utilise gdb comme un pied ou alors D, la réponse D ?

[Stef]

Qu'est ce que tu veux dire ? Il te chie une erreur quand tu essais ? Moi j'ai pas de soucis avec les symboles de debug par contre j'utilise ce flag -ggdb comme ça tu es sûr d'avoir les symboles dans le bon format

Sinon perso j'ai jamais réussi à utiliser GDB non plus Il est censé être supporté par BlastEm, Gens KMod ou Exodus mais je n'ai jamais réussi à le faire fonctionner correctement avec aucun ému (Gens KMod en est le plus proche mais il a un bug sur la gestion des lectures mémoires qui fait partir GDB en cacahouette).

[Hpman]

Non pas d'erreur à proprement parlé mais les infos de debug sont absentes:

Code:

(gdb) list *0x100
No source file for address 0x100.

[Stef]

J'ai modifié mon message, essai avec -ggdb

[Hpman]

Nope, c'est idem avec -ggdb

[Stef]

Bizarre, c'est pas un soucis avec le chemin de recherche des fichiers sources ? enfin bon il n'y pas de raison... j'imagine que tu as déjà googolisé un peu sur le sujet. Mais sinon, tu voulais utiliser GDB avec quoi ??

[Hpman]

Non quand c'est un problème de fichier non trouvé il le dit:

Code:

(gdb) list
1       ./config/m68k/lb1sf68.asm: No such file or directory.

Avec et sans -ggdb, le fichier de sortie fait la même taille, donc y'a bien une couille dans le potage.


J'ai pas de plan précis en vue, justement je voulais voir si c'était fonctionnel avant tout.

[Invité]

Bonsoir les lapins,

je suis en train de recoder depuis le début mon shmup histoire de tout remettre en ordre et de me remettre dans le bain.

J'aurais une question concernant le changement de couleur de texte dans le menu principal. Actuellement j'alterne l'affichage avec deux palettes. C'est à dire la palette 1 affiche les textes en blanc et la palette 2 en gris.

J'utilise la fonction VDP_setTextPalette() :

Code:

u16 a;
    for(a = 0; a < MAIN_MENU_MAX_TEXT; a++) {

        if(mainMenu.text[a].active)
            VDP_setTextPalette(PAL0);
        else VDP_setTextPalette(PAL1);

        VDP_drawText(mainMenu.text[a].content, mainMenu.text[a].posx, mainMenu.text[a].posy);
    }

Je voudrais donc savoir si c'est une bonne pratique ou s'il existe une autre méthode pour changer plus facilement la couleur d'un texte. Je trouve dommage de ne pas simplement sélectionner une couleur dans une palette déjà chargée.

Dans le code vous verrez que je n'utilise pas de pointeur. J'ai tenté de le faire, mais ça fait ralentir le programme comme pas possible, chose que j'avoue ne pas comprendre.

Merci

[Tryphon]

Non, c'est pas possible. Tes caractères sont des tiles, elles sont dessinées avec des index de couleur. Tu peux changer la palette, mais si tu veux changer l'index il faut redessiner les tiles avec d'autres index.

[Invité]

Au moins c'est clair ^^

Merci @Tryphon

[Invité]

Autre petite question concernant :

Code:

VDP_fadeIn(0, (4 * 16) - 1, palette, 20, FALSE);

Pourquoi suis-je obligé de faire appel à lui pour afficher les sprites avec la bonne palette ?!

[Tryphon]

Euh non t'es pas du tout obligé. Ça sert à faire un effet de fondu. Mais sinon tu utilises VDP_loadPalette

[Invité]

Ah merci @Tryphon car je me disais bizarre quand même. Comme je recode entièrement le shmup, j'essaie un peu de mieux comprendre certaines fonctions. Donc lorsqu'on charge en mémoire de nouvelles palettes, c'est pas automatique, il faut demander au VDP de les charger.

Tu coup j'ai compris :

Code:

VDP_setPaletteColors(0, (u16*) spr_player.palette->data, 64);

Est-ce que j'ai toujours d'utiliser cette fonction ?

Code:

memcpy(&palette[0], spr_player.palette->data, 16 * 2);

Il semble que non, car ça marche très bien comme ça :)

Va vraiment falloir que je tiens un carnet de notes.

Je suis content, j'ai fini l'écran titre et j'ai fais les déplacement du vaisseau :) Pour les déplacements j'utilise tout en FIX32 histoire de varier un peu la vitesse de déplacement ^^

Je trouve le contrôle nickel sur GenesisPlus.

[Stef]

Non quand c'est un problème de fichier non trouvé il le dit:

Code:

(gdb) list
1       ./config/m68k/lb1sf68.asm: No such file or directory.

Avec et sans -ggdb, le fichier de sortie fait la même taille, donc y'a bien une couille dans le potage.


J'ai pas de plan précis en vue, justement je voulais voir si c'était fonctionnel avant tout.

Je n'avais pas vu ta réponse... si ça fait la même taille alors oui il y a un soucis ^^
Je dois admettre ne pas avoir regardé depuis quelque temps car de toute façon je n'arrivais pas à utiliser GDB :-/

[Stef]

Donc lorsqu'on charge en mémoire de nouvelles palettes, c'est pas automatique, il faut demander au VDP de les charger.

Heu... Que veux tu dire ? dans certaines fonctions le chargement des palettes est optionnelle... et oui il faut charger les palettes dans le VDP pour charger les palettes ^^
Si tu parles des sprites, alors oui il faut explicitement charger sa palette dans le VDP. C'est normal car tu as souvent de sprites que de palettes et donc certains sprites partagent la même palette


Par contre si tu utilises ça :

Code:

VDP_setPaletteColors(0, (u16*) spr_player.palette->data, 64);

Tu demande de charger les données de la palette du spr_player, mais tu charges 64 couleurs (soit l'intégralité des 4 palettes de la MD) or le sprite en a que 16 (normalement) donc déjà là tu as un gros soucis.

Ensuite cette fonction est un simple memcpy, tu copies les données de la palette de ton sprite vers le tableau palette.

Code:

memcpy(&palette[0], spr_player.palette->data, 16 * 2);

Si tu n'utilises pas palette derrière alors ça sert à rien en effet :p

[Invité]

Oui @Stef j'avais pas vu la doc et je pensais  que le 0 correspondait au numéro de la palette. Je m'en suis rendu compte hier quand j'ai tenté d'utiliser les bullets.

Donc c'est bien de 0 à 16 puis de 16 à 32 etc.

[Tryphon]

Yep!

[ichigobankai]

nope.
0 - 15, 16 - 31, etc. pour les intervalles.

[Tryphon]

Je compte en Python : 0 inclus, 16 exclus

[ichigobankai]

lol, on me l'avait jamais faite celle là

[TotOOntHeMooN]

[Invité]

Bonjour les amis,

j'ai rapidement élaboré une petite carte de la caverne pour mon shmup. Ce soir, je vais la tester et j'aurais aimé mettre en place les collisions.

Je suppose que les collisions entre le joueur et le plan demande peu de ressource machine. En revanche, je ne vois pas trop comment mettre ça en place.

Est-ce que je dois faire un tableau indiquant toutes les valeurs X/Y ou est-ce que la Mega Drive est capable de comprendre que si le joueur touche une tile du plan a ou b, il y a collision ?!

Merci les lapins :)

[Tryphon]

Non, tu dois tout gérer toi-même.

Tu peux faire une carte de collisions, ou alors faire une liste disant, pour chaque tile, si elle est collisionnable ou non.

La deuxième méthode est moins souple, mais moins gourmande en mémoire.

[Invité]

Tiled peut me faire une liste des coordonnées de chaque tiles ? De cette façon se sera plus simple ?