Re: Sgdk - Sega Megadrive / Genesis Development Kit

[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.

[Invité]

@Tryphon justement non d'où ma question. D'après le résultat à l'écran, je me suis dis qu'il y a forcément une limite, mais je voulais en être sûr.

@Stef c'est un peu l'idée que j'avais. Je pensais qu'on pouvait scroller une grande image, mais vu que ce n'est pas possible, va falloir s'adapter :)

Merci pour vos réponses :)

[Stef]

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+

Il n'y a pas vraiment de roadmap, il y a bien sur la possibilité de mettre des requests via les "issues" dans le repository github (je crois qu'on peut voter pour prioriser une issue en particulier). En tout cas pour moi il y a encore *beaucoup* de choses à faire et bien peu de temps libre à y consacrer :-/
En fait je fais ça avant tout pour mon plaisir même si je dois admettre que j'adorerai pouvoir en vivre (gagner ma vie en développant des jeux MD, le kiffe ^^).
Du coup je ne demande pas d'argent pour SGDK mais comme Vetea l'a dit j'ai quand même un compte paypal pour pouvoir faire un don si la personne en a vraiment envie, et ça fait toujours plaisir de se sentir supporter ^^ (merci encore Vetea ).
En fait j'y pense de plus en plus et peut être un jour j'oserai me lancer pour vraiment faire ça en full time en me mettant en free lance  =)

[upsilandre]

@Stef c'est un peu l'idée que j'avais. Je pensais qu'on pouvait scroller une grande image, mais vu que ce n'est pas possible, va falloir s'adapter :)

Estime toi heureux, sur une Master system tu fait ton scroll dans une image 256x224

[Invité]

Je t'en pris Stef, c'est tout à fait normal !
Tu es déjà embauché dans le Studio Vétéa en fait, mais tu ne le sais pas encore !

Après pour ces histoires de scrolling sur des MAP XL, faut faire du Tilemapping. Dans SgdK, tu as tous les moyens de t'en sortir pour ça.
Sur SMS, je ne sais pas .. Un jour peut être !

[Invité]

Hum je suis dans la doc de SGDK et j'ai pas trop compris un truc :

Code:

void SPR_clear    ( )    

Test if specified sprites are in collision.

Parameters:
    sprite1   first sprite.
    sprite2   second sprite.

Returns:
    TRUE if sprite1 and sprite2 are in collision, FALSE otherwise.

Bon d'accord, la fonction semble servir à tester une collision entre deux sprites, super pratique, mais j'ai l'impression que la fonction sert à autre chose, car en pratique elle ne prend aucun paramètre et dans le source rien ne concerne une collision.

[Tryphon]

Si tu lis les fichiers .h de SGDK, la fonction de situe APRÈS sa documentation.

De ce que je lis, ta documentation se rapporte à la fonction : SPR_testCollision, qui semble avoir été retirée.

[Invité]

Je lis la documentation via le doxygene et chaque fonction est dans un cadre.

http://www.retropc.net/mm/md/doc/html/sprite__eng_8h.html#aaeca42253b3a02a23402d895c0faff6e

[Tryphon]

Je la lis directement dans le fichier .h sur le github et je pense que la Doc Doxygen est fausse (le générateur a mal interprété les commentaires).

Par contre je n'ai pas vu de fonction de test de collision ailleurs. Cela dit c'est facile à coder...

[Invité]

Effectivement la fonction a été commenté. Bon va falloir écrire sa propre fonction.

[Monos]

Bonjour,
Voila j'ai une petite demande de conseille et d'aide. Je découvre un peu le SDK, et c'est pas mal. Bravos au créateur. Mais j'ai une petite question à poser. Je n'ai peut être pas tombé sur la fonction mais je pose la question !
Je suis ne mode 256*224 pour avoir 16 tuiles de 14 de visible à l'écran. (Tuiles de 16 pixounet)

J'ai configuré avec le stscrollingmode, le scroling au pixel près avec V/H.. Scorll_Plane

J'arrive à scroller le plan avec le setVerticalScrool (ou Horizontale) ça il n'y pas de problème. Je connais l'idée général pour poser les prochaine tiles dans la zone invisble. A droite et en bas ça marche bien avec mais en Haut et à Gauche, avant d’effectuer le scroling*16 (Pour effectuer un décalage fluide ) ça marche pas. Les valeur négative sont refusés dans le postage de tiles. (Contrairement à Second Basic pour poser un tiles à -1,0 le fait poser à une case à Gauche a portir de l'origine. Il faut appliquer après des modificateur offets.
Qu'elle est la méthode à employer ? Es que j'ai loupé une fonction ? Qu'elle est la couleur du cheval Blanc d'henry 4 ?

Bisous.

[uran]

Mets voir ton code où tu déclares et initialises les variables de scrolling et là où tu  les utilises pour voir.

Edit : j'avais mal lu

[Tryphon]

Si ton plan fait 512 pixels (ça devrait être le cas), il te suffit de faire un et logique sur les derniers bits ( x &= 511; ) avant de le balancer à ta fonction.

Mais ça m'étonnerait que SGDK ne le fasse pas, donc comme Uran je pense que tu devrais poster ton code (nettoyé si possible).

[Monos]

Voila ou j'en suis.

Code:

void draw_map_start()
{
    // *************************************
    // * Déclaration des variables locales *
    // *************************************

    u8 tiles_X=0;
    u8 tiles_Y=0;

    // ********************************
    // * Affichage de la carte du jeu *
    // ********************************

    for(tiles_Y=0;tiles_Y<14;tiles_Y++)
    {
        for(tiles_X=0;tiles_X<16;tiles_X++)
        {
            VDP_fillTileMapRectInc(PLAN_A,1,tiles_X*2-2,tiles_Y*2,2,2);
        }

    }
VDP_setHorizontalScroll(PLAN_A, 16);

}

Ma petite fonction test de draw map.
Je suis en mode 256*224
j'ai configuré mon set plan en VDP_setPlanSize (64,32);
et
VDP_setScrollingMode(HSCROLL_PLANE, VSCROLL_PLANE);

[Tryphon]

Si tu fais :

Code:

VDP_fillTileMapRectInc(PLAN_A, 1, (tiles_X*2 - 2) & 63, tiles_Y*2, 2, 2);

ça passe mieux ?

Par contre rassure-moi : tu ne fais pas ça à chaque frame du jeu ?

[Monos]

Cela semble fonctionner <3.
Pourquoi &63 ? Tu peux m'expliquer stp ?
Je dois placer quoi pour le Y ?

Par contre rassure-moi : tu ne fais pas ça à chaque frame du jeu ?

Non.  Je prévois de faire le scrolling quand le joueur va se déplacer et que la "prochaine" case n'est pas une case qui bloque. Pour un RPG. Enfin je test !

Merci à toi.

Edit : Bon voila ce petit soucie semble être résolut. &31 en Y. C'est en nombre de tiles.
Merci à toi pour l'astuce.

[Stef]

Effectivement on donne la position en nombre de tiles et on doit faire soi même le & logique en fonction de la taille du plan (qui est variable), SGDK ne le fait pas pour toi (et je ne suis pas sûr que ça soit une très bonne idée qui le fasse) ^^

[Invité]

@Stef pendant que tu y es là, pourrais-tu, s'il te plaît, indiquer si dans SGDK il y a un moyen de définir une hit box pour chaque sprite et récupérer sa position afin de déterminer une collision ? Dans le fichier sprite.res j'ai vu qu'on pouvait définir la hit box donc il est possible de récupérer des infos à son sujet ? Je n'ai pas compris à quoi servait la structure collision dans AnimationFrame.

Merci

[Stef]

En réalité cette partie n'est pas encore vraiment implémentée. Actuellement tu peux juste définir le type de collision à CIRCLE ou BOX et ça va te définir (de mémoire) une structure CIRCLE ou BOX qui faire environ 75% de la taille du sprite. Mais il n'y a pas de fonction qui gère ensuite ces structures pour calculer les collisions, en réalité il faudrait un outil te permettant de définir te manière plus flexible les collisions...
En attendant je te conseille d'implémenter les collisions de ton côté avec tes propres structures

[Tryphon]

Cela semble fonctionner <3.
Pourquoi &63 ? Tu peux m'expliquer stp ?
Je dois placer quoi pour le Y ?

& 63 c'est un "et logique", ça ne garde que les 6 derniers bits de ton nombre. Ça fait office de modulo :
0 & 63 = 0
1 & 63 = 1
...
63 & 63 = 63
64 & 63 = 0
65 & 63 = 1
...
127 & 63 = 63
128 & 63 = 0
129 & 63 = 1
...

Ça ramène ton nombre entre 0 et 63.

Tu peux remplacer 63 par n'importe quelle puissance de 2 - 1 (1, 3, 7, 15, 31, 63, 127, 255...).

Par contre si tu veux te balader entre 0 et 19 (par exemple), il faut utiliser l'opérateur "modulo" : x % 20, qui est suuuuuuuper lent (donc à éviter).

Par contre rassure-moi : tu ne fais pas ça à chaque frame du jeu ?

Non.  Je prévois de faire le scrolling quand le joueur va se déplacer et que la "prochaine" case n'est pas une case qui bloque.

Même pour ça, faut pas faire ce que tu fais : tu ne dois tracer que les tiles qui ne sont pas à l'écran (donc une colonne de tiles pour un déplacement horizontal, ou une ligne de tiles pour un déplacement vertical), sinon c'est lent !

En fait, ce que tu fais (tracer tout l'écran de jeu), c'est uniquement lors de la première apparition.

Effectivement on donne la position en nombre de tiles et on doit faire soi même le & logique en fonction de la taille du plan (qui est variable), SGDK ne le fait pas pour toi (et je ne suis pas sûr que ça soit une très bonne idée qui le fasse) ^^

Question innocente (promis) : pourquoi ?

Sinon, tu envisages d'implémenter un "map_engine" (comme le sprite_engine) pour faciliter la gestion et le scrolling de grandes cartes ? (ou c'est peut-être déjà fait ? J'avoue que je suis resté à un très vieux SGDK).

[Monos]

Même pour ça, faut pas faire ce que tu fais : tu ne dois tracer que les tiles qui ne sont pas à l'écran (donc une colonne de tiles pour un déplacement horizontal, ou une ligne de tiles pour un déplacement vertical), sinon c'est lent !

En fait, ce que tu fais (tracer tout l'écran de jeu), c'est uniquement lors de la première apparition.

Heu oui j'ai pas du comprendre le sens de ta question car oui ça me parait logique.

Mon workflow pour un déplacement vers le haut :
-Testé si la case "nord" du perso est pas bloquante. si je peux bouger :
-Afficher les tiles à (-2) sur la ligne
-Déplacer le plane de x pixel vers le bas.
A vrais dire activer un compteur de boucle pour faire un truc du genre 16*1px ou 8*2px pixel mais pas de boucle directe dans la fonction pour le déplacement ce qui peut bloquer d'autre truc je pense. J'ai un peu l'habite de faire des déplacement "case par case" mais en déplacement le sprite ou "bob en basic amos" la c'est le plane que je dois déplacer pour ce que je veux faire. En tous cas merci tu m'as débloqué.

[Stef]

Effectivement on donne la position en nombre de tiles et on doit faire soi même le & logique en fonction de la taille du plan (qui est variable), SGDK ne le fait pas pour toi (et je ne suis pas sûr que ça soit une très bonne idée qui le fasse) ^^

Question innocente (promis) : pourquoi ?

En fait à la base je pensais à ça surtout pour des raisons de performance et je me disais que pour certaines raisons tu peux avoir envie de modifier la map en dehors de la map "hard" (surtout en vertical) mais tout bien réfléchi je pense que c'est effectivement pas très pertinent
Pour les performances c'est toujours un soucis par contre car si SGDK prend en compte le "rolling" sur la taille de map, ça signifie qui doit théoriquement le faire aussi pour chaque colonne / ligne écrite dans le tilemap ce qui serait dommageable pour les performances, par contre je peux le faire sur la position X/Y de départ sans soucis

Sinon, tu envisages d'implémenter un "map_engine" (comme le sprite_engine) pour faciliter la gestion et le scrolling de grandes cartes ? (ou c'est peut-être déjà fait ? J'avoue que je suis resté à un très vieux SGDK).

Ce n'est pas encore fait, et oui c'est un de mes projets :)

[Monos]

Voila j'ai testé le scrooling 4 directions, ça fonctionne bien.
Lien
Mon code source plus le mister bin.

Je dois maintenant mieux refaire ça bien sur mais le premier point est la. ça fais plaisir. (J'ai pas beaucoup XP en C en passant)
Merci.

[Invité]

Il existe une manière simple d'afficher un sprite et de l'animer une seule fois avant de le virer de l'écran ?

Comme je n'ai pas trouver de solutions, j'ai fais une fonction pour mettre à jour chaque frame avec un timer et une fois la dernière frame affichée, je fais dégager le sprite.

Est-il possible de connaître la quantité de mémoire et de ressources processeur utilisées ?

[Stef]

Non il n'y a pas de méthode pour ça, du coup je te conseille de gérer l'animation "manuellement" comme tu le fais

Pour la quantité de mémoire oui, tu peux connaitre la mémoire RAM dispo avec MEM_getFree().
Pour les ressources processeur, c'est à toi de mesurer le temps d'execution de tes fonctions. Il y a plusieurs manières de faire, soit tu changes la couleur de fond avant d'appeler à la fonction à "mesurer" et tu remet la couleur de fond à sa valeur initiale à la fin ainsi la couleur du bord (non visible dans la plupart des émulateurs) va changer sur un certain nombre de scanline, plus la bande est large et plus la fonction prend de temps. Une autre manière est d'utiliser les fonctions timer et d'afficher le temps pris par la fonction avec du KLog(..)

[Invité]

Yeah merci Stef, je vais tester ça midi :) Optimisation me voilà !

[Invité]

Je le signal au cas où, en utilisant la fonction MEM_getFree() j'obtiens une valeur négative. J'ai utilisé la fonction en tout début du code et j'ai eu encore une valeur négative. Est-ce normal ?

[Stef]

Heu non ça n'est pas normal
A tout hasard aurais tu alloué beaucoup de tableau ?

[Invité]

Faut voir ce que tu appelles beaucoup ^^

Je n'ai pas le code sous les yeux, mais il me semble que c'est pas énorme.

Je vérifie ça après le sport et je te tiens au courant :)

[Invité]

J'ai vérifié mes déclarations et j'ai seulement trois tableaux dont l'un fait 10,1 et 6 en taille.

Dans le doute je suis parti voir l'exemple sprite et idem la valeur retourné est négative :

Code:

*******************rom
Message : MEM_init: heap = 16714266
Message : Free memory:-5662
Message : SYS_disableInts() info: inner call
Message : SYS_enableInts() info: inner call
Message : SYS_disableInts() info: inner call
Message : SYS_enableInts() info: inner call
Message : SYS_disableInts() info: inner call
Message : SYS_enableInts() info: inner call
Message : SYS_disableInts() info: inner call
Message : SYS_enableInts() info: inner call


J'ai tenté de le faire autrement :

Code:

KDebug_Alert("Free memory:");
KDebug_AlertNumber(MEM_getFree());

Cela me retourne ceci :

Code:

Message : Free memory:
Message : 0000E594
Message : Player is initialized


[Tryphon]

Ça m'a l'air normal. C'est juste que la routine d'affichage des nombres décimaux considère que l'entier est signé.