Discussion :

[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.

[LittleWhite]

Enfin je reviens donner des nouvelles sur le projet.

J'avoue, j'ai étais un peu pris par le temps (et la motivation) ... en plus je suis de plus en plus actif sur DVP ... ce qui me laisse de moins en moins de temps O_o. Mais je pense que cela devrait se stabiliser dans les semaines qui suivrent.
Enfin bref, trêve de blabla ... voyons les nouveautés.

Première nouveauté:

Petite mis à jour interne de la gestion des Sprite afin de mieux signaler les erreurs (et d'éviter des crashs, si erreur il y a ). Ceci est fait en utilisant des exceptions
Je tiens à remercier fearyourself qui m'avait un peu aider à me remettre dans le bain des exceptions (afin de ne pas faire de fuite de mémoire et d'avoir une utilisation simple).
Donc voici le code d'une toute nouvelle exception:

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
 
class ConstructionFailedException : public std::exception
{
private:
	std::string message;	/*!< Message to display */
 
public:
	//! Exception constructor
	/*!
          \param userMessage message from the user to display
        */
	ConstructionFailedException(const std::string& userMessage):message(std::string("Failed to create class '") + userMessage + std::string("'")) {}
 
	virtual const char* what() const throw()
	{
		return message.c_str();
	}
};

C'est simple, c'est beau .

La classe Sprite lance maintenant des exceptions (sur l'utilisateur )

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
 
Sprite :: Sprite(SpriteManager& sm, const std::string& fileName, const bool needScaling)
{
	surface = sm.getSurface(fileName,needScaling);
	if ( surface == NULL )
	{
		throw ConstructionFailedException("Sprite");
	}
 
	LDebug << "Sprite created from file (" << fileName.c_str() << ")";
 
#ifdef _DEBUG
	nbSAllocation++;
#endif
}

Et bien sur, on attrappe les exceptions pendant le chargement du niveau ... ce qui permet de faire un retour d'erreur judicieux et d'arrêter le programme avec des messages :p.
La classe Font a aussi été protégé, ainsi que toutes les UI

Dans le même genre, j'ai ajouté une exception lors de l'ouverture de fichier par l'intermédiaire du LineParser .

Deuxième nouveauté ... une nouvelle option \o/ pour permettre le changement de thème

./OpenAWars --theme nom_du_theme

Par défaut, celui qui est chargé est le thème classic
Ceci n'est que pour l'éditeur car le thème est présent dans le fichier des cartes

J'ai aussi supprimé les compteurs de créations de Sprite et AnimatedSprite et Font. Qui ne servait presque plus, et puis depuis que mon projet est porté sur Linux je peux faire les tests de fuites de mémoire avec valgrind.

Maintenant nous pouvons quitté le jeu à partir du menu. Nous pouvons aussi faire la fin des tours. De plus, on peut quitter le menu de construction sans faire de construction \o/.

[fearyourself]

Excellente avancée ;-) faut continuer comme ca :-)

Jc

[seeme]

Un rapide message pour te félicite rpour ton projet et ta progression

Je suit ça avec beaucoup d'interêt

Bon courage!

[loka]

Un petit message pour dire que je suis aussi régulièrement l'avancement de ce projet.

[Ange_blond]

ça avance (j'ai perdu la course aux commits depuis longtemps faut croire )

Sinon, loin de moi l'idée de vouloir troller, mais les exceptions ne sont-elles pas un moyen de ne pas avoir à remontrer manuellement la pile d'appels avec des tests judicieux de l'état de retour des méthodes ?
Je veux dire qu'on peut faire sans, et que c'est souvent un moyen de ne pas se prendre la tete, non ?

[LittleWhite]

Sinon, loin de moi l'idée de vouloir troller, mais les exceptions ne sont-elles pas un moyen de ne pas avoir à remontrer manuellement la pile d'appels avec des tests judicieux de l'état de retour des méthodes ?
Je veux dire qu'on peut faire sans, et que c'est souvent un moyen de ne pas se prendre la tete, non ?

On peut toujours faire autrement.
Lors du traitement des erreurs nous avons 4 choix:

• ne pas traiter l'erreur (souvent cela crash) ;
• utiliser des assert (relativement meme resultat que la precedente solution lors de la distribution du jeu) ;
• utiliser les retours d'erreurs ;
• utiliser les exceptions.

Maintenant, cela faisait longtemps que je n'utilisais plus trop les exceptions. J'en ai deux, et je pense que cela facilite le travail.
Deja, je n'envoie des exceptions que lorsque j'ai des constructeurs qui finissent mal. Sinon, j'utilise les retours d'erreurs (sachant que les retours d'erreurs n'existe pas dans les constructeurs, cela alourdi le code).
De plus, les exceptions sont rattrappees au plus tot (enfin des que l'on sort des constructeurs).
Finalement, j'ai lu que la nouvelle version de G++, cree un code a coup nul si une exception n'est pas leve ... donc c'est tout de meme tres benaif, car de toute facon, dans l'autre cas, les performances on s'en fout ... le jeu a plante (proprement).

Maintenant, faire sans, indique que je dois faire pour mes classes un boolean qui est mis a jour si une erreur survient (je l'ai fait, et j'imagine qu'il y en reste des traces). Une fois que cela est fait, un niveau au dessus je dois le tester. Je ne vois pas vraiment ou cela est plus simple.
Pour moi, les deux ont un meme cout d'ecriture (ou presque en fait ).

[seeme]

La seule nuance serait peut-être que coller des assert partout permet de repérer les erreurs critiques et limiter quand même les crashs.

Apparement certains jeux pros utilisent plus cette approche.

Après, j'imagine que dans le cadre présent c'ets plus une question de feeling

[Ange_blond]

Alors pour la "gestion" des crash, il existe un exception handler dans l'API windows qui permet d'appeller le code de son choix lors d'un crash de l'application (utilisé par tous les édtieurs de logiciels pour tenter d'écrire un backup et faire une recovery au re démarrage de l'application)

Apres en effet, chacun ses preferences... perso je suis pas tres exception, mais c'est sur qu'il est parfois lourd de gerer un booléen de status par classe pour vérifier son état a tout bout de champ...

[LittleWhite]

Bonsoir,

Voilà une toute petite mis à jour, car dans la théorie, je n'avais qu'une heure pour faire le changement. Du coup, j'ai pris la tâche la plus simple dans ce cas (et ce que va aussi me permettre de passer valgrind et gprof sur mon programme)
J'ai mis à jour le fichier de base qui sert à l'auto génération des Makefiles pour Linux.
Maintenant le jeu est aussi compilé \o/

[LittleWhite]

Aujourd'hui est un grand jour c'est la révision 42 de mon projet
Quels sont les nouveautés ... en fait ... presque rien.

J'ai pu faire une petite vérification avec valgrind, et j'avais fait qu'une petite erreur (oublié de supprimer un pointeur ) Une deuxième erreur a été repéré, mais juste parce que j'utilise une variable qui n'avait aucune valeur ... du coup je l'ai supprimé (car les exceptions remplacent cette variable ... donc )
Comme quoi ... passer son code par valgrind quelques petites fois, c'est bien.

Maintenant, les vrais changements.
Déjà, une remise en forme de MenuBox afin d'avoir une liste d'élément un peu plus dynamique (car je vais utilisé la même instance pour afficher tout pleins de menus, car il va me falloir des menus pseudos dynamique (dans le sens ... je ne peux pas prévoir à l'avance ce que j'aurais). Pour cela, maintenant je stocke des pointeur de MenuView (d'entrées) dans une liste que je passe au MenuBox. Avant c'était des instances, sans passer par des pointeurs.
C'est mieux, mais pas trop dans le sens, il peut y avoir des problèmes de mauvaises libération de pointeurs (comme toujours ).
Il y a aussi une petite différence dans l'affichage du fond du menu, car maintenant, le fond est une bande que l'on affiche pour chaque entrée (avant je créais tout le fond, qui était donc moins dynamique si le nombre d'entrées change :p)

Autre mis à jour ... on peut enfin déplacer des unités. Pour l'instant le déplacement n'est pas très limité ... mais c'est le début
Voici le code:

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
 
bool MapGame :: move(const UVec2& origPosition, const UVec2& destPosition)
{
    if ( origPosition == destPosition )
    {
        return false;
    }
 
    if ( origPosition.x >= this->width && origPosition.y >= this->height )
    {
        return false;
    }
 
    Unit* unit = unitMap[origPosition.y][origPosition.x];
 
    if ( unit == NULL )
    {
        return false;
    }
 
    if ( !testTile(destPosition, unit->type))
    {
        return false;
    }
 
    // Move physical unit data
    unitMap[origPosition.y][origPosition.x] = NULL;
    unitMap[destPosition.y][destPosition.x] = unit;
 
    // Move reprentation unit data
    unitViewMap[destPosition.y][destPosition.x] = unitViewMap[origPosition.y][origPosition.x];
    unitViewMap[origPosition.y][origPosition.x] = UT_NO_UNIT;
 
    unit->enabled = false;
 
    return true;
}

Rien de particulier en fait.
Par contre, la méthode testTile() était anciennement dans EditorMap, je l'ai juste remonté dans Map pour avoir plus d'accès

Voilà

[gbdivers]

Bonjour LittleWhite

Compilation sous Ubuntu 10.10 64b, gcc 4.5 -> beaucoup de warning (plusieurs centaines) :
- principalement parce que tes switch ne prennent pas en compte systématiquement toutes les possibilités : mettre un "default:" à la fin de chaque switch.
- également beaucoup d'erreur de comparaison entre un signed et un unsigned
- main_editor.cpp, ligne 65, variable "startTime" inutilisée ; TileBar.cpp, ligne 312 : variable "time" inutilisée
- tu "protèges" certain fichier avec "#ifdef EDITOR" mais pas tous (par exemple main_editor.cpp) : erreur de compilation (mais je suis coupable de ne pas avoir utilisé le makefile )
- dommage que tout se fasse au clavier sur l'éditeur. Au fait, une petite page d'aide au démarrage de l'éditeur pour expliquer les touches, ça serait pas mal (et mettre F1 pour afficher l'aide aussi)
- Ça pourrait être bien d'afficher des cartes plus grande sur desktop

Très bon boulot

[CriPpLe]

Bonjour LittleWhite

- tu "protèges" certain fichier avec "#ifdef EDITOR" mais pas tous (par exemple main_editor.cpp) : erreur de compilation (mais je suis coupable de ne pas avoir utilisé le makefile )

Très bon boulot

Normalement c'est #ifndef et par contre c'est simplement pour les fichiers headers pour éviter l'inclusion multiple.

[gbdivers]

Il ne s'agit pas ici des directives de protection des inclusions multiples mais d'une directive permettant de compiler selon 2 modes : le mode jeu et le mode éditeur. C'est donc bien de #ifdef pour inclure les fichiers supplémentaires de l'éditeur (ou les exclure lorsque la directive est absente)

Le top du top serait peut être de pouvoir passer du mode jeu au mode éditeur dynamiquement