Discussion :

[LittleWhite]

Bonjour à tous,

Voilà, j'arrive avec un nouveau projet. Ici je vais reprendre le principe de fearyourself avec son projet, soit je vais expliquer à peu de chose près, mon avancement et mon code ( vu que ce n'est pas sur qu'il soit documenté ( bouh! ) ).

Je vais faire ( et j'ai commencé ) un remake de Advance Wars ( qui est sorti sur GameBoy Advance et sur Nintendo DS ) ou encore, pour les plus vieux d'entre nous, une reprise de Famicon Wars ( qui était donc sorti sur Famicon ).
(Pour les gens qui n'aiment pas la wikipédia ) C'est un jeu de stratégie, au tour par tour qui se joue sur une sorte de plateau ( carte ). On peut avoir jusqu'à 4 adversaires. Chaque tour, nous gagnons des revenus, nous pouvons déployer des unités, déplacer nos unités, attaquer, capturer des usines et autres batiments ( qui donne des revenus, permet de fabriquer des unités, ou même de gagner ). Chaque joueur à un QG. Si celui ci est capturé par l'adversaire, nous perdons. Si nous n'avons plus d'unités sur la carte, nous perdons ( Dans certain cas, si un nombre de tours est dépacé nous perdons ).
Sur certaines cartes il peut il avoir un brouillard de guerre.

- Pourquoi ce jeu?

Simplement car c'est un jeu que j'ai beaucoup aimé et que je voulais faire un projet de jeu vidéo avant la rentrée scolaire .
De plus, il me semble qu'il n'y ai pas beaucoup de monde ayant voulu le faire ( seul projet notable: customwars ).
Pourquoi le refaire... au lieu d'aider un projet courant ... c'est qu'il utilise JAVA ( que je ne critique pas ) que je maitrise moins bien, de plus cela bloque la compatibilité avec les plateformes que je cible.

Donc vous avez compris, ce projet utilise le C++

- Bibliothèques utilisées?

Je vais utiliser la SDL car celle-ci est extrèmement portable ( récemment j'ai recontré un codeur, codant sur AmigaOS ).
En fait, j'ai longtemps hésité, car je voulais apprendre la SFML , qui est très certainement une très bonne bibliothèque ( le créateur est présent sur ce forum, donc je ne peux pas dire de bétises ). Mais comme je l'ai dit, c'est pour garder une extrème portabilité ( que beaucoup de projet ne cherchent pas et n'ont certainement pas besoin ). La deuxième raison est aussi que je veux porter sur GP2X ( une console portable ) et que c'est surement sur cette bête que je vais bosser l'année prochaine ( durant mon année scolaire ).
( On remarquera que chercher à travailler sur de telle bêtes n'est que purement théorique, effectivement, un code C++ écrit correctement est portable ( tant que l'on n'utilise pas des fonctions de la bibliothèque de Windows ), les seuls problèmes qui peut arriver ( les problèmes de compilation avec des compilateurs plus strictes ne sont pas pris en compte, car normalement réctifiables très rapidement ) sont les erreurs de segmentation et les fuites de mémoires. Effectivement, sur nos systèmes surpuissant, le système d'exploitation n'est pas toujours regardant et peu laisser passer quelques erreurs ( et puis nous avons pleins de mémoire vive ( n'est ce pas? ) ). Sur des systèmes tel que l'AmigaOS et celui de GP2X, une fuite de mémoire ou une erreur de segmentation peut arriver à freezer complètement le système ( l'utilisateur va vite me détester si je laisse de telles erreurs ).

Donc:

SDL -> gestion clavier / souris , ouverture de la fenêtre , affichage
SDL_image -> Chargement des images et affichage grace au core de la SDL
SDL_mixer -> Chargements des sons / jouer les sons
SDL_network -> Ah bon! Il y aura du réseau ( pour l'instant ce n'est pas une priorité )

OpenGL. Hum, oui je n'ai pas encore parlé d'OpenGL. En fait, tout est faisable avec la SDL ( vu que nous faisons que de la 2D ). Mais l'avantage d'OpenGL, c'est que c'est directement géré par la carte graphique, donc c'est plus rapide. Je vais essayer ( en fait, je n'ai pas encore d'idée pour le faire correctement ) de gérer le dessin à l'aide de la SDL, ou d'OpenGL ( mais tout avec un seul et unique code à part les routines de dessin, bien sur ).

- Outils?

Clavier, souris, écran ...
Plus sérieusement, actuellement j'utilise Visual Studio 2008.
Sous linux, c'est gcc, make et geany pour l'éditeur.
J'utiliserai aussi doxygen pour générer la documentation.
Et finalement, pour faire une compilation multi plateforme avec peu d'embêtement, je vais utilisé autotool/automake qui est un outil sous linux pour généré un script configure qui lui générera des Makefile dépendant de votre configuration.

- Licence?

Le code source est complètement ouvert et protégé par la licence GPLv2.

- Autre?

Mon projet ( et surtout son code source ) est stocké sur google code.
Il n'y a pas de raison particulière opur avoir choisi google code, juste que mon précédent projet est aussi stocké là bas.
J'utilise SVN ( SubVersion ) pour la gestion des versions ( ça, c'est parce que j'ai l'habitude d'utiliser celui là ).

- Premier design

Sortons une feuille blanche.
Mon premier design est loin d'être parfait, mais donne un premier aperçu et surtout une première direction vers quoi aller.
Les classes de prévues:

Engine:
- Window ( ouverture de la fenêtre ... )
- Renderer ( il devra géré OpenGL et SDL de façon indépendante, du coup il aura les fonctions de base du genre 'drawBackground' 'drawTile' )
- Camera ( pour les cartes plus grandes que la taille de l'écran ... permet donc le déplacement de la carte )
- Sprite
- Animation ( c'est une série de sprite que l'on change selon le temps )
Game:
- Map ( il faudra la charger à partir d'un fichier , la dessiner , ou dessiner un aperçu )
- Cursor ( peut être dans l'engine, c'est un jeu console, donc il y a un curseur )
- Player ( avec une liste d'unité )
Units:
- Unit ( une classe mère, qui défini des actions de base ( dessin / déplacement ) )
- UnitFactory ( une fabriques d'unités )
- Building ( pour les batiments, à peu de chose près le même principe que les unités )
- BuildingFactory ( une fabrique de batiments )
ResourcesManager:
- SpriteManager ( on passe le nom d'un fichier, cela nous retourne un pointeur sur les données du fichier, une fois chargée )
- SoundsManager ( pareil pour les sons )


Les managers sont importants pour la mémoire. Ils permettent de faire un chargement au tout début du jeu, de toute les ressources, et de ne pas utiliser la mémoire plein de fois pour la même chose ( on charge une seule fois chaque fichier )
Les Factory sont aussi importantes car elle vont lire les fichiers décrivants les caractéristiques des unités, et juste en passant le nom de l'unité, nous aurons une nouvelle instance de creer.

Cela permet de faire une meilleure gestion de la mémoire et de tout libérer facilement.

- Notes de codage

Les noms des variables pointeurs sont précédés par un 'p'.

Cela peut ressembler à la notation hongroise, mais c'est le seul point que je reprends de toute la notation.

Les variables doivent toutes être initialisées à la déclaration ( avec 0 ou NULL, bien souvent ). Cela évite toujours des erreurs ( du moins on les remarques mieux ).

Voilà, pour un premier aperçu, je pense avoir dit pas mal de chose, donc maintenant, codons!

[pierreyoda]

Excellent, je me suis justement lancé dans un projet similaire il y a peu

A la différence que mon futur projet est prévu pour être modulaire, "moddable" et scriptable (en Lua), et qu'il ne vise pas vraiment à recréer AW (dont je suis fan ), mais s'en inspire clairement.
Pour information, c'est du C++, j'utilise la SFML et boost.

Enfin, bonne chance à toi

[LittleWhite]

Je me demande si je ne suis pas passer à coté avant de savoir su le projet existait déjà.

Il faut dire que LUA me tente vraiment, même si je ne me suis jamais penché dessus.
On va déjà faire en sorte que la carte s'affiche

Bonne chance à vous aussi

[GR3lh442kR]

Je suis moi aussi en train de code un moteur de jeu 2D avec LUA, et je confirme, c'est surpuissant! Je trouve que ça simplifie tout, le contenu des map, les actions faites par le joueur, chargement des niveau et menus, actions des boutons ect... bref tout ce qui est en rapport avec le contenu du jeu. je te conseille donc de t'y intéresser!

[pierreyoda]

Enfin, "existant", c'est vite dit...

D'autant que ma formule de "tout modulable" (tiles, unités...) je dois coder toute la partie "database" avant même de toucher à la partie graphique (la partie "game" faisant le pont entre les deux)

Pour en revenir à Lua, oui c'est vraiment énorme, et pour l'embedded (on exécute un scipt depuis le programme C++) 100x mieux que Python. Je n'y suis pas vraiment arrivé avec boost::python, qui ne fournit rien du tout pour cette partie, alors qu'avec luabind c'est ultra-simple (même si maintenant que je comprend mieux la façon de faire des interpréteurs je pourrais me dépatouiller avec boost::python).
Le seul avantage décisif de Python, c'est le support par défaut de l'unicode (là je vais être obligé de sortir Qt pour traduire facilement...)

[LittleWhite]

Il faut donc que je m'y penche sérieusement.

Par contre, pensez vous que c'est compatible GP2X et AmigaOS , LUA?

------

Voici le deuxième épisode du développement de OpenAWars.

Qu'avons nous de nouveau?

Une Window peut:

- Ouvrir une fenêtre ( de taille que l'on veut, pleine écran ou pas, opengl ou pas )
- Réouvrir une fenêtre
- Récupérer les résolutions disponibles
- Récupérer la largeur de la fenêtre
- Récupérer la hauteur de la fenêtre
- Récupérer le nombre de bits par pixel

Il y a une fonction interne pour généré les flags que nous allons utilisé pour ouvrir la fenêtre ( entre autre pour le plein écran et OpenGL ).
J'ai fait une fonction de ce genre, pour éviter à répété plusieurs fois le même code. Il est important d'éviter les copier coller ( source d'erreur trop fréquentes ).
Les tests sont les suivants:

- Nous testons si nous avons la possibilité d'avoir une surface du coté matériel.
- Nous testons si l'utilisateur veut le plein écran
- Nous testons si nous avons un gestionnaire de fenêtre, qui dit gestionnaire de fenêtre, dit possibilité d'avoir une fenêtre, donc si nous n'en avons pas, nous mettons en plein écran.
- Finalement, si nous voulons OpenGL, nous ajoutons le flag pour OpenGL. Mais nous définissons aussi le double buffering dans OpenGL

Le fonction de réouverture de la fenêtre à une particularité, celle ci doit fermer complètement SDL pour pouvoir réouvrir une autre ( sans perte de mémoire ). Effectivement, dans la documentation, il est dit que la surface renvoyé par SDL_SetVideo() ne doit pas être désallouer manuellement.

La fonction pour récupérer les résolutions est juste composer d'une boucle testant les resolutions une à une et retournant une liste contenant les résolutions valides. Une première optimisation est de sauter les nombres impaires car nous n'avons pas de résolutions impaires. Bien sur je pourrais faire mieux. Le test se fait que avec les flags de pleine écran, car en mode fenêtré toutes les résolutions sont acceptables.
Cette fonction est importante pour les menus du jeu , laissant la liberté au joueur de changer la résolution.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
void Window :: getResolutionsAvailable(const bool isOpenGL, std::vector<ResolutionInfo>& riList)const
{
	Uint32 flags = this->getFlags(true,isOpenGL);
	int bpp = 0;
 
	std::cout << "Window :: getResolutionsAvailable (" << isOpenGL << ")" << std::endl;
 
	for ( unsigned int w = 2 ; w <= 1280 ; w+=2 )
		for ( unsigned int h = 2 ; h <= 768 ; h+=2 )
		{
			if ( (bpp = SDL_VideoModeOK(w, h, 32, flags)) != 0 )
			{
				ResolutionInfo ri(w,h,bpp);
 
				std::cout << "Test (" << w << "x" << h << "x" << bpp << ") Passed" << std::endl;
 
				riList.push_back(ri);
			}
		}
}

J'ai passé le std::vector par référence, car j'ai pensé que si je le renvoyer ( avec un return ) j'allais faire une copie supplémentaire de la liste.

On peut remarquer l'utilisation des assertions ( assert() ), très pratiques pour notamment repéré rapidement des cas non attendus. De plus, les assertions ne sont pas présentes en Release.

Comme vous pouvez le remarquer j'affiche tout un tas de messages, entre autre à chaque fois que je rentre dans une fonction. Pour cette raison, la prochaine étape est de faire un logguer que l'on pourra désactiver dans la Release.

[LittleWhite]

Bonjour,

Enfin, une mise à jour.

Je suis un peu pressé par le temps donc le commentaire va être assez court.
J'ai mis à jour le moteur (Engine) du jeu, et en faisant cela, j'ai déplacé la moitié du code du moteur de l'éditeur dans une classe Engine, qui est donc hérité par l'éditeur et le jeu.
Cela va me permettre de commencer à faire le jeu en lui même (car j'ai une idée de comment implémenter la logique (enfin)).
Pour ce faire, je vais travailler sur ma toute nouvelle classe GameEngine (qui gardera un enum state, pour indiquer l'état actuel du jeu)
J'expliquerai en détail comment le jeu va s'organiser, un peu plus tard

[LittleWhite]

Bonjour à tous,

Enfin une vraie, une grande, une importante, une très moche, mis à jour.
(Ceci dit, je suis toujours à la recherche d'un artiste)

Aujourd'hui j'ai rajouté assez d'éléments pour produire des unités, coté jeu.

Cette ajout, m'a fait ajouté une nouvelle classe dans la partie IU. Je n'en parlerai pas vraiment, car elle n'a rien d'exceptionnelle (juste du code qui charge les éléments, qui les place et qui les affiche) ... tout le monde connait maintenant

Par contre, j'ai changé un peu la structure du GameEngine afin que celui ci contienne son état (Visualisation / Construction / selection unité)
Comme cela, je sais si je dois afficher me curseur, ou mon tout nouveau IU.

Dernière chose, j'ai ajouté une nouvelle ligne dans le fichier qui paramètres les unités, maintenant il a la forme suivante:

# File to set the values for each unit.
# Here the list of parameters:
#
# ID of the Unit
# name_of_the_unit
# name_of_the_sprite_to_load
# size_x size_w (of one sprite in the animation)
# time (time between two sprites)
# category (Land = 1 ; Navy = 2 ; Air = 4)
# target_category (Node = 0 ; Land = 1 ; Navy = 2 ; Air = 4)
# movement
# fuel
# fuelConsumption
# ammo
# max_life
# price

Voilà tout, vous avez de belles images à contempler

[fearyourself]

Excellent, cela commence à avancer ;-) doucement mais ca avance !

Jc

[LittleWhite]

Petite mise à jour, maintenant si nous n'avons pas assez d'argent les unités sont grisé (je me suis battu avec la SDL juste pour ça, et c'est pas encore parfait )

(Note: Du coup, j'ai rajouté une fonction dans le renderer qui prend un couleur de masque (enfin, dans le principe ))
(Voir capture)

[LittleWhite]

Nouvelle mis à jour miniature.

J'ai amélioré mon code, notamment pour faire le masque. Maintenant je garde une partie des couleurs.
L'astuce est de faire un premier dessin de l'image, puis après, l'image avec le masque.
Voyez le résultat en image

Sinon j'ai aussi un peu déplacé les éléments dans la boite de construction et je l'ai rétréci (le fichier, et on voit que mon programme fonctionne pas mal, car je n'ai rien eu à modifier pour supporter le rétrécissement)

[LittleWhite]

Bonjour,

Aujourd'hui j'ai démarré Linux. Ce n'est pas au hasard que je dis ça :p.
J'ai fais quelques petits changements (sur l'éditeur principalement, vu que je n'ai pas de Makefile Linux pour le jeu ). Tout d'abord il a fallu que je mette à jour le fichier de base qui sert à la génération du Makefile, car il manquait deux règles (une pour le nouveau LineParser, et l'autre pour l'Engine (la classe mère)).
Une fois cela fait, j'ai pu corrigé les warnings. Il n'y en a plus aucun \o/

Deuxièmement, j'ai remarqué que le fichier classic.oawts (le fichier tileset) est dans un format pur windows, et du coup, il ne chargeait plus rien correctement.
J'en profite pour faire la petite correction du LineParser:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
bool LineParser :: isEmptyLine()
{
	for(std::string::const_iterator itChar = line.begin() ; itChar != line.end() ; ++itChar )
	{
		if ( *itChar != ' ' && *itChar != '\r' )
			return false;
	}
 
	return true;
}

Mais finalement, le problème est corrigé en utilisant l'outil fromdos (dans le paquet 'tofrodos') qui anciennement s'appeler dos2unix.

Après, j'ai travaillé sur les fuites de mémoire (vive valgrind).
Il y en avait une dans le EditorEngine, car j'oubliais de libérer la camera

Et c'était la seule \o/
Le reste semble venir de la SDL

==7365== Searching for pointers to 1,337 not-freed blocks
==7365== Checked 1,966,800 bytes
==7365==
^[==7365== 34 bytes in 2 blocks are definitely lost in loss record 24 of 143
==7365== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==7365== by 0x8780A8B: ??? (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x8780D52: _XimSetICValueData (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x8779A86: _XimLocalCreateIC (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x875DAA2: XCreateIC (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x5292AD3: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365== by 0x5293A53: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365== by 0x5282828: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365== by 0x52590DA: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365== by 0x525911E: SDL_Init (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365== by 0x4290B7: main (main_editor.cpp:170)
==7365==
==7365== 192 (16 direct, 176 indirect) bytes in 1 blocks are definitely lost in loss record 111 of 143
==7365== at 0x4C275A2: realloc (vg_replace_malloc.c:525)
==7365== by 0x8763812: ??? (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x87645AA: ??? (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x8765522: ??? (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x8765C65: _XlcCreateLC (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x8784A5F: _XlcDefaultLoader (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x876DB22: _XOpenLC (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x876DC07: _XlcCurrentLC (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x876E1CD: XSetLocaleModifiers (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x5292DB3: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365== by 0x5293A53: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365== by 0x5282828: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365==
==7365== 8,176 bytes in 1 blocks are possibly lost in loss record 140 of 143
==7365== at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==7365== by 0x8745109: ??? (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x8745627: _XrmInternalStringToQuark (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x874BF7D: XStringToKeysym (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x877C7F9: _XimParseStringFile (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x877A964: _XimLocalOpenIM (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x87791E5: _XimOpenIM (in /usr/lib/libX11.so.6.3.0)
==7365== by 0x5292E1B: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365== by 0x5293A53: ??? (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365== by 0x5282828: SDL_VideoInit (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365== by 0x52590DA: SDL_InitSubSystem (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365== by 0x525911E: SDL_Init (in /usr/lib/libSDL-1.2.so.0.11.3)
==7365==
==7365== LEAK SUMMARY:
==7365== definitely lost: 50 bytes in 3 blocks
==7365== indirectly lost: 176 bytes in 4 blocks
==7365== possibly lost: 8,176 bytes in 1 blocks
==7365== still reachable: 119,688 bytes in 1,329 blocks
==7365== suppressed: 0 bytes in 0 blocks
==7365== Reachable blocks (those to which a pointer was found) are not shown.
==7365== To see them, rerun with: --leak-check=full --show-reachable=yes
==7365==
==7365== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 19 from 8)
--7365--
--7365-- used_suppression: 12 X on SUSE11 writev uninit padding
--7365-- used_suppression: 5 dl-hack3-cond-1
--7365-- used_suppression: 2 glibc-2.5.x-on-SUSE-10.2-(PPC)-2a
==7365==
==7365== ERROR SUMMARY: 3 errors from 3 contexts (suppressed: 19 from 8)

En fait, l'éditeur ne fait aucune (semble t'il) allocation lorsque il est en fonctionnement Cela aide à éviter les fuites, n'est ce pas .

Voilà pour aujourd'hui.

[fearyourself]

C'est bizarre ta fuite de la SDL, je suis presque sûr que je ne l'ai pas. Tu fais bien un SDL_Quit à la fin de ton programme, toujours ?

Sinon , je crois qu'il va falloir que je fasse une passe pour virer les miennes ;-)

Jc

[Aspic]

Ton projet a vraiment l'air très prometteur, en plus j'adore Advance Wars

Et puis je vois que tu as utilisé un logiciel pour les fuites de mémoire, dommage que cela ne fonctionne que sous Linux

Bonne continuation

[LittleWhite]

C'est bizarre ta fuite de la SDL, je suis presque sûr que je ne l'ai pas
Jc

Alors là ... je suis prêt à faire un pari

Et, oui je passe bien sur le SDL_Quit :p

Ton projet a vraiment l'air très prometteur, en plus j'adore Advance Wars

Et puis je vois que tu as utilisé un logiciel pour les fuites de mémoire, dommage que cela ne fonctionne que sous Linux

Bonne continuation

Il existe des trucs sous windows (même si je ne suis pas fan) et une méthode avec Visual Studio (qui est nulle comparé à valgrind).
Sinon, pour votre cas, cela va pouvoir s'arranger car Allegro est portable et puis votre code aussi

[LittleWhite]

Bonsoir,

Enfin une nouvelle mis à jours
J'ai ajouté des boites de menus, pour laisser l'utilisateur quitter le jeu.
Pour l'instant, les boites sont vaguement intégrées dans le jeu, mais la classe est totalement prête
Vous avez en récompense de votre attente une image
(Le code ne montre absolument rien de particulier, j'ai repris le même système qui tout mes autres UI)
Sachez que la boite fonctionne parfaitement pour une intégration direct dans la machine à états du GameEngine (et à long terme de l'EditeurEngine)

[fearyourself]

Excellent boulot , moi je serai intéressé par le code quand même, quelques [ code ] quand même ?

Jc

[LittleWhite]

C'est malin.

Alors voici le code de la nouvelle boite:
http://code.google.com/p/openawars/s...s/UI/MenuBox.h
http://code.google.com/p/openawars/s...UI/MenuBox.cpp

Nah!

Sinon pour l'intégration dans le GameEngine:
- Ajout d'un nouveau etat (enumérateur)
- Ajout de la construction de la boite:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
// Prepare the data to put in the Construction Box for the Port
        std::vector<MenuView> menuEntries;
        {
                menuEntries.push_back(MenuView("End turn",ME_EndTurn,new AnimatedSprite(*pSM,GFX_PATH "endTurnIcon.png",32,32,200,true)));
                menuEntries.push_back(MenuView("Quit",ME_Quit,NULL));
        }
        pMBMenu = new MenuBox(*pSM,*pFM,*pWin, GFX_PATH "constCursor.png","./data/fonts/times.ttf",menuEntries);
        if ( pMBMenu->getValid() == false )
        {
                return false;
        }

- Ajout de l'appel à la fonction de dessin (selon l'état):

Code :

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

1
2
3
4
5
6
 
case GS_MENU:
{
    pMBMenu->draw(*pRenderer,pC->getPosition(),pVT->getTime());
}
break;

- Ajout de l'appel à la fonction d'update (selon l'état):

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
case GS_MENU:
{
		pMBMenu->update(pKB->getDirectionPressed());
		if ( pKB->isKey(SDLK_SPACE) )
		{
				// Check what is in 
				// pMBMenu->getActualEntry();
		}
		else if ( pKB->isKey(SDLK_z) )
		{
				this->gState = GS_VISU;
		}
}
break;

- Et on n'oubliera pas, le point d'entrée qui ouvre la boite (aller dans l'état):

Code :

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

1
2
3
4
5
6
7
8
 
/*
else if ( ) = UNIT
*/
else
{
		this->gState = GS_MENU;
}

[fearyourself]

Pour ta gestion du clavier, j'ai une tendance à faire un truc qui reviens en haut ou en bas.

Donc un

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
 
void MenuBox ::update(const ArrowsDirection kd)
{
        switch (kd)
        {
                case AD_DOWN:
                        if ( actualPosition < entries.size()-1 )
                        {
                                actualPosition++;
                        }
                        else
                        {
                                actualPosition = 0;
                        }
                        break;
                case AD_UP:
                        if ( actualPosition > 0 )
                        {
                                actualPosition--;
                        }
                        else
                        {
                                actualPosition = entries.size () - 1;
                        }
                        break;
                default:
                        break;
        }
}

Sinon ca m'a pas l'air mal du tout.

Jc

[LittleWhite]

Bonjour,

Enfin une mis à jour.
Tout d'abord, si vous allez voir la page de mon projet sur google code, vous pouvez voir qu'il y a un bug de rapporter (le secret, c'est que c'est moi qui me suit reporter un bug )

Maintenant la mis à jour.
Le but de celle-ci est d'intégré l'affichage des unités activé et inactive (en utilisant le même système de filtre que dans l'interface utilisateur pour la construction d'une nouvelle unité).

Ce qui a été fait:
Nouveau design, qui demande l'intégration d'une nouvelle structure pour les unités (qui s'appelle Unit). J'explique, avant j'avais bien des unit, mais celles-ci intégrer les paramètres que je chargeais dans le fichier (paramètres de base). Maintenant, cette ancienne classe Unit s'appelle UnitTemplate, et à complètement remplacé Unit. Elle garde donc les informations 'à la création' des unités (celles chargées par les fichier, ex: 10/10 de vie)
Le nouveau Unit, contient les informations logiques des unités dans le jeu.

Voilà la première partie.

Pourquoi un tel changement, simplement car je voulais garder mon système leger de un sprite par type d'unité (sprite maintenant contenu dans UnitTemplate donc).
Du coup, la Map et l'unit set contienne des UnitTemplate.

Mais, il fallait tout de même que j'implémente les unité (informations logiques). Mais je ne voulais absolument as que l'éditeur y ai accès (cela aurait apporter plus de complexité).
Du coup, la Map est devenue une classe abstraite (les méthodes pures, sont celles pour le dessin, et une pour placer une unité).
Cette classe est toujours hérité par MapEditor, mais maintenant aussi par MapGame qui implémente donc une carte d'unité logique.

Voilà.

Il y a eu une méthode en plus, dans la classe Map, qui est protégée, pour dessiner le terrain.
Les méthodes draw() des classes hérités appellent celle-ci puis affiche les unités.
(Cela fait certes, deux parcours deux tableaux, au lieu d'un, mais je n'ai pas trouvé de méilleures méthode).

Voilà.

Niveau code, très peu de changement, ce n'était qu'un redesign du programme.