Discussion :

[LittleWhite]

Petite mise à jour (merci à gbdivers pour les petite remarque ):

- Dans SDL_Renderer, j'ai enlevé de la répétition de code sur les méthodes des rendus. Maintenant, drawSurface(const IVec2& position,const Sprite& pSprite) appelle drawSurface(const IVec2& position, const Sprite& pSprite, const Rect& srcRect) et drawSurface(const IVec2& position, const Sprite& pSprite, const Colour& mask) appelle drawSurface(const IVec2& position, const Sprite& pSprite, const Rect& srcRect, const Colour& mask);

- J'ai enlevé mes variables void* dans les interface Window et Sprite. Cette variable devra (ou non (donc plus de liberté)) être implémenté par les implémentations des bibliothèques natives. Sinon, il faut marqué le rajout d'une méthode virtuelle pure afin de récupéré les données des bibliothèques natives (qui sont toujours utiles au Renderer). Cette méthode est protégé (le Renderer à accès grace à un friend) ce qui me permet de ne jamais laisser voir les types natifs à l'utilisateur final (bon but ultime :p)

[gbdivers]

Bon, bravo pour ton refactoring Je confirme que tu as réussit à isoler toutes les dépendances à la SDL dans NEngine/Native/SDL. J'ai pu réimplémenter le moteur avec Qt sans trop de problème.

Le jeu :


L'éditeur :


Bon boulot !

[LittleWhite]

Bon, bravo pour ton refactoring Je confirme que tu as réussit à isoler toutes les dépendances à la SDL dans NEngine/Native/SDL. J'ai pu réimplémenter le moteur avec Qt sans trop de problème.

Merci ... joli travaille de votre part.
Je vois qu'il manque les textes ? Dernierement j'utilise les polices dans des fichiers images ... cela devrait s'appliquer de la meme facon qu'un simple sprite.
je peux vous laisser un acces sur le SVN si vous voulez mettre votre portage dessus ... demandez le moi

(De plus, j'avance dans un refactoring pour le moteur du jeu ... j'espere que j'irai aussi sur un travail assez propre )

[fearyourself]

Moi je trouve cela super bien comme initiative :-)

Bien joué à tous les deux !

A quand la version avec le moteur Quake 2
Jc

[gbdivers]

Je vois qu'il manque les textes ?

Quels textes ?
Je viens de recompiler ta version SDL et effectivement, il y a des textes

Je regarderai ça

A quand la version avec le moteur Quake 2

Code :

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

1
2
mkdir Sources/NEngine/Native/quake-engine
etc.

Je te laisse faire la suite

@LittleWhite
Pour le svn, on va attendre que j'ai avancé dans le tuto QGraphicsView (donc pas avant 1 mois)

[LittleWhite]

Bonjour à tous,

Enfin je mets à jour mon projet. Enfin nous allons voir la suite de ce jeu.
Alors, certes je suis toujours dans l'amélioration de l'architecture du jeu, mais une fois que tout sera correctement en place, je suis sur que ce sera un bonheur de faire le jeu.

Qu'en est il actuellement. Pour rappel, toute la méchanique interne par rapport au chargement et l'affichage des sprites, l'ouverture de la fenêtre, la gestion du temps a été réalisée de manière modulaire et hautement interchangeable.
La même idée est appliquée sur le reste de l'application. Depuis assez longtemps, je voulais changer mes fichiers de tuiles / unités.
Maintenant, je passe tout en XML. Pourquoi le XML ? car:
- des analyseurs syntaxique existe déjà (plus besoin de faire les miens, qui sont trop basique) ;
- facile à lire pour un humain, comme pour un ordinateur ;
- dynamique.

Pour cela, j'utilise la libxml2 (et non tinyXML :p). La libxml2 est la bibliothèque qui a été choisie par le projet Gnome (du coup elle a été souvent appelé libgnome). J'aurais très bien pu choisir tinyXML pour mes besoins, mais j'avais envie d'étendre mes connaissances sur une deuxième bibliothèque pour les fichiers XML. Et aussi car un bouquin que j'ai eu récemment en parle un peu :p.
Pourquoi je parle de dynamisme ? Simplement car dès le début, je veux mon jeu très dynamique. Si on se rappelle bien, j'utilise des structures pour les tuiles ... ce qui limite le dynamisme aux connaisseurs du C (plus ou moins). Mais aussi, qui nécessite la recompilation du projet pour la prise en compte des changements. Du coup, je pouvais faire mieux, niveau dynamisme.
Le mieux est une "structure dynamique". Ainsi les variables seraient bien stockés dans un truc que l'on appelerai "Tile", mais le nombre de variables peut changer. Ainsi, dorénavant, du coté du code en C++, la structure contient juste une std::map dans laquelle les différentes vairables seront stockés avec leurs noms. Et là, c'est beaucoup plus dynamique. En effet, si une variable est lu à partir d'un fichier, seul une opération de stockage est fait, avec le nom lu, au lieu d'avoir à changer une structure pour chaque ajout d'une nouvelle propriété.
L'avantage du XML est de permettre un ajout rapide qui ne nécessite pas de modification dans l'analyseur (qui n'est plus vraiment fait à la main).
Pour cela, j'ai une classe "Params". J'aime beaucoup cette classe, car elle peut stocker n'importe quoi sous forme de string (comme les données que l'on reçoit du fichier XML) et je peux en ressortir ce que je veux (bon, je peux aussi avoir une exception si la conversion est invalide).
De plus, j'ai une fonction qui, si la donnée recherchée n'existe pas, une valeur par défaut est prise (celle ci est indiqué par une variable paramètre). Cela veut dire, que si mon fichier XML n'a pas une information (par fainéantise, ou juste pour ne pas surcharger celui-ci), le programme pourra continuer à fonctionner sur le comportement par défaut.

Maintenant que la génération des tuiles / unités se fait en lisant un fichier XML, il fallait tout de même que je garde une structure basique (élément de base, comme le nom, l'id et le sprite à utilisé (bon, y en a un peu plus ... )). à cause de cela, il fallait donc que je fasse en sorte que pendant la lecture du fichier XML, je puisse détecter les manques dans les informations non optionnelles. Cela se fait grace à une liste simple et rapide à mettre à jour (la liste est parcouru par une boucle).
Exemple pour les tuiles:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
 
const std::string Tile::neededParameters[] = { "tile-id", "tile-menu", "internalName", "name", "filename", "size_x", "size_y", "defence" };
 
// Check if the important nodes are present
for ( int i = 0 ; i < sizeof(neededParameters) / sizeof(std::string) ; i++ )
{
	if ( !pParams->exists(neededParameters[i]) )
	{
		throw MissingParameterTileException(neededParameters[i]);
	}
}

Du coté de l'analiseyr XML, je me permet d'établir que:
- Si nous atteignons un sous node, le nom du paramètre va être lié par un '_'
- Si nous lisons un attribut, on lie le nom du node conteneur à l'attribut par un '-'

Ce qui me donne des 'tile-id' et autre size_x, pour la structure XML suivante:

Code XML :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
	<tile id='0' menu='0'>
		<internalName>Plain</internalName>
		<name>Plaine</name>
		<filename>plain.png</filename>
		<size>
			<x>32</x>
			<y>32</y>
		</size>
		<!-- <animationTime>200</animationTime> -->
		<defence>1</defence>
		<isRoad>1</isRoad>
		<!-- By default, all others are set to 0 -->
	</tile>

D'ailleurs, voici la définition d'une tuile. La structure peut encore changer, mais c'est plutôt très simple à mettre à jour (du coté fichier comme du coté programme).
Voici comment je définis une unité:

Code XML :

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
 
	<unit id='0' classId='0' faction='0'>	
		<internalName>INFANTRY</internalName>
		<name>Inftry</name>
		<filename>r_infantry.png</filename>
		<size>
			<x>32</x>
			<y>32</y>
		</size>
		<!-- <animationTime>200</animationTime> -->
		<isGround>1</isGround>
		<isBoat>0</isBoat>
		<isFlight>0</isFlight>
 
		<canAttackGround>1</canAttackGround>
		<canAttackBoat>0</canAttackBoat>
		<canAttackFlight>0</canAttackFlight>
 
		<range>
			<min>1</min>
			<max>1</max>
		</range>
 
		<movement>3</movement>
		<fuel>99</fuel>
		<fuelConsumption>1</fuelConsumption>
		<ammo>3</ammo>
 
		<life>10</life>
 
		<price>1000</price>
	</unit>

Certes, y a un peu plus d'information, mais c'est que j'ai aussi laissé les informations optionnelles (qui utilise les valeurs par défaut habituellement)


Comme j'étais dans le XML, j'ai aussi fait un autre analyseur pour lire une liste de nom de thème. Maintenant, nous pouvons ajouter des thèmes facilement \ o /
Lors de ma dernière publication, on me reprochait une mauvaise gestion des erreurs. Ce point a aussi été revu et maintenant, les gestions d'absence de fichier, de fichier mal formatté (comme le XML) sont mieux gérés. Pour cela, j'ai utilisé les exceptions, car le retour de valeur commençait à me faire des imbrications de if / else / if vraiment trop grandes.

Il me reste encore beaucoup de travail dans l'architecture du code et aussi pour le rendre plus dynamique.

Dans les autres changements, on peut noter que le projet Visual Studio 2008 a été mis à jour, mais que les makefile GNU/Linux sont obsolètes.

De plus, malgré la nouvelle lecture des fichiers XML et autre, le changement de l'architecture a provoqué la suppression de quelques fonctionnalités (c'est surtout une question de temps avant que l'on puisse revoir ces fonctionnalités)
(Je publie une mis à jour maintenant, notamment car mon projet est enfin compilable (et qu'il affiche le jeu ... même si le reste n'est pas encore totalement prêt).

[fearyourself]

Excellent ! Moi aussi j'utilise libxml2 pour la simple bonne raison que je voulais pouvoir :

- Lire un fichier
- Changer un noeud XML / le copier / le supprimer
- Ecrire le tout dans un nouveau fichier

Donc, est-ce que tu as du temps pour le projet et cela va avancer de bon train ?

M'enfin, du moment que cela avance, moi je dis

Jc

[LittleWhite]

Excellent ! Moi aussi j'utilise libxml2 pour la simple bonne raison que je voulais pouvoir :

- Lire un fichier
- Changer un noeud XML / le copier / le supprimer
- Ecrire le tout dans un nouveau fichier

Moi je ne voulais que lire un fichier (pour le moment ) et comme j'avais déjà utilisé lé TinyXML, je voulais changer un peu pour me faire une opinion. Perso, j'aime pas du tout la documentation de la libxml2, de plus, l'histoire des unsigned char* comme chaine de caractères et bien gênant lorsque l'on utilise std::string (qui est une basic_string<char> ou un truc du genre)
Il faut donc que je trouve une méthode encore plus propre pour les conversions.

Donc, est-ce que tu as du temps pour le projet et cela va avancer de bon train ?

Bah, j'ai plus de temps qu'il y a 3 mois Donc j'essaie d'avancer sur ce projet (sachant que j'ai un autre projet, lié à la section Qt de ce forum ). Donc là, même si les changements ne sont pas énormes (quoique), cela avait bien pris du temps. Les mis à jour seront normalement plus régulière à partir de maintenant, car j'ai enfin une version qui compile

[fearyourself]

Oui, j'ai préféré la librairie libxml++ qui était vraiment mieux pour du C++ mais je n'ai pas trouvé comment faire ce que je voulais en libxml++ donc je me suis rabattu là-dessus :-)

Jc

[pierreyoda]

C'est moins bien que le Lua

Non je plaisante, excellente avancée ça fait plaisir à voir

[LittleWhite]

C'est moins bien que le Lua

Non je plaisante, excellente avancée ça fait plaisir à voir

Mais je pense aussi à LUA (en plus fearyourself à testé pour moi )
Il fallait que les fichiers décrivants les tuiles / unités soit modifiable facilement, sinon ça sert à rien de pouvoir changer le code des liens entre les tuiles, si on ne peut même pas changer les tuiles (chaque chose en son temps )

[fearyourself]

Mais je pense aussi à LUA (en plus fearyourself à testé pour moi )

C'est clair que si tu as des questions, tu peux me demander ;-)

Jc

[LittleWhite]

Nouvelle petite mis à jour, mais réellement bénéfique.

Dans ma classe GameEngine, je crée les différentes "boites" (interface utilisateur) comme celle pour la construction d'unités. Dans la première conception du jeu, la création de la boite était la suivante:

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
 
std::vector<ConstructUnitView> factoryUnits;
	{
		const UnitTemplate* pU = pMap->getTheme()->getUnit("INFANTRY",0);
		factoryUnits.push_back(ConstructUnitView(pU,pU->getSprite(),pU->getName(),pU->getPrice()));
		pU = pMap->getTheme()->getUnit("BAZOOKA",0);
		factoryUnits.push_back(ConstructUnitView(pU,pU->getSprite(),pU->getName(),pU->getPrice()));
		pU = pMap->getTheme()->getUnit("RECON",0);
		factoryUnits.push_back(ConstructUnitView(pU,pU->getSprite(),pU->getName(),pU->getPrice()));
		pU = pMap->getTheme()->getUnit("TANK",0);
		// ...
	}
 
pCBFactory = new ConstructBox(pNE->getSpriteLoader(),GFX_PATH "constBackground.png",GFX_PATH "constCursor.png",GFX_PATH "upArrow.png",GFX_PATH "downArrow.png", "./data/fonts/font.png",factoryUnits, pNE->getWindow()->getWindowSize());
pCBPort = new ConstructBox(pNE->getSpriteLoader(),GFX_PATH "constBackground.png",GFX_PATH "constCursor.png",GFX_PATH "upArrow.png",GFX_PATH "downArrow.png", "./data/fonts/font.png",portUnits, pNE->getWindow()->getWindowSize());
pCBAirport = new ConstructBox(pNE->getSpriteLoader(),GFX_PATH "constBackground.png",GFX_PATH "constCursor.png",GFX_PATH "upArrow.png",GFX_PATH "downArrow.png", "./data/fonts/font.png",airportUnits, pNE->getWindow()->getWindowSize());

Je peux vous dire, qu'avec un code tel (sachant que j'ai 15 unités réparties sur 3 boites), les architectes logiciels me jettent des pierres. Ils ont raison .
Prenons quelques cas pratique:
- Si je rajoute une unité, je dois rajouter une entrées dans ma liste
- Si d'un coup, je décide de faire une nouvelle fabrique, qui ne fabrique que des véhicules, je dois rajouter une boite, soit: un pointeur ; une liste ; le code de destruction et pour finir, la gestion dans le jeu (avec la machine à état, soit un état en plus (oui, c'était vraiment pourri)).
- Si je modifie une unité, je dois changer le code.

à vomir, n'est ce pas?

Heureusement, je prends conscience de tout ce code bidon. Aujourd'hui j'apporte une mise à jour qui me permet de faire cette gestion des fabriques d'unités totalement dynamique (centralisé dans mes fichiers XML).
Le nouveau code se présente sous cette forme:

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
// Construct all the contruction boxes needed by going throw the tile list
	for ( std::list < const Tile* >::const_iterator itPTile = tilesList.begin() ;
				itPTile != tilesList.end() ; ++itPTile )
	{
		const Params* tileParams = (*itPTile)->getParams();
		// For each unique producer name (if existing)
		if ( tileParams->exists("producerName") && 
			 constructionBoxes.find(tileParams->get("producerName")) == constructionBoxes.end() )
		{
			constructionBoxes[tileParams->get("producerName")] = new ConstructBox(pNE->getSpriteLoader(),GFX_PATH "constBackground.png",GFX_PATH "constCursor.png",GFX_PATH "upArrow.png",GFX_PATH "downArrow.png", "./data/fonts/font.png",pNE->getWindow()->getWindowSize());
		}
	}
 
	// For each unit, we get the tile indicated where the unit is produced
	// If not existing, the loading fails
	for ( std::list < const UnitTemplateFactionList* >::const_iterator itPUnit = unitsList.begin() ;
			  itPUnit != unitsList.end() ; ++itPUnit )
	{
		const Params* unitParams = (*itPUnit)->get(0)->getParams();
 
		if ( unitParams->exists("produceIn") )
		{
			if ( constructionBoxes.find(unitParams->get("produceIn")) != constructionBoxes.end() )
			{
				constructionBoxes[unitParams->get("produceIn")]->add(*itPUnit);
			}
			else
			{
				LError << "A unit is producable in a tile (producer) not existing -> '" << (*itPUnit)->get(0)->getParams()->get("produceIn") << "'";
				return false;
			}
		}
	}

Et ... j'ai copié tout le code utilisé. Ce morceau de code permet de gerer N boite, M unités, sans changer le code. De la magie? presque.
Comme je l'ai dit, j'utilise mes fichiers XML. Pour les tuiles qui produisent les unités, j'ai rajouté un champ 'optionnel':

Code XML :

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

<producerName>Factory</producerName>

(Pour les bateaux, on l'appelle "Port" et pour les avions "Airport").
Maintenant, on connait les différentes boites à créer. Il faut encore savoir qu'elles unités vont être crées dans ces boites.
Un nouveau nœud apparait donc dans le fichier des unités:

Code XML :

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

<producedIn>Airport</producedIn>

Qui indique donc, que l'unité sera produite dans un aéroport.

Au début, je pensais utiliser le nom interne de la tuile, mais cela causait des problèmes avec les différentes factions (car le nom est unique et donc dépendant de la faction (peut être que cela est un autre défaut de conception)).

Voilà.
Il est aussi à noter que le code permet de repérer les erreurs (par exemple, une unité qui veut être créée dans une boite qui n'a pas de tuile). Cela permet aussi la modularité, il est facile d'imaginer l'intégration d'une nouvelle boite / nouvelle unité ou encore d'avoir une unité qui ne peut être construite.

Un autre changement qui a découlé de cette amélioration:
Au début j'avais une machine à état, avec les états:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
enum GameState
	{
		GS_VISU,
		GS_FACTORY,
		GS_PORT,
		GS_AIRPORT,
		GS_SELECT,
		GS_MENU,
 
        GS_MOVE
	};

Comme vous pouvez le voir, un état pour chaque boite (Factory / Port / Airport)
Maintenant, il n'y a plus qu'un seul état pour toutes les boites \ o /
Ce qui m'a permet de simplifier le code (et même de rajouter des morceaux pour protéger des erreurs) dans les fonctions de dessins / mis à jour. En effet, avant j'avais trois fois un code similaire, pour chaque boite. Maintenant, le code est unique.

Il y a encore une chose que je n'ai pas dit. Avant, la classe de la boite était accompagné d'une structure, élément de la boite. Cette structure est vite devenue inutile lors des dernières mise à jour qui ont fait évolué le contenu des classe pour les unités. Donc encore une fois, je simplifie.

Normalement, les prochains jours, je vais continuer à faire de petits changements qui sont tout de même important afin de simplifier le code.

(Je me rappelle un fearyourself qui nous donne des infos sur le nombre de lignes de code dans son projet. étonnamment, moi je régresse dans ce nombre (bon faut aussi dire que mon code était très pourri avant))

[fearyourself]

Joli boulot d'abstraction ! Fait attention tout de même de ne pas passer des heures et des heures à réécrire et réinventer ton code. On peut y passer une vie plus ou moins :-)

(Je me rappelle un fearyourself qui nous donne des infos sur le nombre de lignes de code dans son projet. étonnamment, moi je régresse dans ce nombre (bon faut aussi dire que mon code était très pourri avant))

Lol, cela m'arrive aussi à moi :-)
Jc

[LittleWhite]

Encore une mise à jour de l'architecture de l'application.

Cette fois, j'ai essayé d'appliquer le principe de responsabilité unique à ma Map. Je vous rappelle que ma Map était capable de se charger à partir d'un fichier. Pour le MapEditor (hérité de Map) la sauvegarde était aussi possible.
Mais, au final, cela faisait que la classe était trop grosse (car la gestion des données dans la Map est déjà importante) alors j'ai fait des classes: MapLoader, MapSaver et MapFactory, pour charger, sauvegarder et créer des instance de Map.
De part ce changement, je supprime aussi les héritages MapGame et MapEditor, laissant la possibilité à une Map de géré toute ses ressources toutes seules.
Il me reste de la réorganisation à faire à ce niveau, mais au moins j'avance

à notez que ces derniers jours, il y a eu une simplification complètes de toutes les petites boites d'interface. Notamment les bandeaux pour l'éditeur.

[LittleWhite]

Bonjour,

Dans la nouvelle mise à jour que je veux présenter, il y a:
- Le port GNU/Linux de nouveau en place
- La TileBar totalement refaite pour simplifier le code
- L'éditeur qui est bientôt réintégré comme avant

[fearyourself]

Excellent ! Le projet commence à ne plus être refactoré et on revient sur des avancées alors ?

:-)
Jc

[LittleWhite]

Excellent ! Le projet commence à ne plus être refactoré et on revient sur des avancées alors ?

:-)
Jc

Exactement,

Tout le fond est prêt je pense. J'améliore maintenant la boucle principale (ce que j'ai fait y a deux jours) afin que le code soit plus leger / beau qu'avant.

Il faut savoir que tout ce qui est lié à la gestion de la carte, c'est fait.

Du coup, j'améliore le coeur même du déroulement de l'application afin de pouvoir intégrer facilement les menus, les écrans titres (un jour) et tout ce qu'il y a machine à état du jeu.
J'ai aussi fait ça, pour ajouter un compteur de FPS.
Très prochainement, je vais encore amélioré, alléger le code et surtout, retirer le gros ralentissement que l'on a

[LittleWhite]

J'ai plusieurs bonnes nouvelles pour cette mise à jour.

Hum, par quoi commencer?

Le gain de 40 FPS sur la version Windows (enfin, je dis sur Windows, car c'est la seule version que j'ai testé)?
Un autre gain possible (prêt de 40 autre FPS) si je modifie mes fichiers images?
Le fait que l'éditeur n'est plus un projet séparé et a été complêtement fusionné avec le jeu?
Une gestion plus simple des arguments de la ligne de commande?

Bon, je vous explique.

J'ai trouvé un gros ralentissement dans mon programme (qui ne tournait plus qu'à 10FPS (et en plus cela ralentissait ). Ce ralentissement était du à une utilisation des exceptions dans la classe Params là où je n'aurai pas du.
En effet, j'utilisais les exceptions, pour vérifier si un paramètre était présent ou non dans la classe. Et comme l'exception est souvent lancer car la méthode getAs() permet de récupéré un paramètre ou une valeur par défaut, alors le programme perdait du temps sur le système d'exceptions.
J'avais certes lu des cours sur les exceptions et notamment que leurs utilisation ne ralentisse pas le programme dans le cas ou celle-ci n'est pas lancé (véridique sur une version récente de GCC ou la perte de temps, lorsque l'exception n'est pas lancé, est nulle). Par contre, lorsque l'exception est lancé (puis rattrapé un niveau de pile plus haut) la perte est énorme (40FPS pour mon jeu, lorsque le mécanisme est utilisé dans l'affichage de la carte (soit, dans mon test, 15x15 exceptions lancés par boucle O_o).
Donc, on remarquera que les exceptions sont surtout un mécanisme pour récupérer les erreurs et non pour une utilisation dans le bon fonctionnement du programme (ce qui est logique). En conclusion, j'ai remplacé l'utilisation de l'exception par une simple vérification de l'existence du paramètre (fonction que j'avais déjà codé).
Voilà \ o /

Comment puis-je gagné 40 autre FPS ? C'est surement un truc dont j'avais déjà parlé. Je vais le refaire ici, au cas ou. Alors, la SDL fait des copies de mémoire afin d'afficher les sprites. Mais si un sprite n'est pas dans le même format que la fenêtre de destination, alors la copie est ralentit par une conversion.
Ok, jusque là, c'est normal. Sauf que cette conversion ralentit beaucoup les programmes (disons 50% du temps pris sur la conversion (je l'avais déjà vu dans un projet universitaire (et j'avais rapporté le bug sur ma page de projet sur google code )). La SDL propose une fonction pour convertir nos sprites dans le format de la surface de l'écran. (SDL_DisplayFormat).
Je n'ai toujours pas appliqué le changement, car j'utilise une couche alpha pour mes sprites. Celle-ci est perdu.
La solution finale (qui sera bientôt mise en oeuvre) est de changer les sprites, pour la partie transparente, d'appliquer une couleur clé que la SDL remettra en transparent (soit pas de copie des pixels).
Y a plus qu'à

Comme je l'ai dit, l'éditeur est partie intégrante du jeu. Lors de mon dernier post, j'avais parlé d'une réorganisation du programme sur les machines à états. L'éditeur est un GameState ainsi que le jeu.

Finalement, j'ai amélioré la gestion de la ligne de commande. Grace au changement cité juste avant, en passant la commande '--editor' on lance l'éditeur à la place du jeu.
J'ai crée une classe pour la gestion des arguments (l'analyse en elle même) et une structure pour pouvoir passer tout les paramètres au GameEngine. La fonction main() du programme en est alléger . (Un jour un prof m'avait dit que le main devait juste lancé le programme et ne rien faire d'autre (soit 4 lignes )).

Voilà,

Dans les taches qui me restent à faire:
- Une dernière inspection des éléments qui peuvent être améliorés
- La documentation

Et après, comme l'attend fearyourself, je code le jeu \ o /

[LittleWhite]

Aujourd'hui, toujours pas grand chose.

J'ai juste rajouté une classe d'utilitaire pour le chargement des thèmes. J'ai aussi réorganisé les Exceptions. Mais sinon, rien de notable.
La documentation a été complété.

Aujourd'hui, j'ai réalisé une petite documentation pour répertorié tous les états et choses que je vais devoir faire les prochains jour. Je vous joint les documentations.
Donc je l'annonce et cette fois j'en suis sur, le jeu va progressé.