Re: WIP Jeu de plateforme MD

[Invité]

Ah c'est ce truc là Kaot  ?!
Même pas remarqué !

Moi ça ne me gène pas du tout.
Après, ça n'a rien à voir avec SPR_update() effectivement, mais les dernières mises à jour du SgdK de Stef avec la gestion Yorder.
Faire une compilation avec une version antécédente, la 1.2 par exemple et voir ce que cela donne.
Si c'est OK, faire un report à STEF et attendre !

[Tryphon]

Oui, c'est un bug qui n'influe pas sur le gameplay et qui est visuellement quasi-imperceptible. Mais connaissant le souci de perfectionnisme de Stef, je suis sûr qu'il jettera un œil au problème

[Invité]

Certainement Tryphon !
Faut juste faire un test de compilation avec la 1.2 et constatez si tout est OK !
Avec mon Wifi des Alpes, c'est pas la peine d'y compter ! 

[philip]

Voilà, c'est son positionnement du SPR_update()

Je pense pas, ça le fait sur le sample sprite de Stef et le update() est bien placé.

(mais l'OP a posté son code quelque part ? Je le vois pas...)

Non, il ne l'a pas posté. J'ai regardé la vidéo posté par kaot, et effectivement, les soldats à terre subissent un décalage lors du défilement vertical du décors... La démo sprite de sgdk, je ne vois pas ce phénomène mais j'ai les yeux qui fatigue. J'ai testé sur émulateur le jeu de PF de Kivutar, et les sprites ennemis jouent effectivement du moonwalk, surtout quand on fait du va et vient, cela saute aux yeux. 

Je n'ai jamais rencontré ce problème. Pour en avoir le coeur net, j'ai retrouvé le vieux sgdk 0.90 avec lequel j'ai fait un concept de toki, j'ai désactivé les déplacements des ennemis du jeu, et en faisant des va et vient tout reste bien impeccable... Donc pour moi, le problème ne vient pas de sgdk, du moins jusqu'à la version 1.21

[Tryphon]

Si, ça le fait sur le sprite sample, mais c'est beaucoup moins marqué. Du coup il est possible qu'il y ait autre chose en plus de ce problème. Mais y'a clairement quelque chose de bizarre...

[Stef]

Je regarderai tout ça au retour de mes vacances car c'est louche.
Je pense que le SPR_update() se termine trop tard parfois (après le vblank) d'où le soucis de décalage.

Théoriquement il faut faire dans ce sens pour éviter tout problème de synchro entre sprites et plan :

// met à jour la map sans modifier le scroll hard en lui meme
MAP_update();
SPR_update();

VDP_waitVSync();

// met à jour le scroll hardware
Scroll_update();

A note que le scroll hardware peut être mis à jour dans la routine du vint s'il y en a une mais il faut etre sur que le SPR_update sot termine à ce moment là (avec un flag ou autre).
Je corrigerai l'exemple "sprite" si besoin :)

[ichigobankai]

J'avais failli posté dans ce sens, à savoir si vous (ceux qui dev sur MD) regardiez la charge par frame. Car si ca dégueule, forcément on perd la synchro etc.

[Tryphon]

Si le SPR_update bloque les interruptions (je suppose que c'est le cas ?) alors ça se verrait avec gens (le r57shell-mod montre les VInt ratées), mais ce n'est pas le cas...

[Invité]

Bref ...
Merci Stef, vais tester dès que j'ai le PC en main.

[Kivutar]

Voilà une vidéo qui montre bien le bug, sans avoir besoin de passer au ralenti:

Théoriquement il faut faire dans ce sens pour éviter tout problème de synchro entre sprites et plan :

// met à jour la map sans modifier le scroll hard en lui meme
MAP_update();
SPR_update();

VDP_waitVSync();

// met à jour le scroll hardware
Scroll_update();

Alors j'ai essayé ça. Et ça règle effectivement le souci.
Encore merci pour votre aide précieuse les gars !

J'aurais jamais trouvé ça tout seul

[Invité]

good job

[Tryphon]

// met à jour la map sans modifier le scroll hard en lui meme
MAP_update();
SPR_update();

VDP_waitVSync();

// met à jour le scroll hardware
Scroll_update();

Je crains d'avoir mal compris un truc alors : le scroll hw est en général calculé d'après les coordonnées du sprite du joueur.

Au moment du waitVsync(), on va avoir les sprites avec les coordonnées de la frame n, mais les offsets du scroll hw de la frame n - 1 (puisque le Scroll_update() est situé après)

Edit : ce n'est d'ailleurs pas ce que tu fais dans le sonic sprite sample :

Code:

while(TRUE)
    {
        handleInput();

        updatePhysic();
        updateAnim();

        // update sprites
        SPR_update();

        VDP_waitVSync();
    }


le updateCamera() (équivalent du Scroll_update() ?) est lancé par updatePhysic(), donc au moment du waitVSync() on a bien des offsets synchro avec la position du sprite du joueur (ce qui n'empêche pas le bug décrit par l'OP, visible uniquement en ralenti extrême).

[Kivutar]

Si ça peut t'aider, voilà ma runloop après modifications:

Code:

    while(1)
    {
        joy1 = JOY_readJoypad(JOY_1);

        if (pause)
            pause--;
        else
        {
            camera_update(player, ind);

            // Update entities
            Entity *e = entityList;
            while(e) {
                if (e->update != NULL)
                    e->update(e);
                e = e->next;
            }

            // Update items
            Entity *i = itemList;
            while(i) {
                if (i->update != NULL)
                    i->update(i);
                i = i->next;
            }

            detect_collisions();

            SPR_update(sprites);
        }

        VDP_waitVSync();

        VDP_setHorizontalScroll(PLAN_A, camera_x);
        VDP_setHorizontalScroll(PLAN_B, camera_x >> 3);
        VDP_setVerticalScroll(PLAN_A, -camera_y);
        VDP_setVerticalScroll(PLAN_B, shake_y_offset >> 3);
    }

Avant le changement, je faisais mon camera_update juste avant le waitVSync et ce camera_update contenait mes appels à VDP_setScroll.

J'ai donc dû couper mon camera_update en deux. La partie mise à jour de la map se fait avant la mise à jour des personnages. Ce qui lui donne une frame de retart. La mise à jour du scroll se fait juste après le VSync.

Le sample de sonic devrait être corrigé pour éviter ce bug.

visible uniquement en ralenti extrême

Ca dépend de la vitesse de déplacement du personnage lors de la première frame du déplacement je pense. Si ton personnage accélère très vite, comme lors d'un saut, ça deviens très visible. Jette un coup d'oeil à ma vidéo.

[Stef]

@Tryphon>En fait oui la position de la caméra doit se faire en fonction de la position du joueur mais comme juste au dessus il faut découper le traitement en 2 (la partie soft ou tu mets à jour le tilemap et la partie hard où tu modifies le scrolling).

En gros :
// mise à jour des objets et de la position du perso principal
physicUpdate();
// mise à jour de la map en fonction de la nouvelle position du perso
// attention à ce niveau le scroll hard est inchangé (seule le tilemap est modifié, et encore, de préférence en ram interne)
mapUpdate();

// mise à jour des sprites, la liste sera balancée au hard au prochain vblank
SPR_update();

// attente vblank
VDP_waitVSync();

// mise à jour du scroll (hardware)
scrollUpdate();

Et normalement ainsi c'est ok car le scroll et les sprites seront mise à jour dans le même vblank :)
Par simplification je ne l'ai pas fait dans mon exemple "sprite" mais je le modifierai car sinon tu peux avoir des soucis de synchro

[Kivutar]

Dans cet ordre là, ça ne fonctionne pas pour moi.

Il faut vraiment que je fasse le mapUpdate avant de mettre à jour la position des personnages.

Ca semble vraiment pas logique.

Mais le résultat ne trompe pas.

Au fait, j'ai mis à jour la rom, la map est un peu plus grande, avec des plateformes mouvantes et des leviers.

[Stef]

Possible que ton mapUpdate prenne trop de temps et laisse passer une frame de temps en temps, du coup tes sprites seront desync si tu appelles SPR_update avant...

[Kivutar]

Ah OK je comprend mieux.

C'est quo la façon la plus propre d'afficher du texte avec des sprites ? Je dois me servir des fonts ou je fais juste un sprite avec une lettre par animation ?

EDIT: Pour l'instant je fais avec des sprites.

Ca donne ça:

[Stef]

SGDK n'a pas vraiment d'aide pour écrire du texte avec les sprites. Tu dois le faire "à la main", par contre tu peux utiliser la font interne histoire de ne pas encombrer la VRAM avec plusieurs font (tu peux remplacer la font interne avec la tienne si celle par défaut ne convient pas).
Si tu regardes le code de SGDK pour l'affichage du texte tu verras cette boucle :
*d++ = TILE_FONTINDEX + (*s++ - 32);

le "TILE_FONTINDEX + (*s - 32)" permet de transformer un caractère (*s ici) par l'index du tile correspondant en VRAM.
donc en gros tu dois positionner tes sprites de 8x8 les uns derriere les autres en les faisant pointer sur le bon tile pour construire des mots.

[Kivutar]

OK merci, bon à savoir. Ca a l'air abordable. Si je sature ma VRAM, je passerai à cette méthode.

[Hpman]

Certains jeux gèrent ça "à l'envers", avec un sprite fixe et une mise à jour des tiles en vram quand le compteur change.

Sur un jeu avec peu de texte ça évite de charger une font complète.

[Tryphon]

+1 Hpman

De toute façon, s'il y a beaucoup de texte, tu passes pas par les sprites.

[Invité]

Certains jeux gèrent ça "à l'envers", avec un sprite fixe et une mise à jour des tiles en vram quand le compteur change.

Sur un jeu avec peu de texte ça évite de charger une font complète.

Et ça permet aussi de pas sacrifier une partie d'un plan pour faire un hud .

[Kivutar]

Le point de sauvegarde:

[Tryphon]

Toujours aussi mignon :)

[Kivutar]

Merci !

Il y a une façon facile de gérer les sauvegardes dans SGDK?

[Tryphon]

Mmmh, aucune idée...

[fourchette]

Si tu parles de sauvegarde sur la cartouche, c'est très simple grâce à l'utilisation des fonctions commençant par SRAM_

Dans le principe,
- on active le mode lecture ou écriture
- suivant le mode, on lit ou écrit à la position voulue en mémoire un octet, mot ou entier long
- on désactive le mode d'accès

edit : penser à paramétrer le fichier rom_head.c

[Tryphon]

Bon à savoir, merci :)

[Kivutar]

J'ai avancé sur le jeu.

Je suis en train de refaire le costume du perso, ce sera une Miko.

Le point de sauvegarde aussi deviens plus élaboré avec une animation sympa où le perso bois du thé et croque un onigiri avec des sakura qui tombent du ciel (lol).

J'ai aussi ajouté plus de maps et de transitions entre les maps (vers le haut, vers le bas).

Par contre, ça segfault de temps en temps au changement de maps, et j'ai un souci avec ma camera qui arrive rarement, mais qui arrive quand même.

Je pense que j'ai besoin d'une bonne revue de code pour ce qui est de la gestion de la mémoire, et peut être aussi pour la camera et mes pentes. Y aurait il une bonne âme pour se faire un compte sur bitbucket et lire mon code SVP ?

[philip]

Je n'utilise pas sprite engine, et je ne suis pas le plus doué de l'hôpital, mais pour la pente, peut-être inclure dans un tableau les valeurs Y. Et en fonction de X de ton personnage joueur, appliquer la valeur Y préenregistrés dans le tableau. Puis avec un pointeur sur tableau pour optimiser. Faudra que j'essaie de relever ce défi un jour. Pour regarder la vram il y a plusieurs ému comme:
http://gendev.spritesmind.net/forum/viewtopic.php?f=7&t=2264

[Kivutar]

J'ai réussi à régler la plupart des bugs du jeu. J'ai quand même des crash de temps en temps au changement de map.

Mais du coup j'ai pu continuer à ajouter des trucs, et le perso a maintenant une ombrelle qui lui permet de planer ou de se protéger en position accroupie :