Discussion :

[norwy]

Quelqu'un connais les principes du Mode7 (des algo simples) ? Je voudrais un effet similaire à F-Zero/Mario Kart/FF avec une librairie similaire à DirectDraw.

Mon ami Google me renvoit vers des implémentations assembleurs optimisées depuis 5 ans pour des émulateurs SNES-GBA.

[Sivrît]

Ben pour faire du PC avec directX ou équivalent, pourquoi ne pas directement passer à Direct3D (ou openGL) ? Avec ça cet effet devient limite trivial.

En plus maintenant que directX passe par les circuits 3D même pour la 2D c'est peut-être faisable avec DirectDraw.

[Laurent Gomila]

Qu'est-ce que le Mode7 :

[Mandalar]

Je crois que le mode7 est une technique de programmation utilisée à l'époque sur console ne gérant pas du tout la 3D (sur super nes nottament) dans le but de faire des effets 3D (zooms) ou meme des jeux 3D. Voila une image trouvée sur google (de mario kart) :
http://ds.advancedmn.com/images/cont...creenShot2.jpg

Cela dit je me demande l'utilité d'une telle technique à présent, surtout que ca devait pas forcément etre tres simple... meme si je vois pas trop en quoi ca consiste (coté algorithmes)

[Sivrît]

Plus qu'une technique de programmation, le mode 7 correspondait à un circuit de la super NES. Il a beaucoup contribué à son succès car c'est (était ?) un effet impressionnant.

En gros c'est un roto-zoom avec en plus un effet de perspective, le tout géré en hardware. Idéal pour le sol de Mario Kart et F-Zero, ou encore les cartes du monde de nombreux jeux de rôles.

Maintenant, avec les cartes 3D c'est dépassé puisqu'on a mieux (avec interpolation, mip maping et tout 8) ).

Mais que de bons souvenirs

[norwy]

C'est exactement ça.

J'ai parle d'une librairie similaire à DirectDraw donc pas de DirectX et Direct3D je ne veux pas faire de 3D mais bel et bien implémenter un effet "Mode7". la cible est un PDA.

Il y aurait donc un composant hardware traitant le Mode7 dans la SNES ? Intéressant,

Mais moi ce qui m'intéresse, c'est le principe et les algo, je pourrais alors l'appliquer à mon application.

Où si vous avez une autre idée d'implémentation de fausse 3D (uniquement pour le sol ou plus si affinité ^^), je suis toujours preneur...

[Sivrît]

Ah forcément... Si on reparlait de ce code assembleur ? C'est que faute de circuit 3d ou dédié ça va être plus délicat. Pour la SNES y'a pas photo, elle faisait pas ça au processeur Mais toute machine qui peut sortir doom ne doit pas avoir de problème.

Je ne suis pas un expert sur les PDA (ni sur le mode7 d'ailleurs ) mais je pense qu'utiliser une lib 3d (n'importe laquelle du moment qu'elle sort des poly mappés en soft) reste le plus simple.

C'est quoi ton objectif ? Coder Mario Kart à la dure à partir d'une lib 100% 2d ? Trouver une lib qui fait le maximum du travail pour toi ?

Pour le refaire à la main, il faudrait regarder un tutorial sur la 3d (j'en avais un bien faudrait que je le retrouve) puisque la déformation à appliquer est somme toute la même que pour un triangle texturé. En se limitant à nos karts ça devrait pouvoir beaucoup se simplifier. Car la vue est fixe...

Dans l'idée on veut prendre une image 2d et la plaquer sur un plan incliné. Ca supose un parcourt de l'écran pour placer à chaque fois la couleur du point correspondant de l'image d'origine, bref un mapping pur forme.

Je devrais pouvoir sortir les formules en cogitant un peu dessus (diable ! que ces bêtises sont amusantes ! )

[norwy]

La librairie est déjà fixée, je souhaite simplement ajouter un effet de pseudo 3D sur du sol (qui semble plus simple que de passer par une librairie 3D tierce qu'il faudrait de toute façon linker avec ma librairie 2D principale.

Comment parvenir à un rendu 3D-pseudo3D de de tile (tuiles 2D) avec une librairie 2D ?

Le proc du PDA cible est d'environs 400Mhz donc je pense que c'est faisable sans assembleur.

[Sivrît]

Je ne vois pas trop ce que l'on peut tirer d'une lib 2d dans un cas comme celui-ci... Elle risque de se limiter à fournir un moyen rapide de placer des pixels un par un, et encore il vaudra peut-être lieux travailler sans elle. Si quelqu'un a une idée là dessus je suis curieux.

Pour les formules ça va tenir de la 3d en soft. Prenons un repère orthonormé direct (et tout le tralala) dont l'axe des z est l'altitude orienté vers le haut. On considère un point P(x,y,z) qui dans ce cas est un sommet de notre tile au sol (donc z=0).

On place la vue en (x0,y0,z0). Pour se ramener dans le repère de cette vue on a :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
x'=x-x0
y'=y-y0
z'=z-z0=-z0

Pour orienter la vue, disons que l'on regarde suivant l'axe Y dans un repère (X,Y,Z) obtenu par une rotation d'angle alpha suivant z. Les coordonnées deviennent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
X= x'*cos(alpha) + y'*sin(alpha)
Y=-x'*sin(alpha) + y'*cos(alpha)
Z=z'=-z0

On pourrait rajouter ici d'autres rotations (suivant X pour modifier l'angle de vue du sol, ou Y pour se pencher dans les virages) mais je laisse ça de côté pour simplifier.

Enfin, les coordonnées (u,v) à l'écran (attention, l'origine est au centre de l'écran ! Ne pas oublier de corriger dans l'implémentation) s'obtiennent grâce à Thalès :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
u=a*X/Y
v=a*Z/Y

"a" correspond à la distance entre le point de vue et "l'écran", ce qui s'interprète un peu comme la distance focale d'un objectif. On peut le différencier pour u et v.

Avec ça on peut placer la tile à l'écran. Il faut ensuite parcourir tous les pixels qu'elle recouvre (si il y en a). Les coordonnées d'origine (les sommets de la tile) sont à interpoler afin, pour chaque pixel à l'écran, d'aller y chercher la couleur à placer. En première approche l'interpolation peut être linéaire, mais pour un bon rendu il faut un peu plus que ça.

En variante, il serait possible (je ne sais pas si on y gagne vraiment) de faire un rendu 2d normal dans un tampon puis de tout plaquer d'un coup à l'écran pour limiter les calculs 3d.

J'espère que ça t'aidera (et aussi avoir été compréhensible).

[norwy]

Ouah, voilà exactement le genre de réponse que j'attend.

Je m'explique, implémenter des fonctionnalités 3D ou pseudo 3D à l'aide d'une librairie 2D dans un jeu n'est absolument pas fantaisiste.

Le but ici est donc d'arriver à implémenter cette technique avec une optimisation suffisante pour rester dans de bonnes conditions de jeu.

Ce que je veux, c'est arriver à quelque chose de jouable très rapidement, Mode7 ou OpenGL, même combat mais pas même temps d'implémentation au regard de mon contexte de développement...


Merci beaucoup pour ta réponse, je vais essayer de suite de comprendre et d'implémenter ça. J'ai cependant une autre question, comment gérer au mieux l'organisation de mes tiles pour ce rendu ?

[Sivrît]

Je viens de trouver ça: http://en.wikipedia.org/wiki/Mode_7
J'aurais peut-être du commencer par là.

Donc le mode 7 est une astuce très intéressante et bien maline. Finalement mes calculs mènent à peu près au mème résultat mais moins facilement, et avec un peu de perte sur la projection et surtout un remplissage moins facile à implémenter. Par contre ils offrent plus de possibilités.

Si tu ne veux pas un sol trop fin et/ou que tu as assez de ram ça me semble mieux.

Pour ce qui est de l'organisation des tiles j'en sais pas grand chose... Eviter de les faire trop petites pour limiter le nombre de sommets et calculer une seule fois les sommets communs à plusieurs... Après peut-être les afficher par type au cas où la tile tiendrait dans le cache du processeur mais je suis sceptique. Je pense que ce qui importera le plus sera de loin d'être efficace sur la fonction de remplissage. J'étais tenté de suggérer un affichage 256 couleurs mais en plaçant les points 1 par 1 avec un processeur 32 bits ça va rien changer.

[mat.M]

norwy si tu veux faire de la pseudo 3d pourquoi ne pas prendre SDL ou LibCon pour commencer ?

[norwy]

Bon, bon, un ptit résumé s'impose:
je souhaite implémenter de la pseudo3D dans un jeu 2D (avec un librairie 2D donc) et qui puis est est déjà très avancé donc la question de changer de librairie n'est pas d'actualité.
Petites informations:
- Le jeu est destiné à tourner principalement sur PocketPC (mais fonctionne sur Palm aussi).
- Le rendu Mode7 viendrait remplacer une vue 2D des tiles donc convient très bien tout en s'intégrant dans la librairie puisque 2D... ça agrémente la vue sans en faire des tonnes avec de la 3D plus lourde à implémenter (et sans doute plus gourmande).
- Dans mon cas, vous n'avez qu'a voir le PDA comme une GBA qui ne pourrait pas faire de véritable 3D (même si ce n'est pas le cas mais puisque la librarie est déjà prise et que ce n'est pas essentiel...)

- Pas de Linux (on sait jamais...)
- Pas d'OpenGL
- Pas de DirectX
- Pas de moteur3D usine à gaz
- Juste du Mode7

Merci

Sinon, Sivrît, je m'y suis pas encore mis, ça arrive...

[mat.M]

Poir Pocket PC et PDA il faut obligatoirement prendre des SDK pour ces plateformes.
Il doit y avoir des émulateurs sous Windows.
Je doute qu'il yait des bibliothèques, sinon elles sont payantes évidemment.
Va voir sur sourceforge.net ou gamedev.net

[norwy]

Le sujet porte uniquement ici sur l'implémentation du mode 7 en software évolué (exit donc l'assembleur), et les réponses que j'attend ne sont qu'algorithmiques et conceptuelles, je tacherais de faire le reste...

[mat.M]

Pour à l'effet pseudo3d comme dans Mario Kart le plus simple c'est d'afficher des bitmaps à l'écran.
Je déconseille les transformations avec trigo ça risque de faire perdre du temps au processeur

[norwy]

Si tu as besoin de questions spécifiques d'algoritmes poser la question dans le forum Algorithmes

Toute l'ambiguité est là. Développement de jeux ou simple algo ? Je pense que ce topic a parfaitement sa place ici...

Lorsque je dit:

l'implémentation du mode 7 en software évolué (exit donc l'assembleur)

Je parle d'une implémentation logicielle à l'aide de langage plus évolués que l'assembleur (et non pas proches du hardware cf. composant de la SNES) tels que C, C++, etc. C'est pourtant simple non ?
Et puis la dite méthode peut être ainsi implémentée partout dans les conditions pour être utilisée par tous ceux qui le souhaitent. Sur un sujet comme celui-ci où il existe relativement peu de doc (moi je n'ai pas trouvé mon bonheur), ce serait sympa d'avoir une réponse claire pour tout le monde.

Le Mode7 est une technique encore utilisée il y a très peu de temps notamment sur GBA car elle convient parfaitement lorsqu'il y a des contraintes de performances et que le niveau de graphisme requis n'est pas très élevé, cela donne un effet plutôt sympa pour certaines personnes qu'on pourrait qualifier de "old school". L'implémenter sur PDA est tout à fait légitime de même que sur téléphone mobile qui ne sont pas des plateformes anciennes. Tout dépend de l'effet que l'on veut donner.



Sivrît... ça arrive...

[mat1eu]

salut a tous.........
Je connais pas trop l'algo pour le mode 7 mais ce que je peux dire c que l'on prend une image 2D et qu'on la decoupe en plusieurs lamelles

Par contre le code pour arriver a ce resultat connais pas, j'ai trouve une exemple mais c en actionscript du logiciel flash......Pas tres convaincant?????
Exemple en flash

voici un autre exemple : Exemple 2

[mat1eu]

bon ben je vois que c complique le mode 7 car personne ne post plus ici !!!
je pense que c bien meiux comme ca surtout quand on a directX ou opengl
@ plus
mat1eu

[norwy]

Mais non, ne t'inquiète pas on ira à fond dans le sujet.

DirectX ou OpenGL ne peuvent pas s'appliquer dans ce cas (même si des versions portables de ces librairies débarquent sur PDA).
Regarde dans tes démonstrations flash, le procédé est appliqué en quelques lignes de code (- de 50) pour un résultat certes inférieur à de la vraie 3D mais déjà bien jouable. Dans ces (mes) conditions, le rapport fun / ligne de codes est incomparable à un moteur 3D... et c tout l'intérêt de la chose.

Mais puisque tu remets (entre autre) DirectX sur le tapis, as-tu des idées sur la façon de sélectionner/charger une lamelle en biais sur une Surface (=image). Ma librairie qui se comporte comme DirectDraw, peut charger des portions rectangulaires (des lamelles droites quoi) mais pas des lamelles en biais.
Le code flash est assez démonstratif de la simplicité du procédé mais cette histoire de lamelle paraît être implicite/transparente dans le flash...

Résumé de la Question :
Comment séléctionner une lamelle/rectangle en biais avec DirectDraw ?
(Il me semble que le problème peut s'appliquer également à SDL, non ?)