Re: Collision et Tilemap avec la SGDK

[Tryphon]

J'ai fait une boulette : faut sortir le

Code:

camera_move_left = FALSE;
camera_move_right = FALSE;

du if dans updateCamera() (et y'en a peut-être d'autres, mais t'as l'idée). T'as remarqué aussi que y'a pas du tout besoin du offset_y dont on parlait hier.

Pour les scrollings verticaux, n'oublie pas qu'il faudra tracer une ligne et une colonne plus loin.

Un truc que j'aime bien pour débugger : les KLog, KDebug_Halt, etc.

C'est des instructions spéciales pour l'émulateur gens_kmod, qui provoquent l'affichage de messages dans un terminal, ou qui pausent l'émulateur. C'est super pratique (enfin moi je sais débugger que comme ça, j'ai jamais appris à me servie d'un debugger, c'est mon côté manouche ) et c'est implémenté par défaut dans SGDK.

Par contre, faut penser à les désactiver pour les release parce que ça bouffe assez méchamment des performances ! Moi j'ai écrit un truc du genre :

Code:

#ifdef DEBUG
#define LOG(m) KDebug_Alert((m));
#else
#define LOG(m) {}
#endif


comme ça quand je compile sans debug, ça les désactive.

Un autre truc : gens (enfin gens_r57shell, mais peut-être d'autres) ont un compteur de "frames perdues" qui permettent de savoir quand t'as raté une VBlank (ce qui signifie que le corps de ta boucle principale est trop lent), c'est assez utile.

Ça vaut ce que ça vaut.

Autre chose : je me demande si c'est normal que le SPR_update (et même le VDP_setMapEx, même si y'a moins de risques) soient à l'extérieur du SYS_disableInts() - SysEnableInts() (parce qu'ils accèdent au VDP)

[Infitek]

Ah super pour le debug je t'avoue que je dessinais a l’écran mais je savais que c'était pas du tout la meilleure option je vais tester ça !

Sinon j'ai implémenté le scrolling vertical qui fonctionne, le soucis c'est lorsque la caméra bouge horizontalement et verticalement en même temps, la map s'affiche mal, je vais encore creuser un peu puis si je trouve pas je me contenterais d'un scrolling horizontal

[Tryphon]

Sinon uploade

[Infitek]

C'est déjà énorme toute l'aide que tu m'as donné, je voudrais pas en abuser, mais promis tu auras la rom en avant-première une fois le jeu terminé

https://drive.google.com/open?id=1lP753yOc4OqFg6T3zsmDHJQ6GD8DuKjH

[Stef]

Merci Tryphon pour le support SGDK, tu assures, plein de bons conseils en plus
Une petite note par rapport aux appels à SPR_update() et VDP_setMapEx() en dehors d'un bloc SYS_disableInts() / SYS_enableInts().
SPR_update() est une fonction  de "haut niveau", elle se protège elle-même de l'interruption (donc pas de problème), par contre VDP_setMapEx(..) est une fonction plus bas niveau (accès VDP direct) du coup c'est à toi de la protéger (ça serait un peu trop couteux de protéger automatiquement chaque appel aux méthodes VDP_xxx)

[Tryphon]

Merci chef !

J'en ai pas parlé pour pas compliquer, mais est-ce que VDP_setMapEx utilise le DMA (et donc s'exécute durant la VInt) ? Parce que sinon, il aura des problèmes de performance ?

[Infitek]

Par rapport au debug j'ai bien installé GenKmod mais rien ne s'affiche dans la fenetre debug, j'utilise bien KLog_U2 etje compile avec %GDK_WIN%\bin\make -f %GDK_WIN%\makefile.gen debug

J'ai raté quelque chose ?

[Stef]

@Tryphon> La méthode VDP_setMapEx(..) n'utilise pas le DMA (c'est une copie software assez lourde en réalité), vaut mieux la placer dans le VBlank quand même (dans le callback de l'interruption). Il faut que j'ajoute des méthodes pour mettre à jour juste une colonne / ligne de la map (qui elles pourront utiliser le DMA), ça sera plus performant..

@Infitek> Il faut aussi (et d'abord) re-compiler la librairie en mode debug (c'est elle qui donne les infos) si ça n'a pas été fait (mais normalement je fournis les 2 versions de la lib) :

Code:

%GDK_WIN%\bin\make -f %GDK_WIN%\makelib.gen debug

Et le fait de compiler ton projet en mode debug va automatiquement linker sur la lib "debug". Sinon vérifie de bien avoir activer les fonctions "debug" de l'émulateur KMod (il me semble qu'il y a une option à cocher quelque part pour ça).

[Infitek]

Ok ça fonctionne, c'est génial, thanks !
Je vais pouvoir débugger mon scrolling multidirectionnel

[Tryphon]

J'ai regardé ton code. Pour fixer les idées, j'appelle px, py les coordonnées de la caméra en pixels, et tx, ty les coordonnées en tiles (tx = px/8 et pareil pour y).

Le problème, c'est ça : imagine que la camera soit en px = 480 et py = 0, soit tx = 60, ty = 0 et que tu demandes de tracer une ligne de 40 tiles.

Comme ton plane fait 64 tiles de larges, il tracera les 4 premières correctement, mais les 36 restantes, il les mettra à la suite dans la VRAM. Mais à cet endroit, ce sont les coordonnées de la ligne ty = 1.

Donc tu dois tracer ta ligne en 2 morceaux : de 60 à 63 et de 0 à 35.

Ça se produit lorsque tx est plus grand que 64 - 40 = 24.

Et pareil pour y, lorsque ty est plus grand que 32 - 28 = 4.

Autre plus petit problème : tu dois tracer des lignes de 41 tiles (si px n'est pas un multiple de 8 il y a bien 41 tiles visibles, la première et la dernière étant partiellement visibles sur les bords de l'écran) et des colonnes de 29.

Bref, ça donne ça :

Code:

        if (camera_move_left) {
            if ((ty & 31) < 4) {
            VDP_setMapEx(PLAN_A, map, basetile, tx & 63, ty & 31, tx, ty, 1, 29);
         }
         else {
            l = 32 - (ty & 31);
            VDP_setMapEx(PLAN_A, map, basetile, tx & 63, ty & 31, tx, ty, 1, l);
            VDP_setMapEx(PLAN_A, map, basetile,   tx & 63, 0, tx, ty + l, 1, 29 - l);
         }
        }
        else if (camera_move_right) {
         if ((ty & 31) < 4) {
            VDP_setMapEx(PLAN_A, map, basetile,   (tx + 40) & 63, ty & 31, tx + 40, ty, 1, 29);
         }
         else {
            l = 32 - (ty & 31);
            VDP_setMapEx(PLAN_A, map, basetile, (tx + 40) & 63, ty & 31, tx + 40, ty, 1, l);
            VDP_setMapEx(PLAN_A, map, basetile, (tx + 40) & 63, 0, tx + 40, ty + l, 1, 29 - l);
         }
        }
        if (camera_move_up) {
         if ((tx & 63) < 24) {
            VDP_setMapEx(PLAN_A, map, basetile,   tx & 63, ty & 31, tx, ty, 41, 1);
         }
         else {
            l = 64 - (tx & 63);
            VDP_setMapEx(PLAN_A, map, basetile, tx & 63, ty & 31, tx, ty, l, 1);
            VDP_setMapEx(PLAN_A, map, basetile,   0, ty & 31, tx + l, ty, 41 - l,   1);
         }
        }
        else if (camera_move_down) {
         if ((tx & 63) < 24) {
            VDP_setMapEx(PLAN_A, map, basetile,   tx & 63, (ty + 28) & 31, tx, ty + 28, 41, 1);
         }
         else {
            l = 64 - (tx & 63);
            VDP_setMapEx(PLAN_A, map, basetile, tx & 63, (ty + 28) & 31, tx, ty + 28, l, 1);
            VDP_setMapEx(PLAN_A, map, basetile, 0, (ty + 28) & 31, tx + l, ty + 28, 41 - l, 1);
         }
        }
    }

J'ai vérifié, ça semble marcher (au passage, pour tester des scrollings, désactive la physique du joueur et pilote la caméra directement au pad).

Tu risques d'avoir des petits problèmes si la caméra peut bouger de plus de 8 pixels par frame (j'ai pas vérifié si ça pouvait se produire avec la physique de ton perso). Auquel cas il faudra tracer 2 lignes ou 2 colonnes.

[Infitek]

Ça fonctionne impeccable !

J'ai pas encore constaté de problème par rapport à la physique de mon personnage, c'est super, j’ai commencé à bosser sur le comportement des ennemis et les hitbox j’espère pouvoir sortir une démo bientôt encore merci pour ton aide précieuse !

[Infitek]

Me revoilà (et oui déjà ), j'aimerais avoir une image pour mon décor et une pour les collisions (je n'afficherais que celle de mon décor, je me servirais de celle des collisions uniquement pour les données.. ben de collision)
 
Du coup j'ai fait comme ça :

Code:

    VDP_loadTileSet(bgLevel_image.tileset, levels[actual_level].tile_index, TRUE);
    levels[actual_level].map = unpackMap(bgLevel_image.map, NULL);
    levels[actual_level].col = unpackMap(colLevel_image.map, NULL);

Je charge le tileset de la première image puis j'unpack l’image pour la mettre dans ma map (il s'agit bien la de mon image de décor)
Ensuite j'unpack l'image des collisions.

Ma fonction de collision fonctionnait bien avec l'image de décor mais en remplaçant par celle des collisions cela ne fonctionne plus, faut il aussi utiliser VDP_loadTileSet pour mon image de collision ?

[Tryphon]

Là je peux pas t'aider, moi je fais que du bas niveau... (mais je pense que non).

[Stef]

Pas besoin de charger les tiles pour la map de collision, par contre il faut vérifier que tu n'es pas à court de mémoire (si ta map est assez grande, ça peut prendre pas mal de place avec la map de collision en plus), la fonction unpackMap(..) te retourne NULL dans ce cas.. si ce n'est pas le problème alors il faudrait juste voir les indexes de tuiles utilisés.

[Infitek]

Effectivement unpackMap() me retourne NULL pour les collisions.. c'est embetant.. Je vais essayer de remplacer les tiles de mon image de collisions par la même tile partout.

[Tryphon]

Un truc qu'on fait souvent : plutôt que d'avoir une carte de collisions, on stocke les infos de collision sur le tileset.

(ce n'est pas comme ça que je fais sur Shinobi, cela dit, parce qu'en plus de la collision, je stocke d'autres données sur la carte, comme le numéro d'étage) (mais je pourrais, en dupliquant des tiles du tileset).

[Infitek]

Un truc qu'on fait souvent : plutôt que d'avoir une carte de collisions, on stocke les infos de collision sur le tileset.

(ce n'est pas comme ça que je fais sur Shinobi, cela dit, parce qu'en plus de la collision, je stocke d'autres données sur la carte, comme le numéro d'étage) (mais je pourrais, en dupliquant des tiles du tileset).

Oui mais pour faire cela j'ai besoin de connaitre le numéro de tous mes tiles non ?
Numéro qui peux changer selon l'image même si le tileset est le même étant donné que rescomp va organiser les tiles selon celles qu'il rencontre en premier.

[Infitek]

J'ai remplacé BEST par NONE dans mon fichier res pour la compression et maintenant ça fonctionne... Pourtant la compression n'est pas sensée avoir l'effet inverse ?

[Infitek]

Un petit aperçu du rendu que j'ai pour l'instant : https://i.servimg.com/u/f57/20/05/15/69/rom_0015.png

J'imagine que je dois utiliser des sprites si je veux faire de la pluie ou animer l'eau par exemple

[Tryphon]

J'ai remplacé BEST par NONE dans mon fichier res pour la compression et maintenant ça fonctionne... Pourtant la compression n'est pas sensée avoir l'effet inverse ?

Pas forcément. Si une carte n'est pas compressée, elle peut être entièrement stockée en ROM, où la place n'est pas limitée (enfin si mais t'as le temps).

Par contre, si elle est compressée, elle doit d'abord être décompressée en RAM (très limitée : 64 ko) avant d'être exploitable.

La compression servait surtout à l'époque où la ROM était chère. Aujourd'hui tu devrais pas t'embêter avec ça. Du moins pas dans un premier temps.

Le rendu est plutôt sympa

C'est toi qui a dessiné les sprites ou c'est tiré d'un jeu ?

[Stef]

En fait quand tu n'as pas de compression, la fonction unpackMap(..) ne fait rien et te retourne la map source directement (qui est stocké en ROM ici)... à noter que la prochaine version de SGDK ne fera plus ça (elle crééra une copie de la map à la place, ce qui est plus safe mais consommera plus de mémoire RAM).

[Infitek]

Ah je comprends mieux, mais il y a tout de même une limite de tiles maximum par image même si je ne compresse pas il me semble ?

Pour l'instant c'est des images libres de droits mais ma sœur bosse sur les sprites, je mettrais bientôt tout ça a jour

[Tryphon]

Pour animer l'eau ou la pluie, y'a plusieurs techniques :

* animation de palette (cycle de couleurs) (pas mal pour la cascade)

* animation de tile (tu modifies les graphismes d'une tile présente plusieurs fois dans ta carte) (c'est ce que fait Ghouls'n Ghosts au niveau 1 pour la pluie, mais il sacrifie un plan)

* animation de plan (tu changes certaines l'index de certaines tiles du plan)

* sprites (mais attention à l'overflow)

[Tryphon]

Ah je comprends mieux, mais il y a tout de même une limite de tiles maximum par image même si je ne compresse pas il me semble ?

Tes tiles vont en VRAM donc t'es limitée par sa taille (environ 48 ko utilisables au doigt mouillé, plus en rusant).

Mais ça n'a rien à voir avec la taille de la carte (et ça ne va pas en RAM).

[Stef]

Ah je comprends mieux, mais il y a tout de même une limite de tiles maximum par image même si je ne compresse pas il me semble ?

Pour l'instant c'est des images libres de droits mais ma sœur bosse sur les sprites, je mettrais bientôt tout ça a jour

Ah oui il y a quand même une limite de tiles, il faut que tout rentre en VRAM aussi

[Infitek]

Oui tant qu'il n'y a pas trop de tiles différentes sur une map même énorme ça passe donc.
Merci pour les précisions, c'est la première fois que je dois faire autant attention à l'optimisation pendant le développement d'un jeu, je sens que ça va être formateur

[Tryphon]

Ah ça c'est clair que le dev sur vieille bécane, c'est un autre monde

[Infitek]

Du coup je peux taper mes ennemis maintenant et cela instancie un sprite d'un effet de sang sur leur position, cela marche avec deux ennemis, par contre si j'en mets un troisième le sprite de sang ne s'affiche pas, on dirait qu'il n'y a plus de mémoire, ce qui m'étonne car quand j'observe les Sprites avec GensKmod seuls les 15 premiers sprites sont assignés, le reste semble vide..

EDIT : Ah j'ai trouvé ça !

IMPORTANT NOTE: sprite allocation can fail (return NULL) because of automatic VRAM allocation even if there is enough VRAM available, * this can happen because of the VRAM fragmentation. You can use #SPR_addSpriteSafe(..) method instead so it take care about VRAM

EDIT2 : Ah non c'est déprécié, du coup le AddSprite est censé est safe de base donc le problème viendrait d'ailleurs

[Stef]

Le SPR_addSpriteSafe(..) n'est pas déprécié normalement.

[Infitek]

J'ai un "implicit declaration of function SPR_adSpriteSafe() " chez moi..
Je suis sous SGDK 1.34

[Tryphon]

Manque un d...