Discussion :

[Cirrus Minor]

RedSkidy, tu as apparemment peu d'expérience en C++ et tu t'attaques à une "reconversion" d'algorithme qui m'a pas l'air si simple que ça... Ce sera un excellent exercice, tu vas apprendre pas mal de choses, mais tu devrais tout remettre à plat.
D'autres intervenants t'ont conseillé d'utiliser des types de la STL, je pense que c'est une bonne idée.

Tu devrais donc tout reprendre depuis le début, essayer de comprendre le code, l'intégrer et le tester petit à petit dans ton programme.
Là, tu es assez confus (ça se sent), nous ne pouvons pas trop t'aider parce que ça part dans tous les sens.
Bon courage !

[Iradrille]

Sérieusement, on vient de te répondre pour ce problème..

Code :

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

1
2
3
4
5
6
7
8
calque::~calque(){
    std::cout << "destructeur" << std::endl;
    int j;
    for (j=0; j<this->taille; j++) //ici
        delete this->v[j];
    delete[] this->v;
    std::cout << "fin boucle destructeur" << std::endl;
}

Bon avec toutes ces erreurs je pense que tu commences a voir l'avantage des vectors ^^"

[RedSkidy]

je pense que plutot que de copier/coller le code puis le modifier je vais le recopier en le traduisant directement en C++ il y a trop de pointeurs et avec tableaux en plus refaire tout ça proprement seras surement mieux.

je me posait aussi une autre question :
ma map seras générée par gros carrés de 16*16 et pas entière en un coup. comment je pourrais faire pour que les carrés soient cohérents entre eux ? et aussi comment modifier le seed en fonction des coordonnées sans que 2 carrés soient identiques (pour que la map soit toujours pareil pour le meme seed sans que les carrés se répètent)

[RedSkidy]

extrait de mon cours de programmation :
"Les tableaux mutli-dimenionnels utilisant des vector ne sont pas la meilleure manière d'accéder efficacement à la
mémoire et ne sont pas très optimisés. On préférera donc utiliser des tableaux multi-dimensionnels statiques à moins
que le fait de pouvoir changer la taille de la grille en cours de route soit un élément essentiel"
je ne ferais pas mieux d'utiliser des tableaux statiques ?
si oui peut-on avoir un .h comme ça :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
#ifndef __calque_h__
#define __calque_h__
class calque
{
public:
calque(int taille, float persistance);
~calque();
private:
    int m_taille;
    float m_persistance;
    int m_tableau[m_taille][m_taille];
};
#endif

edit : apparemment non. peut-on avoir un tableau statique en argument d'un objet avec une taille variable en fonction du constructeur ?

[Astraya]

"Les tableaux mutli-dimenionnels utilisant des vector ne sont pas la meilleure manière d'accéder efficacement à la
mémoire et ne sont pas très optimisés. On préférera donc utiliser des tableaux multi-dimensionnels statiques à moins
que le fait de pouvoir changer la taille de la grille en cours de route soit un élément essentiel"

Changer la taille avec un std::vector est très couteux. C'est une des raisons d'ailleurs pour lesquel il ne faut pas choisir le std::vector lorsque tu ajoutes ou retires des éléments. Il procure un accès rapide, mais les insertions/suppresions ont un coût, celui de la recopie des données présentes dans le std::vecteur. Tu peux limiter les dégats en allouant préalablement une taille nécessaire pour contenir un maximum défini d'élément avec le resize() du std::vector, mais dans ce cas, il serait surement possible de la faire avec un C array ( tableau[] ). Sachant que l'allocation dynamique à un coût que l'allocation statique n'a pas.
Ensuite, tu peux très bien travailler avec un seul std::vector pour avoir un tableau à 2 dimensions.

peut-on avoir un tableau statique en argument d'un objet avec une taille variable en fonction du constructeur ?

Non. Le compilateur doit connaitre la taille de ton tableau à la compilation. Si tu ne connais pas la taille à la compilation, combien ferait le sizeof de ta classe? sizeof est un opérateur évalué à la compilation donc il doit connaitre la taille de tous les membres de ta classe. Tu peux changer le std::vector car il est alloué dynamiquement et pas statiquement.

[bretus]

"Les tableaux mutli-dimenionnels utilisant des vector ne sont pas la meilleure manière d'accéder efficacement à la
mémoire et ne sont pas très optimisés. On préférera donc utiliser des tableaux multi-dimensionnels statiques à moins
que le fait de pouvoir changer la taille de la grille en cours de route soit un élément essentiel"

Ce conseil est très mauvais pour des débutants, il revient à dire "On optimisera d'abord l'initialisation des tableaux" quand un programme passe généralement son temps à accéder aux éléments des tableaux.

Or, la majorité du temps, ce sont donc les temps d'accès aux éléments du tableau qu'il faut optimiser et ça veut dire : Organiser le tableau en mémoire en fonction des traitements que l'on fait sur celui-ci pour accéder à des éléments voisins en mémoire.

Encore une fois : "premature optimization is the root of all evil". Généralement, tu vas croire que tu optimises en utilisant une technique sans la comprendre et tu vas te verrouiller sur une implémentation qui t'empêchera par la suite de faire les optimisations qui auront un réel impact sur les performances de ton programme.

M'enfin... Qu'importe : On va te laisser aller au bout avec ton initialisation statique et à la rigueur, on te montrera à la fin ce que ça aurait simplifié

Alors, ton initialisation statique peut fonctionner ainsi :

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
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
 
#ifndef __calque_h__
#define __calque_h__
 
class Calque {
public:
    const static int N = 16 ;
 
    // constructeur par défaut
    Calque( const int & defaultValue = 0 ){
        // TODO amuse toi bien avec les boucles
    }
 
    // constructeur par recopie
    Calque( const Calque & other ){
        assign( other ) ;
    }
 
    // opérateur d'affectation
    Calque& operator = ( const Calque & other ){
        assign( other ) ;
        return *this ;
    }
 
    ~Calque(){
        // pas de new, pas de delete : rien à faire ici
    }
 
    void assign( const Calque & other ){
        // TODO amuse toi bien avec les boucles
    }
 
    int& operator() ( const int & i, const int& j ) {
        return _data[i][j] ; 
    }
    const int& operator() ( const int & i, const int& j ) const {
        return _data[i][j] ; 
    }
 
    const int& size1() const {
        return N ;
    }
    const int& size2() const {
        return N ;
    }
 
private:
    int _data[N][N];
};
 
std::ostream & operator << ( std::ostream& s, const Calque & calque ){
    for ( int i = 0; i < calque.size1(); i++ ){
        if ( i != 0 )
            s << std::endl ;
 
        for ( int j = 0; j < calque.size1(); j++ ){
            if ( j != 0 )
                s << " " ;
 
            s << calque(i,j) ; 
        }
    }
    return s ;
}
 
#endif

A l'usage :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
int main( int argc, char* argv[] ){
	Calque calque ;
	for ( int i = 0; i < calque.size1(); i++ ){
		for ( int j = 0; j < calque.size2(); j++ ){
			calque(i,j) = i + j ;
		}		
	}
	std::cout << calque << std::endl;
 
	return 0 ;
}

A toi de jouer avec les TODO dans le code ci-dessus et la fonction suivante :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
 
Calque generer_calque(
    int frequence,
    int octaves,
    float persistance,
    int liss,
    int seed
){
    Calque calque( /* valeur par défaut */ ) ;
    // TODO
    return calque ;
}

[RedSkidy]

merci je vais voir ce que je peut faire de tout ça.
je me demandais aussi comment je pourrais faire pour que les différents carrés que je vais générer soient différents mais cohérents entre eux ?

[ternel]

Pour la cohérence des carrés, ca dépend de ce que tu appelles "cohérence".

Une solution basique est d'avoir un ensemble de bordures prédéfinies.
Ca n'est pas parfait, ca donne une impression de carrelage, mais c'est sans rupture (seamless).

[RedSkidy]

c'est bon je pense avoir trouvé pour ça et j'ai réussi a "finir" chunkmanger mais le chargement/sauvegarde des chunks est très longue (3 sec par chunk) et comme il faudras en charger/sauvegarder 10 toutes les 4 secondes sa fait 30 secondes de lag toutes les 4 secondes, je pense que sa vient du temps de lecture/ecriture dans les fichiers donc je me demandais comment je pourrais optimiser ça.

[jblecanard]

Astraya: pour optimiser le remplissage d'un vector lorsqu'on connait une borne max du nombre d'éléments, il vaut mieux utiliser reserve plutôt que resize.

"Les tableaux mutli-dimenionnels utilisant des vector ne sont pas la meilleure manière d'accéder efficacement à la
mémoire et ne sont pas très optimisés. On préférera donc utiliser des tableaux multi-dimensionnels statiques à moins
que le fait de pouvoir changer la taille de la grille en cours de route soit un élément essentiel"
je ne ferais pas mieux d'utiliser des tableaux statiques ?

Il est vrai que l'on déconseille généralement les vector de vector, mais on conseille plutôt un seul vector avec une fonction de calcul d'indice en fonction des dimensions de la matrice représentée. Du reste le terme "tableau statique" (indépendamment de l'aspect multidimensionnel) prête à confusion. Est-ce le tableau qui est statique, ou sa dimension ? (question rhétorique bien entendu, c'est la dimension ici). Il est plus exact de parler de tableau à taille constante. En C++11, pour les tableaux de taille constante, il y a std::array, qui vaut toujours mieux, surtout lorsqu'on débute, qu'un C array.

Pour le problème de continuité des tuiles (je suppose que c'est ce que tu entends par "cohérence"), le problème n'est pas simple et conditionne l'algorithme. Pour moi, il faut choisir une graine et un algorithme qui s'applique à la map entière, mais ne l'exécuter que sur les chunks qui t'intéressent (il faut pour cela que l'algo puisse être exécuté "par morceau"). C'est un sujet qui doit être pas mal traité sur les forums de développeurs de jeux.

Pour l'écriture sur le disque, là encore, on n'est pas dans le trivial et plusieurs techniques existent. Tout d'abord, il faut bien concevoir le format de stockage des données (le format texte est proscrire ici), et bien tester son code car on a vite fait de faire n'importe quoi avec des formats binaires. Si le volume de données est grand, il peut être intéressant de les compresser, car l'écriture sur disque coûte souvent plus cher que le temps processeur nécessaire pour compresser. Le choix de l'algo est également primordial (snappy est un algo de compression très rapide qui peut être intéressant, gzip reste bon dans ce type d'application). Enfin, il faut aussi bufferiser pour écrire par lots et éventuellement mettre en place une écriture asyncrhone (un thread fait les calculs et met dans le buffer, un autre écrit sur le disque dès qu'il peut). 3 secondes me parait énorme, mais difficile de juger sans se plonger complètement dans ton code. Il faut aussi faire du profiling pour vérifier que les problèmes de performances ne proviennent pas d'une erreur ou d'une partie d'algo foutrement foireuse. Ha, et ne pas oublie de tester son code compilé en release, lorsqu'on mesure les perfs.

Je ne sais pas sur quelle plateforme tu bosses, mais ce serait bénéfique de prendre l'habitude de passer un coup de valgrind ou un autre memory checker, je suis sûr que ça lèvera plein d'erreurs avec un code aussi touchy.

[RedSkidy]

est-ce que le l'écriture/lecture binaire est rapide ? parce que pour bien faire il faudrais qu'un chunk se charge/sauvegarde en moins de 0,1 sec (ou meme 0,05).
il faut charger/sauvegarder a peut près 65000 variables (le contenue d'un tableau de16x256x16).

[Iradrille]

est-ce que le l'écriture/lecture binaire est rapide ? parce que pour bien faire il faudrais qu'un chunk se charge/sauvegarde en moins de 0,1 sec (ou meme 0,05).
il faut charger/sauvegarder a peut près 65000 variables (le contenue d'un tableau de16x256x16).

Bah c'est un accès disque. Lire / écrire ~256ko en 50/100ms est tout à fait possible.

[RedSkidy]

comment je peut faire pour écrire (et lire) le contenu d'un tableau en mode binaire j'ai un peu cherché sur internet mais j'ai pas trouvé grand chose après peut-être que je sais juste pas chercher

[Iradrille]

Ouvres ton fichier en indiquant le mode binaire : std::ios::binary

[RedSkidy]

quelque chose comme

Code :

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

std::ifstrem flux(file, std::ios::binary);

?

[Iradrille]

Oui.

Code :

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

1
2
3
std::ifstream flux("file.txt", std::ios::binary);
// ou
flux.open("file.txt", std::ios::binary);

[RedSkidy]

ok merci