Discussion :

[fearyourself]

@seeme: , c'est gentil

@LittleWhite: aller, pour te faire plaisir :

Le monde du jeu de base était programmé dans les fichiers de données par troncons et chaque bloc représenté bien entendu une partie du monde.

A l'époque cela était fait pour charger qu'une partie du monde à la fois pour des raisons de performance.

De nos jours, cela n'est pas nécessaire, mais je me suis dit que cela ne pouvait pas faire de mal.

Du coup, nettoyage au balai oblige, la classe Map ne donne plus un accès direct aux cellules mais il faut toujours passer par une fonction getCell. Personne n'accéde directement au tableau à part cette fonction.

Par contre, vu que certaines maps autorisent que le map soient extensible sur la gauche (on peut aller du bord gauche vers le bord droite directement), il faut pouvoir gérer la demande de la cellule (-1,-1) par exemple.

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
 
Cell *Map::getCell (int i, int j)
{
    int signedSizeX = sizeX;
    int signedSizeY = sizeY;
 
    //Depending on wrap around parameter, we do different things
    if (wrapAround == false)
    {
        if (i < 0 || j < 0 || i >= signedSizeY || j >= signedSizeX)
            return NULL;
    }
    else
    {
        //Wrap around
        if (i >= signedSizeY)
            i -= sizeY;
        if (j >= signedSizeX)
            j -= sizeX;
        while (i < 0)
            i += sizeY;
        while (j < 0)
            j += sizeX;
    }
 
    return cells[i][j];
}

Et oui, pour le moment je triche . J'ai en fait tout charger. Mais il est simple de faire à la fin :

Code :

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

1
2
3
4
5
 
if (cells[i][j] == NULL)
    loadNewBlock (i, j);
 
return cells[i][j];

Mais histoire de vous faire sourire, voici quelques screenshots :

Devant le château :


Avec une vue d'ensemble :


Effectivement, il faut que je m'occupe des soucis de performances puisqu'on baisse de facon significative dans cette vue.

Jc

[fearyourself]

Voulant optimiser le code, histoire d'avoir une version un peu plus rapide (tourner à 20 images par secondes, c'est bof bof), j'ai bosser un peu sur ces points.

J'ai travaillé sur trois fronts :

- Premièrement, on profile le code

- Ensuite, après avoir fait un profil du code, j'avais deux fonctions ultra-utilisées :

- Texture_Factory::getTexture
- File_Factory::getFile

En gros, les fonctions qui donne la texture aux sprites.

A) Passer les std::string en const std::string& là où cela a du sens. Cela a permis un petit speed-up (*3 à mon souvenir)

B) Ensuite, j'ai travaillé sur optimiser le code OpenGL. J'ai limité la casse en sortant un bout de code dans Map à la place du code rendu, ce qui a permis d'avoir au final un speed-up de *6.

C) En bossant sur une vieille technique de se souvenir de la dernière association faite, j'ai obtenu *12.

D) Par contre, pour le File_Factory ceci marchait nickel, il y avait quasiment un seul fichier utilisé, donc cela marche à merveille. Pour la texture, si vous vous souvenez, on a plusieurs textures à présent et donc cela ne marche pas énormément.

E) J'ai finalement mis deux map pour les deux. La map pour la texture a beaucoup aidé, la map pour les fichiers par contre coûte un peu plus que ma première technique mais est généraliste.

Voilà la fonction pour les textures:

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
 
GLuint Texture_Factory::getTexture (const std::string &fileName)
{
    if (dirty == true)
    {
        quickSearch.clear ();
        dirty = false;
    }
 
    std::map<std::string, GLuint>::const_iterator it;
    it = quickSearch.find (fileName);
 
    if (it != quickSearch.end ())
    {
        return it->second;
    }
 
    std::string name = File_Factory::getFile (fileName);
 
    //Use internal function with File_Factory finding
    GLuint res = Texture_Factory::getInst ()->internalGetTexture (name);
 
    //Remember it
    quickSearch[fileName] = res;
 
    return res;
}

Au final, ces petits changements me font passer d'un FPS de 20 à 1050.

La question intéressante est de savoir si oui ou non j'aurai pu éviter ce 20 ?

Bien sûr que oui. Par contre, mettre les maps, sortir le code, etc. n'est, à mon avis, qu'utile si on voit un souci de performance. Je ne vois pas l'intérêt de tenter de faire quelque chose d'optimiser pour les bouts de code peu utilisés. Je préfére me concentré sur la lisibilité pour ces bouts de code.

Et vu qu'on ne sait jamais exactement où se trouve le bottleneck, je préfére attendre une telle phase d'optimisation pour m'en soucier :-).

Jc

[seeme]

Je suis surpris du *3 pour les références, je n'aurais pas cru ça

Il y avait beaucoup de passages par valeur pour arriver à *3?

Je note ça dans un coin pour ma culture..

[fearyourself]

Je suis surpris du *3 pour les références, je n'aurais pas cru ça

Il y avait beaucoup de passages par valeur pour arriver à *3?

Je note ça dans un coin pour ma culture..

Oui pas mal en fait :-). La version courante est nettement mieux quand même :-)

Jc

[LittleWhite]

Les copies par valeurs sont ultra dangereuses, surtout sur des std::string, qu'on ne sait jamais ce qui est contenu (enfin pas si precisement que cela).
Moi cela ne m'etonne pas (vu que j'ai eu un probleme similaire l'annee dernier )
Et puis dans valgrind, on voit un super grosse difference de memoire alloue / desalloue (pas de fuite, mais juste utilisation de la memoire )

Maintenant, je trouve un peu dommage que vous n'expliquez pas comment vous faite le profiling (meme si je sais que c'est grpof ... juste une petite commande pour le lancer ou des trucs du genre (pour apprendre rapidement aux autres :p)
Et aussi pour savoir ce qu'il donne vraiment comme resultat.

[fearyourself]

Ok ok :-)

Pour faire du profiling (sous linux):

- On compile avec -pg (pour utiliser gprof)

- On exécute le programme comme si de rien était

- Ensuite, on fait : gprof ./backtoroots (vu que mon exécutable est backtoroots)

et on obtient :

22.39 0.15 0.15 200197 0.00 0.00 Texture_Factory::internalGetTexture(std::string)
11.94 0.23 0.08 1875330 0.00 0.00 Cell::update(int, bool)
8.96 0.29 0.06 200197 0.00 0.00 Sprite::render(SDL_Rect&)
7.46 0.34 0.05 111153 0.00 0.00 Logging::logIt(int, __va_list_tag*)
5.97 0.38 0.04 246770 0.00 0.00 File_Factory::getFile(std::string)

Ceci nous dit que la fonction internalGetTexture prend 22.39% de l'exécution. Ensuite, on doit l'optimiser nous même (et donc l'étudier).

Voili voilou tout ce qui reste à faire :-)
Jc

[LittleWhite]

Merci beaucoup
Je vais pouvoir passer mon programme au gprof

[seeme]

Petite précision en passant, gproof ne mesure que le temps dans l'espace utilisateur.

Si on utilise beaucoup d'appel au noyau (aller, au hasard, sleep), il ne mesurera rien (en terme de temps)..

J'imagine que ce n'est pas le cas dans ton programme, mais tant qu'à être didactique :p

[LittleWhite]

Petite précision en passant, gproof ne mesure que le temps dans l'espace utilisateur.

Si on utilise beaucoup d'appel au noyau (aller, au hasard, sleep), il ne mesurera rien (en terme de temps)..

J'imagine que ce n'est pas le cas dans ton programme, mais tant qu'à être didactique :p

Sauf que si on y refléchi bien ... un malloc / free et autre ... sont des allocations système ... si on en fait 3000000...000 on ne verra donc pas ...

[fearyourself]

Version 348 est en place et présente la fin de la phase 1 :-)

En effet, j'arrête l'intégration du 4ème jeu de la série et je me lance dans l'intégration du 5ème de la série. Ceci va permettre de voir si le moteur est bien générique et permet la jouabilité des deux jeux.

La première étape : la gestion du décodage LZW :-), un nouvel algorithme implémenté.

Je vous conseille de le lire, c'est intéressant comme algorithme :

http://en.wikipedia.org/wiki/Lempel%...%E2%80%93Welch

Jc

[LittleWhite]

Version 348 est en place et présente la fin de la phase 1 :-)

En effet, j'arrête l'intégration du 4ème jeu de la série et je me lance dans l'intégration du 5ème de la série. Ceci va permettre de voir si le moteur est bien générique et permet la jouabilité des deux jeux.

La première étape : la gestion du décodage LZW :-), un nouvel algorithme implémenté.

Je vous conseille de le lire, c'est intéressant comme algorithme :

http://en.wikipedia.org/wiki/Lempel%...%E2%80%93Welch

Jc

Plus que deux révisions avant d'avoir quelque chose à se mettre sous la dents
Est ce compliqué d'implémenté un LZW ?

http://cpp.developpez.com/telecharge...donnees-de-LZW
http://www.developpez.net/forums/d33...mpression-lzw/

[fearyourself]

Nous y voilà : révision 350 ! J'ai pris la peine de passer le projet en alpha dans le sens où j'arrête, pour l'instant, l'intégration d'éléments dans le premier jeu.

J'ai commencé l'intégration d'un deuxième jeu afin de voir les capacités du moteur et le garder générique.

Note : Comme pour la révision 300 :

Gardez en tête que beaucoup de choses sont en suspens car le moteur accepte beaucoup de chose mais j'ai éteins pas mal de choses parce que je ne les ai pas encore intégrer.

Bref, vous pouvez trouver le jeu ici : https://sourceforge.net/projects/bac...0.zip/download (il faudra le décompresser et le compiler par contre)

Comme pour la version 300 :

Ensuite, il faudra ensuite télécharger :
- http://prdownloads.sourceforge.net/x...1.zip?download
- http://prdownloads.sourceforge.net/x...d.zip?download

Ces deux zip, il faudra les extraire au même niveau que backtoroots donc pas à l'intérieur...

Par exemple :

~/Projects$ ls
backtoroots ULTIMA4 ULTIMA4VGA
~/Projects$

Si vous ne voulez pas mettre les deux répertoires comme cela ou les nommez comme cela, vous pouvez changer le fichier data/defaultSprite.txt.

Ensuite, make pour installer. En principe, cela vous crée un main et vous pouvez le lancer tel quel.

Il devrait vous mettre dans le niveau 0 du chateau de base.

Vous pouvez :
- Bouger/Sortir des villes
- Discuter avec les gens/marchands/etc
- F1 résume les touches
- E pour entrer dans les villes, K pour grimper les échelles

Touches debug :
- F9 change la position
- F10 change de ville automatiquement (pas dehors par contre...)
- F11 Change la visualisation

Je n'ai que tester ce projet sur Ubuntu et sur deux machines, s'il y a des soucis, de me le dire. Et je m'excuse pour cette version alpha ;-)

Jc

[LittleWhite]

Encore une fois, j'ai tendance à rien comprendre du jeu. Je parle au clown ... mais je ne sais pas quoi lui dire.

Sinon ... bah encore une fenêtre trop grande pour mon écran de pc portable

Je crois que j'ai un bug (voir capture)

Après avoir fait 180 appuie sur F9 et F11 (non ne cherchez pas à comprendre pourquoi) je n'arrive plus à bouger mon perso. A chaque fois que j'appuie sur une flèche il passe sont tour...

Sinon cela fonctionne bien
Les dialogues ne sont pas implémentés ? n'est ce pas ?

[fearyourself]

Encore une fois, j'ai tendance à rien comprendre du jeu. Je parle au clown ... mais je ne sais pas quoi lui dire.

cf. plus bas ;-)

Sinon ... bah encore une fenêtre trop grande pour mon écran de pc portable

Je sais il faut que je propose différentes résolutions ;-)

Je crois que j'ai un bug (voir capture)

En effet, cela est un bug connu, il faut que je retravaille l'algorithme de visibilité.

Après avoir fait 180 appuie sur F9 et F11 (non ne cherchez pas à comprendre pourquoi) je n'arrive plus à bouger mon perso. A chaque fois que j'appuie sur une flèche il passe sont tour...

Bizarre, j'aurai bien voulu voir ce bug, peut-être que je peux le reproduire.

Les dialogues ne sont pas implémentés ? n'est ce pas ?

Cela dépend lesquels, la plupart le sont il faut commencer par Name, job, health et cela donne le départ de la conversation. C'est très limité par contre dans ce jeu ;-)

d'avoir testé le jeu :-)
Jc

[dstar]

Bonjour,

Je ne trouve pas la nouvelle orientation du projet réellement pertinente. Abandonner le premier jeu, qui semble bien avancé, pour se lancer dans un second, c'est généralement signe de lassitude et souvent aussi le début de la fin, c'est dommage.

Dans tous les cas, il faudra bien à un moment décider si le but du projet est de développer un jeu ou un moteur de jeu générique (l'un n'empêchant pas l'autre, il y a quand même une priorité à donner).

Bonne continuation,
dstar

[fearyourself]

Justement, cette transition a toujours été prévue.

En effet, le but premier est le moteur pour gérer plusieurs de ces jeux de façon transparente. Ensuite, lors du développement je bascule maintenant sur un autre, pas par lassitude, au contraire, mais pour m'assurer que le moteur demeure générique. Je ne veux pas devoir dé-spécialiser le moteur plus tard.

Pour moi, l'important est d'avoir ce moteur capable de gérer ces deux ensembles. Vu que beaucoup de choses sont communes, ce n'est pas difficile.

Par exemple, j'ai déjà le monde géré et je peux me balader dedans. Là où cela va devenir plus laborieux est le manque de documentation pour celui là. Je risque de pédaler un peu plus.

Espérant que cela rend mes priorités et buts plus clairs,
Jc

[LittleWhite]

Justement, cette transition a toujours été prévue.

En effet, le but premier est le moteur pour gérer plusieurs de ces jeux de façon transparente. Ensuite, lors du développement je bascule maintenant sur un autre, pas par lassitude, au contraire, mais pour m'assurer que le moteur demeure générique. Je ne veux pas devoir dé-spécialiser le moteur plus tard.

Pour moi, l'important est d'avoir ce moteur capable de gérer ces deux ensembles. Vu que beaucoup de choses sont communes, ce n'est pas difficile.

Par exemple, j'ai déjà le monde géré et je peux me balader dedans. Là où cela va devenir plus laborieux est le manque de documentation pour celui là. Je risque de pédaler un peu plus.

Espérant que cela rend mes priorités et buts plus clairs,
Jc

N'aurait-il pas fallu faire cette "vérification" tout au long du projet et non si tardivement?
Ne fallait-il pas faire une étude en regardant les deux jeux / fichiers de configuration / organisation avant de partir sur le développement ?

Même si je sais que cela va marcher, j'ai l'impression que cela a été pris un peu tard. A moins que la vue soit plus:
- Moteur ultra générique
- Spécialisation par héritage des classes de bases des chargeurs de fichiers

[fearyourself]

Je venais de répondre à ceci et quelque part, cela s'est perdu. Je recommence ;-)

N'aurait-il pas fallu faire cette "vérification" tout au long du projet et non si tardivement?

Oui et non. Il vaut mieux à mon avis bien avancé dans un pour "prouver" que cela marche pour un et ensuite aller vers le deuxième. Par contre, cela ne veut pas dire que le deuxième doit être oublié. Au contraire... Mais dans mon cas, les jeux se ressemblent, donc cela n'est pas vraiment difficile. Si cela fonctionne pour un, cela devrait fonctionner pour le deuxième à quelques lignes près.

Ne fallait-il pas faire une étude en regardant les deux jeux / fichiers de configuration / organisation avant de partir sur le développement ?

Si mais cela aurait demander du temps de préparation, de faire de l'UML, de prévoir un planning, de ... s'endormir

Ce projet est un délire, une facon de se détendre et passer le temps :-). Aucune grande préparation, un but ultime bien défini oui, mais pas de longues discussions (avec moi-même ) sur quel est le meilleur format, qui devrait gérer ceci ou cela...

On avance quand on peut et tout a l'air de tenir la route pour l'instant.

Le planning depuis le début a été :

1) Faire un moteur de jeu qui gére ce genre de chose avec des fichiers customs pour faire sa propre histoire, son propre jeu
2) Puisque 90% des choses sont faites, intégrons le jeu #1 en même temps, cela est intéressant et marrant à faire et permet de voir si j'ai oublié quelque chose.
3) Une fois que (2) est bien avancé, commencons la gestion du jeu #2 pour vérifier que tout est encore compatible et que je ne me suis pas trop spécialisisé dans le (2)

Dans le meilleur des mondes, j'aurai une équipe pour maintenant gérer le (1), continuer le (2) et gérer le (3) en parallèle. Mais je suis, à ma volonté, seul dessus donc je travaille sur une chose à la fois.

Même si je sais que cela va marcher, j'ai l'impression que cela a été pris un peu tard. A moins que la vue soit plus:
- Moteur ultra générique
- Spécialisation par héritage des classes de bases des chargeurs de fichiers

Ben justement, pour le moment, je n'ai rien changé au moteur pour l'intégration du #2. Je charge la map du monde et je peux me balader dedans sans avoir touché au code de base. Tout est compatible pour le moment et ne me prends du temps que parce que la documentation est moins bonne pour ce jeu #2.

Jc

[fearyourself]

Après un peu de triturage et de jouer avec les fichiers de données, me voici prêt à présenter la première ville :

Vue globale :


Vue normale :


Bien sûr il me reste à ajouter les personnages, mais comme je le disais plus haut, je n'ai pas toucher au code du moteur donc pour le moment, tout semble tenir le choc.

Jc

[fearyourself]

Après un petit lapse, je me suis occupé de voir pour le chargement des différents villes et maps du jeu.

On a maintenant le chargement de toutes les villes, villages, chateaux du jeu en place, on peut y accéder de facon transparente maintenant via F10.

Ceci a été fait en faisant une gestion de code comme ceci :

Code :

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

1
2
3
4
5
 
            case SDLK_F10:
                {
                    std::string name = Map_Factory::getMapNextName ();
...

Cet appel est au milieu de la logique du moteur :

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
 
std::string Map_Factory::getMapNextName (void)
{
    switch (type)
    {
        case MAP_LOADER_CUSTOM:
            return "novea.txt";
        case MAP_LOADER_U4:
            return MapU4::getMapNextName ();
        case MAP_LOADER_U5:
            return MapU5::getMapNextName ();
        default:
            assert (0);
            break;
    }
    return "";
}

Petit changement a faire un jour : avoir une instance centrale de la classe Map et donc spécialiser. Cela enlévera ce switch et donnera juste :

Code :

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

1
2
 
 return myMap->getMapNextName ();

Mais je ferai cela un jour... :-)


Ensuite, on passe au prochain map facilement :

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
 
std::string MapU5::getMapNextName (void)
{
    static std::string cities[] = {"../ULTIMA5/TOWNE.DAT",
                            "../ULTIMA5/CASTLE.DAT",
                            "../ULTIMA5/DWELLING.DAT",
                            "../ULTIMA5/KEEP.DAT"};
    static unsigned int idx = 0;
    static unsigned int metaIdx = 0;
    idx++;
    if (idx >= 16)
    {
        metaIdx++;
        metaIdx %= sizeof (cities) / sizeof (cities[0]);
        idx = 0;
    }
 
    std::ostringstream oss;
    oss << cities[metaIdx] << " " << idx;
 
    return oss.str ();
}

Et voilà, F10 fonctionne pour le deuxième jeu et on a tout les chargements des villes :-)

On peut gérer les Npcs maintenant de toutes les villes,
Jc