Discussion :

[mat.M]

Tu n'as pas besoin d'avoir recours à toute une "usine-a-gaz" 3d .
SDL suffit amplement; pour éviter les collisions il faut tester la collisation avec des pixels rouges du masque que tu as dessiné.
Ensuite pour donner l'effet de rétrecissement, prendre le plus bêtement du monde ....une succession de bitmaps ou le personnage est rendu de plus en plus petit .
Tu te casseras moins la tête

Pour la trajectoire on peut prendre l'algorithme de Bresenham

Ils ne sont pas dessinés à la main, ils sont modélisés en 3D et rendus dans une image.

Oui avec des softs de 3d comme 3dStudioMax par exemple

[orochimaru]

J'ai beau chercher je ne vois vraiment pas comme c'est possible de faire cela en 2D, dessiner 500 fois (une fois par taille) un sprite et ce dans toutes les positions possible je trouve ca mille fois plus lourd que de coder qqchose en 3D qui permet d'utiliser un modèle 3D de perso et c'est fini...

Il est vrai que cela résous le problème des collisions mais je viens de me rendre compte que c'est EXATEMENT la même chose qu'il faut faire en 3D

Et enfin, le plus gros problème qui est celui des objets du décors pouvant apparaitre devant ou derrière le perso selon sa position est toujours présent :/

Sinon, je vais essayer de me renseigner pour la modélisation de décors par 3DSmax ou autres parce que j'ai l'impression que c'est la seule solution.


Mais bizarrement, j’ai la sensation qu’il existe une méthode assez simple pour tout cela…..

[fearyourself]

Et enfin, le plus gros problème qui est celui des objets du décors pouvant apparaitre devant ou derrière le perso selon sa position est toujours présent :/

Personnellement, je ne trouve pas ce problème très complexe. En prenant un programme de dessin, j'ai pu modifier ton fichier de base pour donner ceci:


En gros, pour les collisions:

On regarde si les trois couleurs sont égales (on pourrait repasser par une couleur ne satisfaisant pas cette condition genre magenta pour toutes les autres zones...).

Donc si le sprite du joueur déborde sur une zone magenta alors il y a collision, il ne peut pas y aller...

Ensuite, tu remarqueras pour les lampadaires (c'est bien des lampadaires??) j'ai laisser le bas, pour justement faire une collision, par contre il faut pouvoir le dessiner.

Tout se fait en zone, sur cette image, j'ai mis 4 niveaux de gris donc 4 tailles de sprites, plus c'est clair, plus le joueur doit être grand (les images du joueur sont juste une différence de taille affichée, finalement le sprite a toujours la même taille en mémoire, sauf si on veut faire des dessins optimisés pour chaque taille possible, mais on ne ferait jamais pour chaque taille plutôt quelques tailles qu'on rétrécit ou agrandit comme il faut...).

Pour afficher correctement toute l'image, on a l'image de fond, le joueur et 3 objets (2 lampadaires et le truc centrale).

Maintenant pour ce qui est de l'affichage, on veut que si le joueur est derrière un objet, l'objet soit afficher devant le joueur.

Comment savoir si le joueur est derrière? Est-ce que la position sur l'image suffit?

Dans ce genre d'image, oui. Puisque plus on est en bas de l'écran, plus on est proche du joueur, il suffit de classer les positions des objets dans l'ordre haut vers bas.

Du coup, si le joueur est tout en haut de l'écran, il sera dessiner d'abord, s'il est entre les deux lampadaires, un des lampadaires sera dessiner avant et l'autre après, ...

Comment faire pour savoir la position des différentes objets? Ben ça faudra un fichier qui te donne toute l'info de la scéne, que t'auras besoin de toute façon pour ton jeu. Tu auras donc dans ce fichier l'image de fond, l'image de fond colorier comme j'ai fait pour la taille et le nombre, positions et noms des fichiers des images à mettre en plus...

Cela doit se faire en pas très longtemps quand même, non?

Jc

[Sivrît]

Avec un sprite j'utiliserais un bon zoom façon Monkey Island (si c'était bon pour mon Amiga 500 ça le sera pour un pentium) suivant une fonction affine de Y (ou plutôt son inverse pour que la fonction donne la distance à la caméra). Le sol étant généralement plat ça doit faire l'affaire. Pour les cas compliqués il faudra plusieus zones (et une fonction par zone en faisant attention aux raccords) car on ne rapetisse pas en montant une échelle

Pour l'ordre on peut donner une distance à chaque élément et afficher dans l'ordre (ou passer par un Z Buffer si on est un openGL) en insérant le personnage grâce à la distance donnée par fonction affine de Y.

Et pour reprendre fearyourself on peut définir plusieurs niveaux de détails du sprite associés à des plages de distances. Ou alors garder cette technique avec un personnage en 3D mais utiliser un modèle 3D (et ses animations) me semble bien plus complexe.


Cela dit ça ne vaudra pas la rolls qui a été mentionnée : Faire les décors en 3D et exporter le Z Buffer (après l'affichage est facile et propre) et même une partie du modèle pour faire évoluer les personnages dans un univers 3D (mais simplifié, limité à des formes simples) totalement cohérent avec les images précalculées. Comme ça pas de problème de priorité ou de positionnement approximatif (à mon sens le principal apport de Resident Evil par rapport à Alone In The Dark).

[Clad3]

Moi qui m'était toujours posé la question du fonctionnement de ce genre de décors Voila qui m'éclaire !

En fait c'est bien pensé la modélisation 3D permet surtout de récupéré simplement les zone accesibbles et la poisition en Z , ca facilite quand même grandement les choses . Je suis pas sur qu'une méthode a la main ( genre redéfinir soit meme comme il a été fait ya quelques poste en plusieur niveau de gris le "Z-buffer" soit très judicieux. Ca risque d'être long et fastidieux au final . Je prèfere personnelement encore quelquechose basé sur des tiles à ce niveau , mais cela n'engage que moi
Bonne chance !

[orochimaru]

Bon, j'ai essayé de faire qqchose entierement en 2D avec la SDL, et j'obtient ceci:
http://poypoy.charly.free.fr/divers/...20map%202d.zip
(la source est fourni mais c'est fait à l'arrache :p)

->Je n'ai mis que 3 tailles possibles pour le perso mais ca donne déjà une idée.
->Le perso doit normalement être animé mais ce n'est pas utile pour un exemple.

Comme vous pouvez le constater, le tout fonctionne à peu près mais c'est extrêmement chiant et laborieux de créer une image pour chaque objets de la scène
De plus, il est inconcevable de créer des sprites pour tous les points de vues possibles (bah oui, le décor est en plongée mais il pourrait très bien être en contre-plongée)
Enfin, La vitesse de déplacement du perso devrait être lente quand il est loin et rapide quand il est près.

Il vaut donc mieux, a mon avis, continuer sur l'idée de la 3D pour le perso mais dans ce cas il faudrait définir le point de fuite du perso ce que je ne sais pas faire (si qqn connait la fonction OpenGL...)

[fearyourself]

Comme vous pouvez le constater, le tout fonctionne à peu près mais c'est extrêmement chiant et laborieux de créer une image pour chaque objets de la scène

C'est clair, on a jamais dit qu'il le faudrait vraiment. Ce qu'il faut faire c'est avoir l'idée et dire "comment automatiser ou combiner le plus possible?"

La grande question est: comment vas-tu obtenir tes images?

Si un artiste peut les faire avec un programme 3D alors il pourra sûrement sortir toutes les infos dont tu as besoin pour gérer correctement la scéne, il suffira de mettre en place une boîte noire qui interpréte toutes les données de la scéne et en extrait ce que tu veux.

Si tu chopes des images toutes faites, alors tu devras quand même faire ce genre de travail mais je pense que tu peux te faciliter la vie. En coloriant l'image une fois tu devrais arriver à générer lors de l'exécution du programme l'image finale.

Je m'explique ,

Tu utilises déjà la couleur (255,0,0) pour les collisions.
En ajoutant quelques codes couleurs pour les plans, tu peux colorier tous les pixels qui doivent se trouver sur les différents plans.

Avec quelques conventions, je pense que tu dois pouvoir colorier l'image de façon à extraire correctement toute l'info pour directement dessiner ton image...

De nouveau, je conseillerais de prendre le magenta, c'est la couleur la plus utilisée pour ce genre de chose.

Ensuite, lors du lancement du programme, il suffira de générer les surfarces des différents plans en utilisant l'image de base et l'image masque construit...

De plus, il est inconcevable de créer des sprites pour tous les points de vues possibles (bah oui, le décor est en plongée mais il pourrait très bien être en contre-plongée)

Cela dépend des artistes et de ce qui est possible, si tu as des images comme celle-ci tu peux garder les persos en 3D et la vue en 2D, cela ne posera pas de problème.

Enfin, La vitesse de déplacement du perso devrait être lente quand il est loin et rapide quand il est près.

Ca c'est une question d'implémentation.

Jc

[TheToune]

Salut,

sans vouloir vous offenser je croit que vous etes tous a côté de la plaque ...
Vous devez tellement vous prendre la tête sur des problemes plus compliqué que vous en oubliez d'etre simple.

Il n'y a tous simplement aucune diference entre un jeu 3d aux plan fixes precalculé (alone in the dark, resident evil, final fantasy) et un jeu 3d classique sauf que la camera est fixe et le rendu du decor et le depth buffer stocké dans une image plutôt que recalculé a chaque fois.
En memoire on utilise une version ultra simplifié pour les test de colisions et les projections d'ombre.

- on fixe la camera a une position predeterminé.
- Au lieu de rendre les polygone du decor, on utilise le rendu et le depth buffer precalculé correspondant a la position de la camera.
- On rend normalement comme dans n'importe quel moteur 3d les objets dynamique restant.

Par contre bon courage pour placer la 3d sur du dessin existant, ca risque d'etre difficile. Il vaut mieux déja creer la 3d de base du decor, placer la camera et le faire le rendu ou le dessin aprés.

[fearyourself]

- on fixe la camera a une position predeterminé.
- Au lieu de rendre les polygone du decor, on utilise le rendu et le depth buffer precalculé correspondant a la position de la camera.
- On rend normalement comme dans n'importe quel moteur 3d les objets dynamique restant.

Faut-il encore l'avoir...

Je suis d'accord mais je n'ai toujours pas compris si le PO a un système pour faire une scéne en 3D et faire le rendu.

Donc en partant d'une image 2D, finalement tu propose de faire ce que je dis:

- Précalculer le depth buffer

Ce qui se fait donc à la main -> ce qui sera chiant

Mais sans la génération de la scéne 3D je ne vois pas comment faire mieux...

Jc

[Sivrît]

Il n'y a tous simplement aucune diference entre un jeu 3d aux plan fixes precalculé (alone in the dark, resident evil, final fantasy) et un jeu 3d classique sauf que la camera est fixe et le rendu du decor et le depth buffer stocké dans une image plutôt que recalculé a chaque fois.

On est tous d'accord, c'est super mais si tout n'est pas généré à la source c'est tendu... Et refaire un environnement 3D à la mano est lourd et approximatif (ce qui rendait la visée très délicate dans Alone In The Dark).

Ensuite le rendu 3d est équivalent à du temps réel grâce au Z Buffer... sauf que Alone in the Dark, Resident Evil et Final Fantasy n'en avaient, le premier pour cause de 386 (sans commentaire) et les autre parce que la playstation n'en avait pas (c'était la première génération de console 3d après tout). Et ils se débrouillaient donc en découpant le fond en morceaux.

orochimaru> Si tu veux faire du réaliste tout en prenant des angles de vue originaux, ça va être difficile de couper à la 3d (ou alors un sprite vu suivant différents niveaux d'inclinaison - genre 4 ou 5 - plus un zoom temps réel, approximatif mais ça peut rendre, c'est un style).

Pour la 3D je vois deux gestions possibles :
- Comme en 2d mais avec un personnage en 3D pour avoir un zoom trivial et pouvoir changer l'angle de vue. Ca sera un peu tordu sur les paramètres 3d à utiliser mais pas d'environnement 3d à gérer.
- De la vrai 3d. Dans ce cas il faut modéliser l'environnement, au minimum définir le sol sur lequel se déplace le personnage dans un repère en 3d, avec des rectangles par exemple. A la louche à partir de l'image ça sera délicat et il faudra pas mal tâtonner. Ensuite il faut faire coïncider la vue openGL avec celle du rendu du fond (bref trouver les bonne coordonnées pour gluLookAt). Et il restera à donner des profondeurs aux éléments du décor (genre le lampadaire à 3.789 ), ou à mettre en place un ordre d'affichage.

Hum, bon courrage ?

[fearyourself]

Effectivement.

Finalement, il faudrait probablement recentrer la discussion avec la question suivante:

- Quelles sont tes possibilités pour générer les images de fond?

- As-tu l'occasion de générer à partir de scéne 3D ou non?

Jc

[orochimaru]

Pour générer des images de fond, c'est dessin + retouche avec Gimp.

Pour faire des scènes en 3D, je connait les bases de Blender mais c'est tout, je ne l'ai jamais vraiment utilisé serieusement mais je croit que je vais m'y mettre si cela me permet de produire un décors avec des informations pour le Z-buffer (d'ailleur si qqn sait comment faire pour exporter ces données et les reutiliser...).

Mais ce qui me fait douter de cette technique, est que certaines scènes de jeux ressemblent vraiment à des dessins, peut etre que ceux-ci on juste subi une retouche sous un logiciel de modeling pour créer les fameuses inforations du Z-buffer...

[Laurent Gomila]

Mais ce qui me fait douter de cette technique, est que certaines scènes de jeux ressemblent vraiment à des dessins

On peut faire beaucoup de choses avec un modeleur 3D
Et puis j'imagine qu'on peut toujours générer le Z-Buffer avec une scène approximative, et retoucher la scène 3D à la main ensuite pour la rendre plus jolie.

[orochimaru]

mmmm....
Et Monkey island, c'etait des décors générés en 3D aussi ? Parceque ca date...
un petit lien pour ceux qui ne connaissent pas: http://www.64bits.se/guider/scummvm/...land_kejoe.png

[BanZaiii]

Ah, ça je sais, il sont fait en 2d pixel art.

Et pour la taille du personnage, il réduit de tant de % en fonction de la profondeur que tu auras defini dans la scène. Et pour les objets devants derriere et bien, c'est juste une question de selection de zones "de marche" et de "premier plan" sur ton dessin... et le personnage marchera devant ou passera derriere.

En gros c'est que de la 2d, sauf pour monkey island 3 ou les décors on été fait en 3d pour la base.


edit: Arff, j'avais pas vu, je sais pas comment j'ai atteri ici mais je viens de le detterer...dsl...

[orochimaru]

Donc c'est comme le petit programme que j'ai fait.

C'est un boulot monstre pour les infographistes de faire un jeu comme ca !
Cela signifie de découper chaques scenes en autant de plans que nécéssaire, et un sprite par point de fuite...

c'est beaucoup trop pour moi et en plus ce n'est pas l'effet exact que je désire obtenir, je prefere le perso en 3d
Mais j'ai toujours le probleme pour le décors :/

[BanZaiii]

Non, pas du tout tu n'est pas forcé de faire ainsi.
D'ailleurs j'ai recemment découvert un petit programme gratuit qui te permet de creer ton propre jeu d'aventure façon monkey island, bon bien sûr c'est à toi de fournir les ressources mais il suffit tout bettement de créer un décor avec ton logiciel graphique préferé ou tes petits doigts et de créer simplement un jeu de sprites pour chacun de tes personnages (à toi de voir la fluidité que tu veux).
Une fois que t'as tout tes éléments le logiciel te permet de tout mettre en place ton décor, ton personnage, les objets... donc en trèès peu de programmation.
Par exemple, tu as un arbre mais la route passe derriere et ton personnage ne marche que sur la route; et bien tu définie une selection englobant ta route, puis tu définis une autre selection qui suit les contours de l'arbre en lui indiquant que "l'arbre est devant la route".
A ce moment lorsque ton personnage marche sur la route celui ci disparaitra en passant derriere et réapparaitra de l'autre coté...
Par contre ce logiciel à des limites. Si tu veux plus d'infos :
http://adventuregamestudio.fr-bb.com/index.forum

[orochimaru]

Oui j'ai déja eu vent de ce logiciel, mais le probleme c'est que ce n'est pas du point&click que je veux faire mais un rpg donc je ne sait pas si l'on peut avec (combats aléatoires, inventaire, points de sauvegarde...)
Mais je vais aller me renseigner sur comment fonctionne le moteur de l'editeur, je pourrais surment l'adapter a mes besoins par la suite