OpenAWars - Advance wars like

**pierreyoda** · 16/10/2010, 18h31

Salut,

j'ai testé votre démo, et bravo, c'est du bon boulot!

Maintenant, quelques petits points que j'ai relevé en passant :
- l'image de DCA "Blue Moon" (bleu) est toute petite
- 25% d'utilisation processeur ! Sur un Core i7 (920) et une Radeon 4850, c'est fort! (synchronisation verticale et/ou limiteur d'FPS activé(s) ?

- les animations de la barre (très bien faites au demeurant) laguent chez moi...

Sinon superbe boulot!

**LittleWhite** · 16/10/2010, 19h01

Pour le DCA "Blue Moon" j'ai remarqué, et c'est corrigé (pas sur le SVN, car les graphismes ne sont pas sur le SVN

)
Pour la prise du CPU, je suis assez étonner ... :s il faut que je vérifié ... mais avec un debuggueur c'est dur dans ce cas là. Je pense qu'il y a une erreur dans le limiteur de vitesse

Finalement, pour la vitesse lente de la barre, cela dépend de la résolution. Enfin, cela dépendait de la résolution. Du coup, j'aimerai connaître quelle était votre résolution :p

**pierreyoda** · 16/10/2010, 20h12

Euh, celle par défaut je crois, je n'ai pas utilisé la ligne de commande

**LittleWhite** · 17/10/2010, 19h39

Pfu ,c'est votre PC qui est tout

...

----

Bonjour,

Petite correction: J'ai aussi appliqué l'offset du scaler sur la position de dessin du curseur.

Grande correction!

Oui, c'était du boulot, je suis rentré dans mon code avec la masse, pour tout détruire de la base, et reconstruire un monde plus solide (ou presque).
Le changement apporte aussi une façon de modifier le jeu de manière "simple".
Effectivement j'ai rajouté un fichier, dans lequel toutes les tuiles ont leurs paramètres, selon le format suivant:

# File to set the values for each tile.
# Here the list of parameters:
#
# ID of the Tile
# name_of_the_tile
# name_of_the_sprite_to_load
# size_x size_w (of one sprite in the animation)
# time (time between two sprite)
# defence (defence given by this Tile)
# is_it_a_road_?
# is_it_a_bridge_?
# is_it_a_river_?
# is_it_sea_?
# is_it_a_beach_?
# is_it_a_building_?
# is_it_an_HQ_?
# does_it_need_background_?
# cityLife

Ce qui fait que maintenant dans mon code, je n'ai qu'une simple boucle pour lire/charger les tuiles avec leurs animations:

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
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
 
for ( unsigned int i = TT_Plain ; i < TT_Invalid ; i++ )
	{
		unsigned int idTile = static_cast<unsigned int>(lp.getInt());
		lp.readNextLine();
		if ( i != idTile )
		{
			LWarning << "The tileset does not have sprite is good orger -> Received: " << idTile << " ; Expected: " << i;
		}
		std::string name = lp.getLine();
		lp.readNextLine();
		std::string spriteName = lp.getLine();
		lp.readNextLine();
		IVec2 spriteSize = lp.getIVec2();
		lp.readNextLine();
		int spriteDuration = lp.getInt();
		lp.readNextLine();
		unsigned char defence = static_cast<unsigned char>(lp.getInt());
		lp.readNextLine();
		bool isRoad = lp.getBool();
		lp.readNextLine();
		bool isBridge = lp.getBool();
		lp.readNextLine();
		bool isRiver = lp.getBool();
		lp.readNextLine();
		bool isSea = lp.getBool();
		lp.readNextLine();
		bool isBeach = lp.getBool();
		lp.readNextLine();
		bool isBuilding = lp.getBool();
		lp.readNextLine();
		bool isHQ = lp.getBool();
		lp.readNextLine();
		bool needBackground = lp.getBool();
		lp.readNextLine();
		unsigned char cityLife = static_cast<unsigned char>(lp.getInt());
		lp.readNextLine();
 
		tilesSet[static_cast<TileType>(idTile)] = Tile(new AnimatedSprite(sm,GFX_TILES_PATH + theme + std::string("/") + spriteName, spriteSize.x , spriteSize.y, spriteDuration, true),
			name,
			defence,
			isRoad,
			isBridge,
			isRiver,
			isSea,
			isBeach,
			isBuilding,isHQ,
			needBackground,
			cityLife);
	}

Vous pouvez voir que j'ai rajouté un LineParser. Cette classe est une idée de fearyourself, que j'ai presque pris directement de son code. (Merci à fearyourself

)

Maintenant, la Map contient un tableau de TileType (pour la carte en elle même) est un dictionnaire qui associe un TileType à un Tile. Le Tile recontient (truc que j'avais enlevé un moment) le sprite pour dessiner la tuile ainsi que tout les paramètres nécessaires chargé du fichier.
Les fichiers Tile.cpp et Tile.h ont fait un régime, le Tile.cpp est inutile et le Tile.h ne déclare plus que la structure Tile ainsi que les enums.
Il n'y a plus de fabrique, ni même d'analyseur de TileType vu que tout est chargé à partir du fichier.

Du coup, à chaque fois que l'on a besoin d'une information sur une tuile, nous passons par la carte. Mais de toute façon, ce cas là arrive généralement dans la Map et son héritier le MapEditor.

Je crois que j'ai tout dit.
Ah! Ce changement va bientot être appliqué aussi pour les unités. (Pfu! ça en fait du boulot

)

**LittleWhite** · 18/10/2010, 21h13

J'ai voulu aller trop vite, du coup, le fichier du tileset de la révision 30 est faux. C'est corrigé

J'ai aussi corriger un bug que j'avais rajouté dans la version précédente (avec le curseur) mais uniquement visible dans la version Jeu.

Premier changement:
J'ai modifié mon analyseur de fichier de carte pour utiliser le nouveau LineParser. Du coup cela simplifie un peu le code (pas de trop) et surtout, plus besoin de ce soucié des ouverture / fermeture de fichier)

Le deuxième mis à jour a été décrite dans le message précédent.
J'ai donc ajouté un nouveau fichier qui sert à décrire les unités.
Il a la structure 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

Voilà pour aujourd'hui. Je crains de ne plus avoir beaucoup de temps pour faire évolué ce projet car l'université reste tout de même plus importante :p.

**fearyourself** · 19/10/2010, 12h23

Est-ce que cela veut dire que le projet est mis en pause, qu'il est à l'arrêt, qu'il est terminé (vaporware) ou qu'il va juste avancer doucement ?

:-)

Jc

**LittleWhite** · 19/10/2010, 12h32

J'espere qu'il va avance doucmenet, et j'espere que cela ne sera pas trop doux

**CriPpLe** · 19/10/2010, 14h10

Tu fais quoi comme études ?

**LittleWhite** · 19/10/2010, 14h19

Actuellement, BSc Final Year en 'Games Programming' a l'universite de Teesside (Angleterre).
La grande chance, c'est que j'ai pris module de 'Multiplayer' et 'IA', mais il y a d'autres modules qui prennent du temps, du genre:
"Games Development" (ou l'on doit faire un jeu complet, avec des graphistes et tout

)
"Personnal Project" (ou je dois faire un projet de recherche, tout seul, tout bien)

**CriPpLe** · 19/10/2010, 14h49

Cool ça comme études ^^

**LittleWhite** · 19/10/2010, 22h49

Nouvelle mise à jour (vous voyez, je ne lâche pas le projet):
J'ai intégré la possibilité de quitter en appuyant sur la croix.

En fait, j'ai aussi cherché par rapport à ce bug, que le jeu prend trop de CPU, et semble ramer. Il vrai qu'il rame, et pour l'instant, je ne sais pas encore la cause...

Donc c'est sur ma liste

**Ange_blond** · 20/10/2010, 08h15

Envoyé par LittleWhite

En fait, j'ai aussi cherché par rapport à ce bug, que le jeu prend trop de CPU, et semble ramer. Il vrai qu'il rame, et pour l'instant, je ne sais pas encore la cause...

Pour trouver ce qui se passe, je te conseille des Profilers (Valgrind sous Linux) qui vont t'indiquer combien de temps est passé dans quelle méthode, et te premettra donc de trouver les goulots d'étranglement sur ton code (ces méthodes qui mine de rien ralentissent tout le code car non optimisé ou appellée a tout vas)

Bon courage.

**LittleWhite** · 20/10/2010, 09h41

Envoyé par Ange_blond

Pour trouver ce qui se passe, je te conseille des Profilers (Valgrind sous Linux) qui vont t'indiquer combien de temps est passé dans quelle méthode, et te premettra donc de trouver les goulots d'étranglement sur ton code (ces méthodes qui mine de rien ralentissent tout le code car non optimisé ou appellée a tout vas)

Bon courage.

Je suis entièrement d'accord sur la méthode (et puis il faut que je vérifie les fuites de mémoire

) mais il semble que le cas soit assez bizarre (mais, plus facilement repérable) car j'ai une chute de performance lorsque je change les tuiles (ou alors peut être même) lorsque j'ouvre la TileBar.
C'est une grande indication

(Et puis, hier je manquais un peu de temps, ce n'était donc que la première investigation)
Merci pour les conseils

**LittleWhite** · 22/10/2010, 11h46

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** · 23/10/2010, 05h53

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** · 23/10/2010, 10h59

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

Jc

**LittleWhite** · 24/10/2010, 01h22

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** · 24/10/2010, 15h31

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** · 26/10/2010, 09h34

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.