Est-ce que vous pouvez dire sur quoi vous travailler en ce moment.
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
vos projets
Est-ce que vous pouvez dire sur quoi vous travailler en ce moment.
pour ma part, je travaille sur un mini mmorpg
j'en suis à la conception de l'éditeur de carte pour mon moteur 2D.
mais ça avance pas vite, j'ai plus beaucoup de temps pour prog
Moi, je fais un shoot'em up(mais ca avance pas tres vite:-(
Il est fait en C++ et DirectX 8. Tout en 3D, vaisseau, ennemis et decor.
Il est vu de dessus (je suis un fan des vieux shoot d'arcade)
Pour l'instant, j'ai fait :
-la gestion du vaisseau (mouvement et tir)
-la gestion des ennemis
-la detection des collisions
-le tile rendering engine pour le decor
en ce moment je suis en train d'implementer des zolis explosions.
voila! Je crois bien que je n'en verrai jamais le bout!
bin je vois pas pourquoi, t'est quand même vachement bien avancé dans ton jeu !voila! Je crois bien que je n'en verrai jamais le bout!
moi me manque :
- les décors
- l'histoire
- le système de jeu
- l'interface client/serveur
- le serveur
- le client
- euh tout en fait lol
j'ai déjà mis au point mon moteur 2D, c'est déjà pas malje pourrais m'en resservir pour faire n'importe quel jeu vu de dessus ou de 3/4
il faudrait juste que je finisse l'éditeur de niveau, mais c'est assez complexe.... donc moi je ne pense jamais pouvoir finir mon projet !!!!
J'ai dit ca parce que mon plus gros probleme, ce n'est pas la prog mais la conception des decors, des vaisseaus, tout ce qui est game design quoi!
[quote="Shakram"]Salut! Y'aura pas moyen d'avoir les sources de ce fameux moteur 2Dj'ai déjà mis au point mon moteur 2D, c'est déjà pas mal
projet !!!!
moi ca m'intéresserait d'avoir un .exe demo de ton moteur, Shakram.
bin en ce moment je suis en pleine restructuration de mon moteur 2D!
mais je n'ai pas beaucoup de temps pour m'y consacrer
bon il est simple et voici comment je l'ai fait :
--- un tableau de tiles à trois dimensions :
- tile 'carré' de dimension 8, 16, 32, 64, 128 ou 256 pixels de côté
- la troisième dimension permet de gérer la profondeur
--- deux listes pour chaque niveau (hauteur) :
- une pour afficher les images fixes
- l'autre pour les images animés (images dont la position peut varier, comme une image d'un personnage)
les deux listes sont ordonnées selon Y puis X de l'image selon son coin en haut à gauche
--- méthode d'affichage :
- on trie toutes les images animées qu'on va ranger par niveau et par position
- on parcours chaque niveau entre deux niveaux donnés, du plus bas au plus haut
- pour chaque niveau, on affiche d'abord les tiles, puis les images fixes et enfin les images animés
sinon pour les codes sources, je les mettrai à disposition une fois que je serai satisfait du résultat
pour la démo, j'en aurai une à te proposer mais elle date et ça ne montre pas grand chose ! juste le déplacement des tiles , gestion du niveau et affichage d'une image par dessus les tiles
de + je dois encore l'améliorer, par exemple pour éviter d'afficher un tile non visible....
voilà, j'espère que ça en aidera certains....
quelle différence fais-tu entre tiles et images ?
pourquoi fais-tu une distinction entre image fixe et image animée, (une image fixe pouvant etre vue comme une image animée ne comportant qu'une seule frame) ?
- les tiles sont rangés dans un tableau et sont de taille fixe.quelle différence fais-tu entre tiles et images ?
cela permet de ne pas avoir besoin de les ranger, donc l'affichage est rapide et la gestion aisée.
le défaut est qu'on ne peut pas placer une image n'importe où.
- les images sont de tailles variables.
c'est le contraire des tiles :
on peut les placer n'importe où, sauf que l'affichage et la gestion sont moins aisés.
j'ai peut être été pas assez clair quand j'ai dis " images animés (images dont la position peut varier, comme une image d'un personnage)pourquoi fais-tu une distinction entre image fixe et image animée, (une image fixe pouvant etre vue comme une image animée ne comportant qu'une seule frame) ?
"
quand je parlais d'image fixe, je veux dire qu'elle ne changera pas de position ! par exemple un arbre dans le décor, il ne bougera pas !
ainsi, toutes ces images sont stockées dans une liste ordonnée qui ne sera pas rearrangé à chaque affichage)
pour les images animés, je parlais des images 'mouvantes', tel un personnage qui se déplace sur la carte !
je dois à chaque affichage réordonner la liste des images pour prendre en compte le déplacement.
cela est couteux d'ordonner une liste, d'où la distinction entre ces deux types d'images !
je n'ai pas trouvé de terme approprié pour 'images animés', j'espère que là j'ai été clair
ok j'ai tout bien compris...
pour le réordonnancement des listes aussi je penses, meme si je n'aurais pas opté pour un système basé sur des listes (justement pour éviter de réordonnancer)
tu aurais utilisé quoi alors?
Code : Sélectionner tout - Visualiser dans une fenêtre à part meme si je n'aurais pas opté pour un système basé sur des listes (justement pour éviter de réordonnancer)
pour être plus précis j'utilise la STL avec sa classe SET je crois, qui permet d'ordonner à l'ajout.
j'ai effectivement une liste qui stocke toutes les images 'animés', mais au moment d'afficher, je ne range dans le SET que les images visibles à l'écran.
j'aimerai trouver une méthode + efficace mais pour l'instant, je n'ai rien trouver de mieux
une map qui stocke toutes les images susceptibles d'etre utilisées (a chaque image est associé un identifiant qui permet de la retrouver)
un tableau à trois dimension dont chaque case contient un pointeur vers l'image à afficher, ce pointeur étant obtenu à partir de l'identifiant lors du chargement.
puis on lance l'affichage sur le tableau en trois dimension.
les déplacements sont géré en modifiant l'offset de l'image associé à une case.
tu as donc un tableau d'images, qui fonctionne apparemment comme mon tableau de tiles.un tableau à trois dimension dont chaque case contient un pointeur vers l'image à afficher, ce pointeur étant obtenu à partir de l'identifiant lors du chargement.
dans mon moteur, je n'ai pas encore prévu comment seront chargés les images, c'est au programmeur de se charger d'affecter lui même les images au tableau.
là j'aimerai que tu détailles car j'ai pas très bien compris comment tu gérais ton déplacement.puis on lance l'affichage sur le tableau en trois dimension.
les déplacements sont géré en modifiant l'offset de l'image associé à une case.
en fait ce serait au programmeur de la couche du dessus de gérer le changer l'offset de l'image par rapport au X et Y associé à la case, jusqu'au moment ou l'image est rattaché à l'autre case, à ce moment son offset devient 0, 0.
je crois commencer à comprendre ta méthode, mais c'est encore un petit flou...en fait ce serait au programmeur de la couche du dessus de gérer le changer l'offset de l'image par rapport au X et Y associé à la case, jusqu'au moment ou l'image est rattaché à l'autre case, à ce moment son offset devient 0, 0.
chaque case contienne une ou plusieures images?
et qu'est-ce exactement le offset? la valeur est stockée où?
une case est définie par 3 coordonnées (x, y, z) z la hauteur
la valeur de l'offset serait stocké dans la case.
Je mets au conditionnel, car c'est juste comme moi je le ferai, ce n'est pas quelque chose qui est déjà implémenté.
ok, mais tu gère comment la superposition des images qui se trouvent au même niveau?
et il faut aussi prendre en compte la charge mémoire. les tiles permettent de juste devoir stocker un pointeur vers l'image, c'est pourquoi j'ai séparé les images immobiles et mouvantes, car les premières ne nécessitent pas de stocker des informations liées au mouvement.
la première approche de mon moteur faisait qu'une carte test prenait 25 Mo de mémoire pour l'afficher, sans compter la charge mémoire des bitmaps.
après avoir changé l'approche, je suis redescendu à mois de 2 Mo, cependant avec une rectriction sur le mouvement. c'est pourquoi j'ai crée une liste pour ces images afin de compenser la perte.
de toute façon le mieux pour se rendre compte des difficultés est de commencer à coder le moteur !
il n'y a jamais deux images sur la meme case, la superposition se fait à l'aide des niveauxEnvoyé par Shakram
tu peux te le permettre ca ne devrait pas prendre pas trop de place en plus, je penseset il faut aussi prendre en compte la charge mémoire. les tiles permettent de juste devoir stocker un pointeur vers l'image, c'est pourquoi j'ai séparé les images immobiles et mouvantes, car les premières ne nécessitent pas de stocker des informations liées au mouvement.
avec mon systeme ca prend en gros : m*x*y*z*sizeof(int) + n*(taille d'une image);la première approche de mon moteur faisait qu'une carte test prenait 25 Mo de mémoire pour l'afficher, sans compter la charge mémoire des bitmaps.
après avoir changé l'approche, je suis redescendu à mois de 2 Mo, cependant avec une rectriction sur le mouvement. c'est pourquoi j'ai crée une liste pour ces images afin de compenser la perte.
m étant le nombre d'informations associées à la case
n le nombre d'images susceptibles d'etre utilisées
apres il faut équilibrer... mais ca ne sera pas au programmeur de décider
vrai, mais j'en ai deja codé un auparavantde toute façon le mieux pour se rendre compte des difficultés est de commencer à coder le moteur ! :)
Un coup de MFC AppWizard , un projet SDI par ex. , un CSplitter , d'un côté une CFormView ( ou CTreeView ) et de l'autre une CView , rien de plus facile !!il faudrait juste que je finisse l'éditeur de niveau, mais c'est assez complexe....
L'éditeur dans un jeu est la première chose que l'on développe , en parallèle avec le moteur de jeu
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager