for (int i = x; i <= endX; i+=gridMap->getOffsetX()) {
for (int j = y; j <= endY; j+=gridMap->getOffsetY()) {
for (int k = z; k <= endZ; k+=gridMap->getOffsetZ()) {
math::Vec3f point(i, j, k);
CellMap* cell = getGridCellAt(point);
if (cell != nullptr) {
for (unsigned int n = 0; n < cell->getNbEntitiesInside(); n++) {
Entity* entity = cell->getEntityInside(n);
if (visibleEntities[entity->getRootTypeInt()][entity->getId()] == nullptr) {
visibleEntities[entity->getRootTypeInt()][entity->getId()] = entity;
if (entity->getRootTypeInt() == 1)
std::cout<<visibleEntities[entity->getRootTypeInt()][entity->getId()]<<std::endl;
}
}
}
}
}
}
J'ai vérifié et j'ai bien les murs dans le std::vector de std::vector. (le type 1 c'est les murs)
Mais lorsque je veux les récupérer pour les mettre dans un autre std::vector, les murs de mon std::vector de std::vector ont disparu!
vector<string> types = core::split(type, "+");
for (unsigned int t = 0; t < types.size(); t++) {
//unsigned int type = core::Application::app->getIntOfType(types[t]);
unsigned int type = factory.getIntOfType(types[t]);
if (type < visibleEntities.size()) {
vector<Entity*> visibleEntitiesType = visibleEntities[type];
for (unsigned int i = 0; i < visibleEntitiesType.size(); i++) {
bool found = false;
for (unsigned int j = 0; j < types.size(); j++) {
if(i == 1 && visibleEntitiesType[i] != nullptr) {
std::cout<<"type : "<<types[j]<<std::endl;
std::cout<<"entity type "<<visibleEntitiesType[i]->getRootType()<<std::endl;
}
if (visibleEntitiesType[i] != nullptr && visibleEntitiesType[i]->getRootType() == types[j]) {
found = true;
}
}
if (visibleEntitiesType[i] != nullptr && found) {
Entity* ba = visibleEntitiesType[i]->getRootEntity();
if (ba->getBoneAnimationIndex() == visibleEntitiesType[i]->getBoneIndex()) {
entities.push_back(visibleEntitiesType[i]);
}
}
}
}
}
return entities;
Je ne sais pas si c'est un bug de la stl ou du compilo parce que avec un autre projet utilisant ma même lib là tout s'affiche bien par contre pour mon autre projet il y a des tiles qui ne s'affichent pas.
Faut se mettre dans la tête que mettre un problème sur le dos de la stl et/ou du compilo, c'est une vieille astuce pour essayer d'attribuer à quelqu'un d'autre la responsabilité des bugs qu'on a évidemment mis soi-même dans le code. (*)
Ca ne marche jamais, mais c'est amusant quand même, la psychologie de la programmation.
Un des symptômes, c'est de ne pas vouloir montrer tout le code, qui permettrait à un lecteur de trouver la vraie cause de l'erreur. On se demande bien pourquoi ?
(*) qui bien sur marchait avant / chez moi / dans un autre programme / etc.
PS: trois boucles imbriquées pour "récupérer des trucs pour les mettre dans l'autre vector", ça me parait un tantinet louche.
Ca serait plus clair avec des "range-based for loops"
/*
for (unsigned int t = 0; t < types.size(); t++) {
unsigned int type = factory.getIntOfType(types[t]);
*/
for (auto &t : types) {
auto type = factory.getIntOfType(t);
// etc
et ça éviterait de se mélanger les pinceaux entre les i et les j.
- Edité par michelbillaud 23 juillet 2023 à 19:58:53
Je n'avais pas ce bug auparavant et pourtant mon code n'a pas changé. La seule chose qui a changé c'est que j'utilise une factory pour créer mes entités.
D'ailleurs, est-ce que le compilo et la stl a changé depuis l'autre version du code qui fonctionnait ? Parce qu'avec ce genre de raisonnement, il est pas trop sensé avoir changé non plus, donc il est innocent.
J'ai essayé sous linux et là le sol ne s'affiche pas sur windows le sol s'affiche mais les murs ne s'affichent pas je n'y comprends plus rien c'est le même driver nvidia le même compilo mingw et g++.
> Je n'avais pas ce bug auparavant et pourtant mon code n'a pas changé. La seule chose qui a changé c'est que j'utilise une factory pour créer mes entités. Il admet que quelque chose a changé ... Disons que j'ai écrit un petit programme qui fonctionne avec les nombres impairs. Je n'ai rien changé et oups! il ne marche pas avec les nombres pairs. C'est sûrement la faute du compilo ...
Si on ne sait pas utiliser un débuggueur, on affiche les informations pertinentes aux endroits critiques.
- Edité par PierrotLeFou 30 juillet 2023 à 15:18:41
Le Tout est souvent plus grand que la somme de ses parties.
Salut! J'ai corrigé le problème en fait c'était le type int des entités qui n'était pas bon parce que comme je suis en réseau l'id du type sur le serveur n'était pas le même que celui du client donc j'ai généré les ids des type avec le client et ça marche et pour les personnages qui ne s'affichaient pas c'est parce que je chargeais les textures après les avoir chargées sur le composant de rendu et comme j'utilise le blindless texturing bah ça ne s'affichait pas.
>je suis en réseau l'id du type sur le serveur n'était pas le même que celui du client
On parle de la taille, de l'endianness, de la complémentation, etc... ?
Le plus simple, c'est d'utiliser des types et les fonctions de conversion faites exprès pour ça.
Les gars, on a eu chaud. Imaginez qu'il soit vraiment tombé sur un bug dans une librairie ou un compilateur utilisé par des centaines de millier de développeurs ...
Je recherche un CDI/CDD/mission freelance comme Architecte Logiciel/ Expert Technique sur technologies Microsoft.
std::vector de std::vector qui se vide tout seul.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
Le Tout est souvent plus grand que la somme de ses parties.