Discussion :

[flasheur]

je voudrais connaitre la bonne technique pour avoir un rendu tile-base propre sur les cartes vidéo modernes

en SDL par exemple

je sais qu'au final on doit avoir tout le contenu de l'écran rendu sur une texture unique, afin d'avoir un floutage des pixels propre quelque soit la résolution, comme le font les émulateurs de vieilles consoles

ce qui m'intéresse c'est ce qui se passe avant, quelle est la meilleure manière de faire du blitting dans cette texture... est-ce mieux de le faire bêtement avec le processeur, comme les émulateurs, afin d'avoir une liberté totale au niveau du moteur graphique (quitte à sacrifier les perfs), ou y'a-t-il moyen de le faire plus rapidement en faisant du blitting hardware qu'on balance ensuite dans la texture?

[Invité]

Déjà je suis pas sur d'avoir compris la question, alors dans cette réponse je vais supposer que quand tu dis "tile-based" c'est que tu as un monde en 2D tilé que tu veux rendre rapidement (à la RPG).
Et non-pas que tu veux séparer ton frame-buffer en plusieurs "tiles" histoire de contourner des limitations de taille des render-to-texture sur téléphone.

je voudrais connaitre la bonne technique pour avoir un rendu tile-base propre sur les cartes vidéo modernes

en SDL par exemple

je sais qu'au final on doit avoir tout le contenu de l'écran rendu sur une texture unique, afin d'avoir un floutage des pixels propre quelque soit la résolution, comme le font les émulateurs de vieilles consoles

Si tu veux être indépendant de la résolution en 2D, à mon avis il faut
- des tiles/sprites avec suffisamment de pixels, les émulateurs trichent avec hq2x etc
- un bon resampling : j'entends lanzcos4 pour un agrandissement, lanzcos3 ou bicubique pour une réduction. Faire un lanzcos rapidement c'est pas évident, du coup je pense que tu devrais precalc tes tiles à la bonne résolution une fois que tu connais la connait parce que au moment du blit ça va pas le faire.

ce qui m'intéresse c'est ce qui se passe avant, quelle est la meilleure manière de faire du blitting dans cette texture... est-ce mieux de le faire bêtement avec le processeur, comme les émulateurs, afin d'avoir une liberté totale au niveau du moteur graphique (quitte à sacrifier les perfs),

ou y'a-t-il moyen de le faire plus rapidement en faisant du blitting hardware qu'on balance ensuite dans la texture?

Le problème pour moi c'est que le blit software est lent et que le filtrage hardware est flou.

D'où mon avis :

- si le joueur ne peux pas zoomer : tu précalc les tiles à la bonne taille en soft, tu les upload sur GPU dans une texture atlas ou là il seront blittés rapidement avec un filtre type "nearest".

- si le joueur peut zoomer : alors là il faut choisir entre la peste ou le cholera, c'est soit les filtres trilinéaires flous, soit tu fixe la résolution, soit tu fais tout sur CPU... Améliorer le filtre de la carte graphique avec un shader c'est possible mais c'est pas mal lent.

Bon j'espère que quelque part je répond à une partie de la question. Note: j'ai jamais fait ce dont je parle.

(EDIT: je viens de me rappeler qu'iq a un trick pour améliorer le filtrage bilinéaire sur carte graphique http://www.iquilezles.org/www/articl...re/texture.htm, par contre pas sur que ça marche quand il y a des mipmaps)

[flasheur]

houlà... heu..

non ce que je cherche à faire est beaucoup plus simple, je veux avoir le même rendu que sur les émulateurs, sur une texture que tu peux stretcher à la taille de l'écran (avec par exemple un filtrage hq2x au final) donc mon "pseudo écran" qui est balancé dans la texture filtrée a une résolution constante avec rendu interne sans aucun filtrage, avec des gfx "pixelart" prévus pour cette résolution (je vais peut-être pas choisir 256*224 comme les emulateurs ça ferait un peu trop rétro, disons une résolution 640*480 par exemple)

bon bref, pour simplifier ma question, mettons que je fasse un rendu pixel-perfect sans aucun filtrage dans une petite fenêtre 640*480. (ce qui se passe après je me débrouille)

c'est à propos de ce qui se passe dans cette petite fenêtre que porte ma question en fait: est-il possible de reproduire la mécanique des consoles à tuiles ?
les tutos SDL que j'ai vu sur le rendu tuiles, dans la mémoire vidéo on balance une texture unique qui contient toutes les tuiles et ensuite on les rend à l'écran avec un crop.
je ne veux pas utiliser ça car ça n'a rien à voir avec la mécanique des consoles 2d (1): la vram contenait un tileset fait d'une grosse liste d'images distinctes, une image par tuile, et y'en avait beaucoup, plusieurs centaines (et l'animation des tuiles se faisait à cet endroit là avec des switch d'adresses). je ne sais pas si la carte vidéo d'un p.c. est prévue pour gérer rapidement ce genre de trucs, grosso modo avoir plusieurs centaines de mini textures (de 8*8, 16*16 ou 32*32 pix par exemple).
si les cartes vidéo des pc sont pas prévues pour gérer une tonne de mini-textures dans ce cas vaut mieux que je laisse tomber mon blitting hardware et que je fasse un rendu software comme les émulateurs


donc là à vue de nez je dirais qu'il faut passer par du rendu software comme les émulateurs, comme ça je fais ce que je veux, c'est plus facile à porter et c'est pas une vieille résolution de 640*480 qui va tuer un cpu d'aujourd'hui (les machines d'il y'a 10 ans savaient déjà rendre de la 3d software fluide avec cette résolution alors bon)... voilà... mais je veux quand même vérifier que je fais pas une bêtise en me privant du rendu gpu

(1) d'ailleurs ce bricolage foireux n'a rien à voir non plus avec le fonctionnement d'un moteur 3d propre...

[Kannagi]

Moi je dis ça au cas ou et d’après mon expérience personnel, mais le mieux pour la SDL c'est du 320x240 , le 640x480 elle le supporte bien (sans bouffer trop de CPU) , m'enfin a 50 fps c'est limite (enfin sur mon ordi) .
Apres rien t’empêche de faire un x2 de ton écran (soit avec SDL_gfx soit avec opengl).
Apres le mieux c'est de gérer les tileset avec la SDL.

Mais tu peux le faire avec opengl (je suis pas un spécialiste ).
Mais tu peux mettre les image dans la mémoire vidéo avec glGenTeextures,glBindTexture.
C'est possible de faire un 'croc' avec l'opengl , on donnant les bonne valeur a glTexCoord2f(x,y);

[LittleWhite]

Bonjour,

Je dois dire que je ne comprends pas grand chose.
Tout de meme, je conseillerai d'utiliser la SFML qui de base a du scale de mapping et qui permet aussi de faire des post process facilement. De plus, contrairement a la SDL 1.2 ... la SFML utilise le materiel.

EDIT par rapport a Kannagi: Je crois avoir vu la SDL tournant rapidement avec du 800x600 mais il ne faut pas avoir de transparence, ou mettre les surfaces sources au meme format que l'ecran. Mais sinon, la SDL n'ayant pas d'acceleration materielle (sous Windows avec DirectDraw ... peut etre) c'est "normal" que cela rame). Bref, il y a tout de meme des methodes pour avoir des trucs fluides avec la SDL.

[Invité]

je ne veux pas utiliser ça car ça n'a rien à voir avec la mécanique des consoles 2d (1): la vram contenait un tileset fait d'une grosse liste d'images distinctes, une image par tuile, et y'en avait beaucoup, plusieurs centaines (et l'animation des tuiles se faisait à cet endroit là avec des switch d'adresses). je ne sais pas si la carte vidéo d'un p.c. est prévue pour gérer rapidement ce genre de trucs, grosso modo avoir plusieurs centaines de mini textures (de 8*8, 16*16 ou 32*32 pix par exemple).
si les cartes vidéo des pc sont pas prévues pour gérer une tonne de mini-textures dans ce cas vaut mieux que je laisse tomber mon blitting hardware et que je fasse un rendu software comme les émulateurs

Les cartes vidéo c'est un peu comme sur les consoles, tu peux pas sélectionner plus de (disons) 16 textures différentes. Donc en OpenGL on switche de texture et ça peut prendre un peu de temps. Du coup on cherche généralement à limiter le nombre de textures et le nombre de switch.

EDIT: d'où mon avis, reste en software surtout pour du pixel-perfect en 640x480

[flasheur]

ponce >

c'est pas vrai du tout ça, c'est le nombre d'appel de shaders qu'il faut limiter

les plus vieux moteurs 3d hardware (mettons celui d'half life) ça pouvait déjà rendre une tonne de textures différentes pour le décor, mais c'était toujours le même shader qui les rendait

quand aux vieilles consoles à tuiles ça raisonnait avec une logique du genre une tuile = une texture (mais un shader unique pour toute la machine... enfin, à vrai dire, pas de shader du tout) et la mémoire vidéo stockait plusieurs centaines voir plusieurs milliers de tile

peut-être bien qu'en fait le coeur de la mécanique il est dans la manière dont on code le shader

ptêt bien que là où ça coince c'est quand on bosse à partir de shaders tout faits et tout pourraves pour démomaking


enfin j'en sais rien je suis pas un spécialiste...

mais comme tu dis je vais me contenter de blitting software

[Mat.M]

je ne comprends pas ce que tu veux faire.
Si tu veux faire un jeu 2d avec des tuiles à base d'images, il est préférable de charger une grosse bitmap dans la carte vidéo et après faire une découpe des animations ou des éléments du décor.
Avec Direct3d tu peux prendre un D3DXSPrite ou bien un quad vertex et un vertex buffer.

Sinon avec DX11 il ya maintenant Direct 2D

[Invité]

@flasheur, ok PC != console mais un truc est sur tu pourras pas rendre 10000 textures différentes dans la même frame sans faire de tilesets
Ton shader peut pas sampler plus de 8/16 texture d'un coup du coup si tu as trop de tiles différent tu te retrouve a devoir faire plus de drawcall, et puis les states changes des textures units sont pas gratuits non plus.
(EDIT: en fait ce que tu voudrais c'est les textures arrays mais ça faut une carte SM4)

[flasheur]

Mat.M > c'est justement ce que je veux pas faire. pour avoir essayé cette technique j'ai pu voir qu'elle bloque plein de trucs car elle empêche de reproduire la mécanique des consoles 2d

ponce > wep voilà. donc je vais me rabattre sur un rendu software comme les émulateurs

bien j'ai eu la réponse à me question je coche résolu, merci ponce et les autres

[iliak]

Salut,

Voici comment je fais en OpenGL :

- Tu as une "grande" texture qui contient toutes tes tiles. 1024x1024x32 me semble raisonnable. Une seule texture te permet d'éviter de changer de texture constamment.

- Tu créées un vertex buffer qui va permettre de faire un maillage (horizontal) pour afficher ta map. Tu définis ce maillage à la taille de tes tiles. Donc si tu veux une map de 800x600, ça va te donner un grille de 25x32 si tes tiles font 32x32. Il est important que ce maillage soit bien uni. Comme le montre le "line_strip" sur l'image :

Tu as ainsi un plan que tu affiches en mode orthogonal devant la caméra.


Pour ce qui est du filtrage, utilise du "Render To Texture". Tu peux redimensionner à ta guise pour faire un effet de "zoom in" ou "zoom out" et tu as la possibilité de donner des effets en appliquant un shader.