Les maps et les tiles dans SGDK

[Kivutar]

Bonjour tout le monde.

Je viens de découvrir SGDK et gendev, c'est l'occasion de ressortir ma vieille Megadrive du placard et de réaliser un rêve d'enfant :)

Donc j'ai commencé à réécrire un de mes prototypes de jeux pour qu'il tourne sur SGDK. C'est un jeu de plateforme qui va ressembler à ça:



Mais sur SGDK j'en suis pas aussi loin. Il ressemble à ça:



J'ai la physique et les collisions qui fonctionnent comme je veux.

Maintenant mon souci c'est d'adapter ma première map. Mes maps sont au format de tiled. J'ai fais un petit script qui m'exporte les hitboxes en C et ça passe bien. Par contre là ce qu'on voit sur le PLAN_A c'est une gros PNG exporté depuis Tiled. Et quand ma caméra se déplace vers la droite, la même image reviens en boucle.

J'aimerais que quelqu'un m'explique un peu qu'est-ce que c'est la bonne approche pour adapter ma map dans SGDK.

Vu que Tiled a déjà un systeme de Tilesets, est-ce que je peux exporter ces tilesets pour la mégadrive et convertir d'une façon ou d'une autre ma map ?

J'ai vu qu'il y avait un format de map supporté nativement par SGDK mais j'ai pas trouvé trop de doc dessus. C'est quoi en fait ?

Est-ce que c'est difficile au niveau du code d'alimenter le PLAN_A du VDP au fur et à mesure que mon personnage se déplace ?

C'est quoi la fonction la plus appropriée pour afficher une rangée de tiles sur la droite ?

Merci d'avance !

[Kivutar]

Bon j'ai un peu avancé:

- Je charge mon tileset avecVDP_loadBMPTileData
- J'ai un long tableau d'entier qui représente mes tiles et qui viens de mon fichier .tmx
- Quand ma caméra se déplace horizontalement, je charge les nouvelles colonnes de tiles à gauche ou à droite sur mon PLAN A à coup de VDP_setTileMapXY
- J'utilise un modulo sur X pour gérer quelques soucis du au fait que l'affichage boucle sur les plans

Donc ça fonctionne. Par contre le ça fait lagger le jeu à fond, donc je pense que c'est juste pas la bonne technique. Appeller VDP_setTileMapXY 84 fois en une frame, ça à l'air trop lourd.

J'ai vu dans le code de cave-story-md qu'il utilise DMA_queueDma dans la VRAM dans camera.c

C'est quoi la façon classique d'implémenter le scroll ?

[Tryphon]

Je fais comme toi et ça lagge pas, curieux...

Déjà, ne fais pas un mod mais plutôt un " et" logique (et demerde toi pour que la largeur de ta map soit une puissance de 2).

Tu peux en effet aller plus vite avec du DMA, mais je ne pense pas que ton problème soit là...

[Kivutar]

Ca y est j'ai enfin réussi. Et tu avais raison, c'était mon code qui n'était pas assez optimisé. J'avais des boucles for imbriquées et des conditions pour chaque tile à ajouter alors qu'il me suffisait de calculer l'index du tableau avec une multiplication et une addition.

Du coup je fais ça sans DMA et c'est plus facile pour mon niveau.

Je met mon code qui fonctionne au cas où quelqu'un bloquerait sur le même souci:

Code:

        s8 morphing = (s8)(camera_next_x/8) - (s8)(camera_x/8);

        if (morphing)
        {
            for (u16 y = 0; y < MAP_H; y++)
            {
                u16 x = -camera_x / 8 + (morphing < 0 ? 41 : -1);
                VDP_setTileMapXY(VDP_PLAN_A, TILE_ATTR_FULL(PAL1, 0, 0, 0, map[y * MAP_W + x]), x % 64, y);
            }
        }

En tout cas merci pour l'aide. J'étais carrément bloqué.

[Tryphon]

C'est encore énormément optimisable, par exemple :

* tu recalcules x à chaque étape de la boucle alors qu'à première vue il ne change pas : sors le calcul de la boucle

* tu calcules y * MAP_W dans chaque passage de la boucle, pourquoi ne pas écrire map[pos], avec pos initialisé à x avant la boucle, et pos += MAP_W après le VDP_setTileMapXY

* probable que le compilo le fasse seul, mais c'est pas sûr : si MAP_W = 2^N, remplace y * MAP_W par y << N (par exemple, y * 1024 est plus lent que y << 10)

* de même, x & 63 est plus rapide que x % 64 (et d'ailleurs puisque ce x % 64 est constant dans la boucle, tu peux le sortir)

* il y a encore d'autres optimisations possible, comme faire une boucle descendante, mais à ce niveau c'est du pinaillage

[Kivutar]

Ah merci beaucoup pour ces conseils. J'ai commencé à les appliquer là.

C'est la première fois que je dois faire autant attention aux performances. Je sens que ça va m'apprendre pas mal de choses :)

[Tryphon]

Oui, c'est ce qui est embêtant

En plus, un excellent conseil en programmation est de ne pas optimiser trop tôt (parce qu'un programme optimisé est en général plus difficile à lire et à modifier).

Mais quand tu codes sur MD, tu es obligé de faire assez tôt des optimisations, car la machine est vieille et lente (et en plus tu codes en C, pas en assembleur).

Donc je donnerais plutôt comme conseil :

* code en faisant les optimisations simples (notamment les boucles)

* en deuxième lecture, fais les optimisations plus élaborées (DMA par exemple)

[Stef]

Partir d'une grande image PNG avec SGDK (ressource IMAGE) je dirais que c'est la méthode classique et simple qui fonctionne très bien :)
En interne la ressource Image est composée d'un Tileset et d'une Map.
Tu charges le TileSet avec VDP_loadTileset(..) et ensuite tu utilises la méthodes VDP_setMapEx(..) pour mettre à jour des parties de la Map dans le tilemap hardware (en général tu mets une ligne ou une colonne à jour en fonction du scrolling).
C'est beaucoup plus rapide que d'utiliser la méthode VDP_setTilemapXY(..)...
Aussi si l'image est compressée alors il ne faut pas oublier de décompresser la Map en amont:
Map* map = unpackMap(image.map, NULL);

Sinon la map sera décompressée à chaque appel à VDP_setMapEx(...) ce qui est trèèès lent.

[Kivutar]

Ah OK!

Pour l'instant mon code ressemble à ça:

Ma map est un tableau d'entiers.

Je la dessine comme ça durant l'init:

Code:

void drawmap(u16 ind)
{
    for (u16 y = 0; y < MAP_H; y++)
        for (u16 x = 0; x <= SCREEN_WIDTH/8; x++)
            drawtile(x, y, ind);
}

Puis dans ma caméra je met à jour les bords à droite ou à gauche:

Code:

    s8 morphing = (s8)(camera_next_x/8) - (s8)(camera_x/8);

    if (morphing)
    {
        u16 x = -camera_x / 8 + (morphing < 0 ? 41 : -1);
        for (u16 y = 0; y < MAP_H; y++)
            drawtile(x, y, ind);
    }

Et ma fonction qui blite le tile:

Code:

void drawtile(u16 x, u16 y, u16 ind)
{
    u16 t = map[y * MAP_W + x];
    if (t)
        VDP_setTileMapXY(VDP_PLAN_A, TILE_ATTR_FULL(PAL1, 0, 0, 0, ind - 1 + t), x & 63, y);
    else
        VDP_setTileMapXY(VDP_PLAN_A, TILE_ATTR_FULL(PAL1, 0, 0, 0, ind), x & 63, y);
}

Ca fait que j'avais un tileset pas optimisé par SGDK et chargé à la main avec VDP_loadBMPTileData.

Si c'est mieux et plus rapide avec une grosse image plus VDP_setMapEx je vais plutôt faire comme tu dis.

[Kivutar]

OK j'ai fais comme tu as dit et ça fonctionne très bien comme ça.

Code:

VDP_drawImageEx(VDP_PLAN_A, &test_level, TILE_ATTR_FULL(PAL1, FALSE, FALSE, FALSE, ind), 0, 0, FALSE, TRUE);

Et dans ma caméra:

Code:

    s8 morphing = (s8)(camera_next_x/8) - (s8)(camera_x/8);

    if (morphing)
    {
        u16 x = -camera_x / 8 + (morphing < 0 ? 41 : -1);
        VDP_setMapEx(VDP_PLAN_A, test_level.map, TILE_ATTR_FULL(PAL1, FALSE, FALSE, FALSE, ind), x & 63, 0, x, 0, 1, 28);
    }

J'ai pu virer mes fonctions drawmap et drawtile qui ne servent plus à rien.

Pour l'instant je n'utilise pas la compression.

Merci pour votre aide Steph et Tryphon. Je m'éclate à apprendre SGDK.

[Stef]

Bah voilà, je pense que tu as tout compris, bien joué J'ai hâte de voir ce que ça va donner :)

[Kivutar]

Ca rend comme je voulais, je vais pouvoir passer à la suite.

[Stef]

Bravo ca marche bien (avec gestion des pentes en plus ^^) et c'est joli comme tout :)

[Kivutar]

Merci :)

Par contre je sens que je vais devoir réécrire les pentes pour que mon personnage s'y colle en descendant.

De toute façon mon système de collisions est surement trop lourd (pas otpimisé) et ça va se faire sentir quand je vais ajouter plus d'éléments de jeu.

[Hpman]

Ouaip c'est généralement emmerdant les pentes, surtout dans le sens descente.

[troudki]

du coup, ta map est limitée à 2048 tiles ou pas ?

[troudki]

Partir d'une grande image PNG avec SGDK (ressource IMAGE) je dirais que c'est la méthode classique et simple qui fonctionne très bien :)
En interne la ressource Image est composée d'un Tileset et d'une Map.

Du coup, la map est limité à 2048 tiles ? (rescomp est bien limité à ce niveau , non ?)

[Kivutar]

Aucune idée, pour l'instant j'utilise de petites maps de 1024*224 pixels.

[Tryphon]

Je ne crois pas que SGDK gère les maps plus grandes qu'un plane...

[Invité]

Ma Map de test pour Papi Reload fait 320x2048 !!
La seule limite : La RAM et pi un peu la VRAM ...
Je songe a du 320x4096. :)

[Tryphon]

Tu gères le scrolling toi-même ou SGDK fait du scrolling 8-directionnel ?

[philip]

1024x1024 mais sgdk limite à 512x512. Passé 512 pixels, il y a un petit décalage Y qu'il faut compenser. Et oui il y a des commandes pour les scroll horizontal et vertical.

[troudki]

Ma Map de test pour Papi Reload fait 320x2048 !!
La seule limite : La RAM et pi un peu la VRAM ...
Je songe a du 320x4096. :)

Est ce que ta Map est basée sur une image de 320x2048 que tu charges via la méthode de STEF "grande image PNG avec SGDK (ressource IMAGE)" 
car rescomp me génère une erreur pour maximum number of tile <2048> reached pour une image aussi grande.

[philip]

Avec ma version de dragonninja sur sgdk 1.21, la plus grande image, format bmp mis dans le dossier res, que je déclare fait une taille de 16 x 2048.

[Invité]

Je pense qu'il faut que le nombre de  Tiles associés à l'image soient aussi cohérents.
Pour ma part, mes MAP sont générés à la base d'un Tileset, sans excéder un nombre qui pourrait saturer la VRAM !
Rescomp doit avoir une sécurité à ce niveau là.

[Stef]

Je pense qu'il faut que le nombre de  Tiles associés à l'image soient aussi cohérents.
Pour ma part, mes MAP sont générés à la base d'un Tileset, sans excéder un nombre qui pourrait saturer la VRAM !
Rescomp doit avoir une sécurité à ce niveau là.

C'est exactement ça :) tu peux avoir une très grande image sans problème, par contre il faut effectivement ne pas dépasser les 2048 tiles différents dans ton image, ce qui est logique car derrière ton image est transformé en tilemap où 2048 tiles au maximum peuvent être addressés... Si tu utilises la compression alors ton image ne peut pas dépasser une certaine taille non plus car il te faut décompresser le tilemap en mémoire avant de l'utiliser donc ça te limite à un tilemap d'une taille max de 40Ko environ décompressé (soit une image de 2048x768 par exemple), sans la compression tu n'as virtuellement aucune limite sur la taille du tilemap (que tu vas utiliser directement depuis la ROM) si ce n'est l'utilisation de 2048 tiles différents au maximum.

[Tryphon]

Autrement dit, le meilleur moyen de générer une grosse map est de le créer avec un logiciel d'édition de map, quitte à nourrir rescomp avec un export png de la map.

Tiled fait ça bien.

[Stef]

Oui, c'est exactement comme ça que je fais, un gros PNG exporté depuis Tiled :) Il est primordial d'utiliser un outil adéquat pour créer la MAP, la MD (comme les autres consoles de cette génération ou antérieure) fonctionne à base de tile donc il faut concevoir les graphismes avec cette "contrainte"

[r_songo]

Je viens de me remettre a SGDK, et j'ai un problème sur la partie map, tiles, parallax.

Voila ce que je souhaite faire dans un premier temps.
J'ai une image en 320x240 qui sera mon background je souhaite un loop infini. C'est à dire que quand mon personnage avance à droite, je veux que le fond se décale vers la gauche et que la partie de gauche de l'image qui a disparu s'affiche à droite.

Ce que je fais actuellement :
Lors de l'initialisation :

Code:

 map = unpackMap(bgall_image.map, NULL);
ind = TILE_USERINDEX;
VDP_setScrollingMode(HSCROLL_TILE, VSCROLL_PLANE);
VDP_loadTileSet(bgall_image.tileset, ind, 0);
VDP_drawImageEx(PLAN_A, &bgall_image, TILE_ATTR_FULL(PAL0, FALSE, FALSE, FALSE, ind), 0, 0, FALSE, TRUE);
ind += bgall_image.tileset->numTile;

Et lors de l'update de la camera :

Code:

VDP_setMapEx(PLAN_A, map , TILE_ATTR_FULL(PAL0, FALSE, FALSE, FALSE, ind),  x1 & 31, 0, x1, 0, 1, 32);

Je n'ai pas bien compris le fonctionnement du setMapEx.
Les tiles sont bien découpé  en 32x32 ?
A quoi correspondent les 6 dernières valeurs ?

[Kivutar]

Je crois qu'avec le réglage par défaut, ta map va se répérer tous les 512 pixels. Donc si tu fais une image de 512x240, tu ne devrait pas avoir besoin d'appeller setMapEx. Ca va se répéter tout seul.