Discussion :

[Punk_Coders]

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.

[Punk_Coders]

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).

[Kannagi]

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

[Punk_Coders]

[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.

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.

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.

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...

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...

[Kannagi]

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.

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.

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

[Punk_Coders]

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.

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.