adnz a écrit:
Avec quoi vous pensez construire les datas/graphisme des écrans ? genre vous utilisez un tilemaker ?
moi j'avais commencé à faire un script pour pouvoir générer custom comme j'ai besoin un tilemaker, qui est en cours ...
juste tu choisis le tile et tu click/drag pour dessiner et ça génère les datas pour faire un array des id des tiles graphisme 1 = 0 / graphisme 2 = 1 etc...
https://oxustudio.com/to8/tilemaker/02/bon c'est pas parfait vue que je suis le seul à l'utiliser ...
J'avais envisagé plusieurs possibilités :
- Utiliser Pro Motion NG (j'ai déjà une license), il permet de concevoir les map comme ton outil, et il permet de partir d'une image et de créer le tileset correspondant et la map.
- Développer un outil spécifique
- Utiliser des outils d'édition de niveau de Sonic + un convertisseur custo
Cependant, j'imagine que fxrobin récupèrera les données de map dans une version existante, ça ira plus vite que de tout refaire à la main.
En tout cas merci pour ta proposition, j'apprécie ! c'est une bonne base
Il faut d'abord qu'on définisse les besoins, et puis il y a plusieurs techniques pour gérer les tilesets.
J'avais commencé à réfléchir au sujet en imaginant une solution permettant de gérer de grandes maps,
l'idée est de regrouper les tiles en blocs :
Citation:
La map serait de taille maximum de 128x128 blocs (16ko), chaque bloc a donc une référence sur un octet.
Ces 256 blocs de taille 128x128 pixels sont composés de 8x8 images de 16x16px, chaque définition de bloc fait donc 64 octets (16 ko pour les 256 définitions de blocs). Oui ça fait bien une map de taille maximum de 16384px par 16384px !
Enfin l'index image fait 256x3 (un octet page, deux octets adresse) et pointe vers la routine d'affichage qui sera certainement un dérivé de celle des "sprites compilés".
Cette structure sera à multiplier pour chaque plan de tile a afficher (j'en ai prévu deux, un pour le fond, un autre pour les plateformes).
Les éléments en avant plan par rapport aux sprites seront gérés par le moteur de sprites et non par le système de tilemap.
Dernière précision, on pourra afficher la map à l'écran en déplaçant la "caméra" (zone affichée par l'écran) par pas de 16px (taille d'une image tile). Si vous avez bien suivi on perd donc 8 px en hauteur (l'image sera constituée de 20x16px en largeur et 12x16px en hauteur).
J'avais pensé ce modèle pour mes besoins mais du coup c'est intéressant de voir dans un autre contexte si c'est adapté ou pas.
... et rien n'empêche de penser un système "modulaire" qui permette de gérer plusieurs cas de figure, la priorité restant la performance (les tiles seront rendu en sprite compilés)
Dans Sonic il me semble qu'il y a trois niveaux de blocs : 128x128px, 16x16px et des tiles de 8x8px
Il faut trouver le juste milieu entre taille max de la map, taille du tile, performance de la routine d'affichage ...
Dans le cas de Rick Dangerous vous avez des infos sur le nb de niveaux, leur taille, le nb de tiles, gestion de blocs ?
Pour ce qui est de la notion de solidité ce seront des données associées aux tiles, c'est le point le plus complexe, la encore il y a bcp d'options et le moteur de Rick Dangerous sera bcp plus simple de ce coté là par rapport à Sonic ;-) mais réalisons déjà l'affichage, sur cette partie il y a moyen de mettre en commun.