IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Développement 2D, 3D et Jeux Discussion :

[ENTRAIDE] Les bases du Tile-Mapping.


Sujet :

Développement 2D, 3D et Jeux

  1. #1
    Inactif  
    Homme Profil pro
    Développeur multimédia
    Inscrit en
    février 2021
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur multimédia
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2021
    Messages : 16
    Points : 0
    Points
    0
    Par défaut [ENTRAIDE] Les bases du Tile-Mapping.
    Ce post n'est pas une question c'est une réponse Ca pourrait être transformé en tutoriel si quelqu'un a le temps mais pas moi...

    Je sais que beaucoup de débutants galèrent avec cette technique d'affichage basique des jeux 2d, trop de mauvais tutoriels avec des calculs non-binaires, des dimensions non-standard, et un drawcall de quad par tile qui met les processeurs à genoux pour rien.

    Voilà une explication simplifiée très schématique, vous pourrez demander aux spécialistes du retro-gaming Vetea et Kannagi de vous expliquer plus en détails.

    A/ Bases mathématiques

    Tout est basé sur les calculs binaires (notemment le bitmask), donc les tiles, les tilesheets et les tilemaps sont intégralement à base de dimensions puissance 2 (8, 16, 32, etc...). Ainsi sur la nes les tilesheets avaient une largeur de 182 pixels, et une hauteur qui variait de 128 à 256. (l'adressage était dynamique afin de pouvoir animer les tilesheets en interne). Les tiles faisaient 8*8 pixels. La tilemap 32*32 tiles.

    La logique du tilemapping est entièrement basé sur les ascii sheets. C'est pourquoi un tilesheet de base fait 256 tiles (avec quelques caractères incorporés histoire d'afficher un peu de texte). Le premier jeu en tilemapping (Tetris) était entièrement affiché avec des caractères ascii. Vous pourrez ensuite doubler ou quadrupler les sheets mais il faut d'abord s'entraîner avec un seul.

    B/ Algorithme

    On appelle ça le "mirrored scrolling". Pour chaque plan, la tilemap est légèrement plus grande que l'écran et affichée en 4 exemplaires afin de pouvoir faire un scrolling répété. Au fur et à mesure qu'on scrolle, les tiles sont mises à jour sur les bords de l'écran. Même principe quand vous passerez à des mappings plus complexes avec des images rectangulaires, des maps géantes en quadtree, etc...

    Pour les jeux modernes (ex: les derniers mario 2d) les tilemaps peuvent également être contenues dans des objets indépendants (bloc de briques qui tourne, etc)

    C/ Rendu

    Méthodes hardware

    Le principe est le suivant: les tilemaps sont des renderTargets, où les tiles sont rendues à échelle 1 sans filtering. Le stretching se fera ensuite en fonction de la résolution écran (et des effets de zoom quand vous ferez de la 2d moderne).

    1/ Méthode débutants.

    La tilemap est mise à jour avec des petits drawcalls de quads qui permettent de copier-coller les tiles depuis le sheet. Les moteurs 2d de pygame, SDL et html5 le font automatiquement. En revanche avec cette méthode vous ne pourrez pas animer les tilesheets, l'arrière plan va rester statique.

    Une petite tech-démo maison en js, clic-droit, afficher la source: http://punkcoders.free.fr/platformer/

    2/ Méthode pro.

    La tilemap est rendue avec un shader de displacementMapping. Attention c'est gourmand en GPU donc prévoir un menu de baisse de résolution résolution pour les smartphones.

    Pour animer le tileSheet il doit lui-même être une renderTarget.

    Bon.... j'avais fait ça en assembleur pour le vieux flash player mais voilà un tuto webgl qui règle ça en une ligne de GLSL (qui n'est pas de moi):

    http://media.tojicode.com/zelda/

    Méthodes software

    Là vous faites exactement comme les émulateurs de vieille console, votre écran tronque une texture dont vous modifiez la couleur des pixels, en reproduisant les calculs de ces vieilles machines qui raisonnaient scanline par scanline afin de simplifier la logique de rendu en 1d. Le rendu au pixel près doit être optimisé à mort avec un maximum de calculs binaires.

    Petites tech-demos maison:
    En javascript: http://punkcoders.free.fr/noelshoot/
    En c++: http://punkcoders.free.fr/punkowip/

    voilà

    Vous avez tous les calculs dans les sources JS, bon apprentissage à tous.

    Pour la petite histoire, si les machines japonaises font ça beaucoup plus rapidement que nos machines chinoises, c'est parce que chez les japonais les calculs de tile-mapping sont directement programmés en assembleur embarqué dans les puces des bornes/consoles/cartouches.

  2. #2
    Inactif  
    Homme Profil pro
    Développeur multimédia
    Inscrit en
    février 2021
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur multimédia
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2021
    Messages : 16
    Points : 0
    Points
    0
    Par défaut
    Bon accrochez-vous c'est pas pour les 100% débutants. Mon ancien patron a annulé 3 projets parce qu'il avait pas le niveau pour se servir d'une librairie de tilemapping (tant pis j'ai été payé quand même... dans ce métier on annule beaucoup de projets, les deux premières versions de duke nukem forever c'était des millions jetés par la fenêtre...).

    Pour débuter le jeu vidéo on démarre par un pong histoire de déjà maîtriser les sprites, les states et les collisions AABB.

    Ensuite on fait un Tetris afin de s'initier au tile-mapping.

    Après on enchaîne par un mario-like, sans éditeur de maps, juste des petites listes d'objets converties en grille au chargement du niveau. Ensuite on attaque la galère de développer un éditeur de maps qui fait la même chose en offline (les vieux city-builders et wargames sont basés sur ces algos).

  3. #3
    Expert éminent
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    mai 2010
    Messages
    3 060
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : mai 2010
    Messages : 3 060
    Points : 9 584
    Points
    9 584
    Par défaut
    Il est vrai que la Nes utilise du 8x8 en hardware , mais la plupart des programmeurs faisait des meta-tiles (pour avoir des bloc de 16x16) ce qui permet de réduire la taille de la map par 4 !
    Après on peut continuer avec du 32x32 (mais c'est assez contraignant) , ou alors faire comme Sonic qui réutilisé des bloc de 256x256 pixel (divisé eux en meta-tile).

    Bien sur de nos jours ça sert pas à grand chose ,avoir une map de 32ko , c'est pas génant , à l'époque un peu plus
    (Et puis de nos jours on peut avoir de gros buffer en mémoire ,donc faut mieux privilégier des compression du type LZ4)

    Je préciserai juste qu'il y'a un excellent outils pour faire ces map : Tiled dispo ici : https://www.mapeditor.org/
    Je l'utilise sur tout mes jeux , et donc ça marche assez bien pour la SNES , Neo Geo et j'y passe


    votre écran tronque une texture dont vous modifiez la couleur des pixels, en reproduisant les calculs de ces vieilles machines qui raisonnaient scanline par scanline afin de simplifier la logique de rendu en 1d.
    Ce n'est pas parce que c'est plus simple de faire du scanline , où qu'il y'avait une logique du 1D , c'est même assez complexe , mais il était moins chère d'avoir un rendu par scanline que d'avoir un double frame buffer.
    Parce que oui les vielles consoles 8/16 bits avait un buffer , mais un line buffer ,du coup ça permettait d'avoir un rendu rapide (le line buffer était directement sur la puce graphique donc avec un accès rapide ) et donc au final de pouvoir afficher beaucoup de chose à l'écran ,bien plus qu'un PC de l'époque

  4. #4
    Inactif  
    Homme Profil pro
    Développeur multimédia
    Inscrit en
    février 2021
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur multimédia
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2021
    Messages : 16
    Points : 0
    Points
    0
    Par défaut
    [QUOTE=Kannagi;11680890]la plupart des programmeurs faisait des meta-tiles (pour avoir des bloc de 16x16) ce qui permet de réduire la taille de la map par 4 ! Après on peut continuer avec du 32x32 (mais c'est assez contraignant)[
    J'ai lu la doc de la super-nes, les tiles 16*16 étaient gérées en hardware. Ca a permis aux devs de metroid3 de faire l'impasse sur l'algo du mirrored-scroll histoire d'économiser un max de CPU.
    Sinon les 32*32 je m'en suis servi aussi parce que les clients sont pas trop friands du style retro. Pas de contrainte particulière, faut toujours dessiner le raccord au pixel près, surtout pour les marching square.

    Citation Envoyé par Kannagi Voir le message
    ou alors faire comme Sonic qui réutilisé des bloc de 256x256 pixel (divisé eux en meta-tile).
    Mario, Zelda et Metroid1 utilisaient la même technique, sauf qu'on appelle pas ça des "blocs" mais des "rooms". Ca permettait déconomiser de la ROM en faisant des bouts de maps répétées.

    Citation Envoyé par Kannagi Voir le message
    Bien sur de nos jours ça sert pas à grand chose ,avoir une map de 32ko , c'est pas génant , à l'époque un peu plus
    (Et puis de nos jours on peut avoir de gros buffer en mémoire ,donc faut mieux privilégier des compression du type LZ4)
    De tous temps on optimise la (V)RAM et depuis l'avènement des smartphones les vieilles techniques sont on ne peut plus d'actu.

    Citation Envoyé par Kannagi Voir le message
    Je préciserai juste qu'il y'a un excellent outils pour faire ces map : Tiled dispo ici : https://www.mapeditor.org/
    Je l'utilise sur tous mes jeux , et donc ça marche assez bien pour la SNES , Neo Geo et j'en passe
    Autrefois j'avais développé un éditeur de map du même style (malheureusement uniquement dispo en .exe) mais le modeling tile par tile là je peux plus, je suis vieux et fatigué. Si je me refarcis le dev d'un éditeur de maps ça sera conversion objet=>tiles + collisionmap. Mais pour l'instant je me débrouille très bien avec la méthode super-mario-bros, taper la liste d'objets à la main ça suffit...

    Citation Envoyé par Kannagi Voir le message
    Ce n'est pas parce que c'est plus simple de faire du scanline , où qu'il y'avait une logique du 1D , c'est même assez complexe , mais il était moins chère d'avoir un rendu par scanline que d'avoir un double frame buffer.
    Parce que oui les vielles consoles 8/16 bits avait un buffer , mais un line buffer ,du coup ça permettait d'avoir un rendu rapide (le line buffer était directement sur la puce graphique donc avec un accès rapide ) et donc au final de pouvoir afficher beaucoup de chose à l'écran ,bien plus qu'un PC de l'époque
    Heu ben oui c'est exactement ce que j'ai expliqué. Coder le rendu scanline buffer c'est loin d'être facile oui (mate mes sources pour voir comment j'en bave), mais à l'époque des vieilles consoles/bornes les dev n'avaient pas à s'en soucier puisque c'était déjà pré-programmé en assembleur embarqué dans les puces japonaises.

    Et dire que dans nos machines chinoises "modernes" on doit se taper les calculs nous-mêmes...

  5. #5
    Expert éminent
    Avatar de Kannagi
    Homme Profil pro
    cyber-paléontologue
    Inscrit en
    mai 2010
    Messages
    3 060
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 33
    Localisation : France, Bouches du Rhône (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : cyber-paléontologue

    Informations forums :
    Inscription : mai 2010
    Messages : 3 060
    Points : 9 584
    Points
    9 584
    Par défaut
    Citation Envoyé par Punk_Coders Voir le message
    J'ai lu la doc de la super-nes, les tiles 16*16 étaient gérées en hardware. Ca a permis aux devs de metroid3 de faire l'impasse sur l'algo du mirrored-scroll histoire d'économiser un max de CPU.
    Sinon les 32*32 je m'en suis servi aussi parce que les clients sont pas trop friands du style retro. Pas de contrainte particulière, faut toujours dessiner le raccord au pixel près, surtout pour les marching square.
    Oui mais tu parlais de la Nes , pas de la SNES !
    Oui je sais que la SNES fait du 16x16 vu que je le fais aussi sur mes jeux , mais c'est surtout pour économiser en VRAM.
    Cela économise certes du CPU mais pas tant que ça , j'avais fait du meta-tile sur PCE , et ça me prenais vraiment rien en %CPU.

    Citation Envoyé par Punk_Coders Voir le message
    De tous temps on optimise la (V)RAM et depuis l'avènement des smartphones les vieilles techniques sont on ne peut plus d'actu.
    Oui et non , on n'optimise mais peut être pas en utilisant tout à fait les mêmes techniques ,disons qu'il y'avait des technique des fois très spécifique a certaine machine (je pense principalement aux consoles 3D).
    Personnellement j'ai rarement optimisé sur smartphone pour les jeux que je faisais du moins.



    Citation Envoyé par Punk_Coders Voir le message
    Heu ben oui c'est exactement ce que j'ai expliqué. Coder le rendu scanline buffer c'est loin d'être facile oui (mate mes sources pour voir comment j'en bave), mais à l'époque des vieilles consoles/bornes les dev n'avaient pas à s'en soucier puisque c'était déjà pré-programmé en assembleur embarqué dans les puces japonaises.

    Et dire que dans nos machines chinoises "modernes" on doit se taper les calculs nous-mêmes...
    C'est un peu faux de dire que c'était préprogrammé en assembleur , c'était plus un genre du VLIW ou Verilog ancien
    Mais oui c'était gérer en hard donc voilà , il ne devait pas se soucier de ça (enfin oui et non , pas mal d'effet sont sur scanline) , mais il avait des contraintes CPU/RAM/ROM bien plus sévère par contre

  6. #6
    Inactif  
    Homme Profil pro
    Développeur multimédia
    Inscrit en
    février 2021
    Messages
    16
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Développeur multimédia
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : février 2021
    Messages : 16
    Points : 0
    Points
    0
    Par défaut
    Citation Envoyé par Kannagi Voir le message
    Personnellement j'ai rarement optimisé sur smartphone pour les jeux que je faisais du moins.
    Je suis d'accord. Le seul truc que j'ai optimisé sur smartphone c'est un shader de displacement-tile-mapping (histoire d'économiser deux additions... oui bon au pixel près ça compte...). Sinon le reste ça aurait été de l'optimisation de bout de chandelle avec des incidences totalement insignifiantes sur la consommation CPU, et qu'en prime ça aurait bloqué toute possibilité de faire du pattern cohérent et productif parce que je sais plus quel programmeur israélien il a écrit un truc du genre que premature optimization is the root of all evil dead.

    Citation Envoyé par Kannagi Voir le message
    C'est un peu faux de dire que c'était préprogrammé en assembleur , c'était plus un genre du VLIW ou Verilog ancien
    Mais oui c'était gérer en hard donc voilà , il ne devait pas se soucier de ça (enfin oui et non , pas mal d'effet sont sur scanline) , mais il avait des contraintes CPU/RAM/ROM bien plus sévère par contre
    Heu je te crois sur parole parce que je connais à peu près rien à ces trucs d'antiquaires.

Discussions similaires

  1. connaitre les bases qui existes
    Par nycagi dans le forum Administration
    Réponses: 13
    Dernier message: 08/06/2004, 12h29
  2. Les Bases de Données! tout un monde!!
    Par kikimnet dans le forum Bases de données
    Réponses: 3
    Dernier message: 29/04/2004, 18h26
  3. Lister les bases
    Par Neuromancien2 dans le forum PostgreSQL
    Réponses: 1
    Dernier message: 26/01/2004, 09h12
  4. Réponses: 1
    Dernier message: 01/08/2002, 21h09

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo