Re: Sgdk - Sega Megadrive / Genesis Development Kit

[Invité]

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

[Invité]

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.

Il faut que tu récupères les coordonnées X/Y de ton sprite, que tu les transformes en coordonnées de tiles, et qu'ensuite dans ta map ou dans une map de collisions dédiée tu testes le type de collision comme l'a décrit tryphon.
La map de collision peut être faite sous tiled il me semble, y'a des tutos pour ça .

Donc faut tenir à jour le pointeur vers la map de collision en fonction du scrolling .

[ichigobankai]

Rien de bien compliqué (ni tres gourmand)

[Invité]

Rien de bien compliqué (ni tres gourmand)

C'est vrai, mais peut être galère si mal pensé au départ .

[Invité]

Un truc moins sensible que la Fuckin' VBlank !!

[Invité]

Un truc moins sensible que la Fuckin' VBlank !!

si,si c'est foiré,ça peut niquer la jouabilité 

[Invité]

Oki, je vais regarder ça dans la journée.

Merci @StudioVetea et @Stef pour m'avoir aidé hier afin de comprendre les bases du scrolling d'une tiles map.

Je vais pouvoir me concentrer sur la réalisation de la carte maintenant :)

J'ai regardé rapidement dans Tiled, je n'ai vu que la collision à définir pour le tileset.

[Invité]

J'ai regardé rapidement dans Tiled, je n'ai vu que la collision à définir pour le tileset.

Oui, et je pense que c'est normal(si tu définis par exemple une tile "non-walkable=1",il va te remplacer toutes les tiles identiques de ton tilemap par la valeur 1 dans le layer de collisions), ensuite il me semble que tu peux juste exporter ce fichier, et t'en servir, il sera directement en relation avec ton tilemap .

[Tryphon]

Dans Tiled tu peux définir des attributs pour les tiles (par exemple des infos de collision), mais ça sera à toi d'écrire le script de conversion dans SGDK je suppose (faut voir avec Stef).

Moi j'ai carrément dans mes cartes de Shinobi un calque spécial pour les collisions, mais j'ai fait mon propre générateur de ressources.

[Stef]

Dans Tiled tu peux définir des attributs pour les tiles (par exemple des infos de collision), mais ça sera à toi d'écrire le script de conversion dans SGDK je suppose (faut voir avec Stef).

Oui pour l'instant SGDK ne gère pas les maps de Tiled (collisions, objets...) et c'est bien dommage, va falloir que j'ajoute cette feature (mais ça prendra surement un peu de temps, surtout que je prévois de réécrire rescomp en java car le maintenir en C c'est franchement l'enfer :p).

[Tryphon]

Python c'est bon...

[ichigobankai]

Clair qu'en python, c'est rapide à coder et a mettre à jour.
(et pour manipuler du XML... je dis ca je dis rien)

Comme Tryphon, j'ai des calques spécifiques. Je trouve ca souple à l'utilisation.

[Stef]

Je sais que python c'est rapide à coder mais d'une part je ne connais pas (j'ai jamais vraiment codé en python ) et aussi je préfère éviter d'ajouter une dépendance sur Python avec SGDK (déjà que vers Java c'est un peu chiant mais au moins c'est plus répandu ^^).
Je connais bien java donc je suis assez rapide avec et puis on peut tout faire assez facilement (GUI, algos complexes et assez lourd type compression / optimization...) ce que python ne fait pas aussi bien.
Mais je suis d'accord que lorsqu'on en vient à faire du script / parsing / manipulation de fichier etc... python est le plus efficace et rapide.

[Tryphon]

Python est surtout moins verbeux, et ça c'est cool (j'ai jamais aimé la syntaxe du C/C++/Java). Et t'obliges à écrire du code formatté, ce qui est sympa quand tu lis du code d'autres personnes (c'est pas ton cas, le source de SGDK est un régal )

Après, pour ce que tu peux faire, ça se vaut (les GUI c'est chiant dans les 2 cas, les algos sur de grosses quantités de données je connais des labos qui le font en python avec SciPy ou NumPy).

Du coup, tu prends celui que tu préfères (Upsi nous dirait que Lua c'est pas mal aussi). Moi je sais que le jour où j'ai essayé Python la première fois, j'ai su qu'à part le C pour les perfs (et CamL pour le fun) (jeu de mot inside), j'aurais plus envie d'apprendre un nouveau langage (faut dire que j'en avais fait pas mal avant plus ou moins contraint et forcé, et ça me lourde)

[Invité]

@Shingo : Oui, c'était cool ! Et puis c'est un plaisir de partager ses expériences avec Stef.

Sinon, pour ma part, j'ai créé un outil spécifique pour ça : MapCoder !



On définit la grille voulue, le type d'Obstacle ( 8 disponibles, mais on peut en créer indéfiniment ... ), et ensuite, y a juste copier coller le résultat dans son code ( C ou autres si besoin ... )



Pas la peine de s'emmerder à apprendre le Python, le Cobra ou la Couleuvre ... Quand il te faut un truc spécifique, autant le créer !
Bonne VBlank à tous.

[ichigobankai]

Sauf que pour créer ta fameuse appli, faut apprendre -un peu- a coder avant    

Sous Tiled, y'a déjà des scripts d'export d'intégrés (binaire, csv, lua, json...), mais le meilleur reste de faire soit même ce fameux script.
Ce sera du sur mesure pour ton jeu et il n'y aura rien à faire en manip ensuite.

[Invité]

Ben tu vois, je trouve plus simple de coder son outil, qu'essayer de s'adapter à un outil déjà existant.
J'ai essayé avec Tiled, je n'y suis jamais arrivé ... Je bloque avec ces outils certes performants que tout le monde utilise d'ailleurs ...

Je sais, c'est débile, mais c'est ma manière de faire. 

[Invité]

C'est sur que c'est pratique le sur mesure. Par contre à quoi correspondent les valeurs du tableau, 0 1 2 3...

[Invité]

Ces valeurs représentent le type d'obstacle défini ensuite dans ton code ( Obstacle Brut, Eau qui ralentit de 50% la vitesse, etc ... )
La première ligne est le haut de ta map, chaque ligne représente donc ta coordonnée verticale Y.
Et sur chaque ligne, tu as tes positions horizontales X.
Tout cela est définit par le type d'échelle que tu as choisit pour ta map ( 4x4, 8x8, 16x16, 32x32 ).
C'est tout bête, mais avant je me tapais ça à la main pour ainsi dire ... 

[Invité]

Surtout que dans certains cas tu voudras peut être utiliser juste quelques bits/tile, ce qui aura pour conséquence de réduire fortement le fichier de collisions .
Je suppose que tiled (ou autres) utilisent minimum des collisions sur 8bits non ??
Déjà utiliser 4 bits / tile(qui donne qd même 16 types de collisions) va diviser par 2 la taille du fichier (au dépend d'un peu plus de CPU) .

[Invité]

J'ai fini ma carte et je comprends pas comment exploité le fichier json que tiled à généré. J'ai compris que la key "data" était un array des id de chaque tiles utilisées. OK, mais sans la position X et Y j'en fais quoi de ces données ?!

Je voudrais simplement obtenir la position X / Y ou alors la position en tiles, c'est possible sans finir avec un mal de crâne ?!

Bon je pense avoir compris, dans mon fichier json, l'id des tiles est indiquée par ligne. Il faudrait que je crée un script python pour remettre ça en ordre et m'indiquer la position en tile ou X/Y.

edit : super j'ai trouvé où était indiqué la position en tile, je vais enfin pouvoir créer mon script

[Invité]

Je voudrais simplement obtenir la position X / Y ou alors la position en tiles, c'est possible sans finir avec un mal de crâne ?!

Tu divises chaque coordonnées (X et Y) de ton sprite par 8 en commençant par Y .
Tu auras la ligne,tu la multiplies pas le nombre de tiles qu'il y a sur une ligne de ton écran(en 320 pixels c'est 40), ensuite tu ajoutes X,et ça te donne le nombre d'octets que tu dois passer dans ton fichier de collisions pour atteindre la bonne tile (si tes collisions sont codées en octets bien sur) .
Pour accélérer les calcul tu peux utiliser un tableau ou chaque indice correspond à la valeur à ajouter pour Y:

0
40
80
120
160
etc ..

Donc si par exemple ton Y = 2 tu ajoutes X à 80,mais il faudra aussi tenir compte du scrolling .
tu as aussi la solution de récupérer la tile directement en VRAM pendant le vblank, mais ça limite le type de collision à mortel/non mortel.

[ichigobankai]

idem Touko.

Et pourquoi un export en json ?
Le plus proche (mais vraiment très très proche) de ce qu'à poster Vetea dans son exemple/catpure serait un export CSV (valeurs séparées par une virgule)

[Invité]

Je voudrais simplement obtenir la position X / Y ou alors la position en tiles, c'est possible sans finir avec un mal de crâne ?!

Tu divises chaque coordonnées (X et Y) de ton sprite par 8 en commençant par Y .
Tu auras la ligne,tu la multiplies pas le nombre de tiles qu'il y a sur une ligne de ton écran(en 320 pixels c'est 40), ensuite tu ajoutes X,et ça te donne le nombre d'octets que tu dois passer dans ton fichier de collisions pour atteindre la bonne tile (si tes collisions sont codées en octets bien sur) .
Pour accélérer les calcul tu peux utiliser un tableau ou chaque indice correspond à la valeur à ajouter pour Y:

0
40
80
120
160
etc ..

Donc si par exemple ton Y = 2 tu ajoutes X à 80,mais il faudra aussi tenir compte du scrolling .
tu as aussi la solution de récupérer la tile directement en VRAM pendant le vblank, mais ça limite le type de collision à mortel/non mortel.

D'accord, mais pourrais-tu me donner un exemple d'une collision codée en octet ?

Si j'ai bien compris, il faut :

1) Diviser la position Y du joueur par 8 et multiplier le résultat par le nombre de ligne "40".
2) Diviser la position X du joueur par 8
3) Additionner les deux résultats pour obtenir le nombre d'octet.

Maintenant comment convertir les données de tiled en octet sachant que mes tiles font 16x16 et non 8x8 ?

[Tryphon]

Ben au lieu de diviser par 8, tu divises par 16...

Par contre, le 4O, c'est le nombre de tiles dans une ligne de la carte de ton niveau. Elle ne fait que 32O pixels de large ta carte ?

[Invité]

Non la carte fait 4096 x 208 pixels

[Tryphon]

Tu as donc 4O96/16 = 256 tiles par ligne.

Donc c'est plutôt : (y / 16) * 256 + (x / 16) ta formule pour retrouver ton octet dans ta carte de collision.

[Invité]

Oki ^^

Code:


    a = fix32ToInt(player.posy);
    b = fix32ToInt(player.posx);
    player_tile = (a / 16) * 256 + (b / 16);

C'est normal que dans le coin en bas à droite, le résultat est de 3346 alors que je pensais trouver 3328 ?

edit : ah en fait c'est dû à mon offset de 2 tiles pour laisser de l'espace à la window...

[Tryphon]

En bas à droite, y = 2O7 et x = 4O95

Tu dois trouver (2O7 / 16) * 256 + (4O95 / 16) = 12 * 256 + 255 = 3327.

Donc aucun des deux n'est normal

[Invité]

OK j'ai compris, le problème semble être le fix32ToInt(), car 207/16 = 12,9375 donc forcément, il passe à 13 une fois la fonction appelée.

[Tryphon]

Non.

/ c'est la division entière, ça n'arrondit pas à l'entier le plus proche mais à l'entier inférieur.

2O7/16 = 12.