probleme compilation version release visual c++

Bonjour,
je devellope sous visual c++ 6, un jeux multijoueurs en c++ et opengl sous win32.

sous visual vous pouvez "builder" le projet en mode debug ou en mode release.
visual place l'executable de votre programme dans ces repertoires en fonction du mode.

mon jeux est "fini" et j'ai decouvert une chose que je ne comprend pas :

lorsque je "run" mon jeux depuis visual, aucun probleme.
je teste donc de copier l'executable (se trouvant dans le repertoire release)
à la racine de mon projet, la ou se trouve mes repertoire "graphiques" et "sons" necessaire à mon jeux,
aucun probleme.

je decide donc de copier : l'executable du jeux, le repertoire "graphiques" et "sons"
dans un autre repertoire pour preparer la version finale.
et la je lance mon jeux et ça rame completement.

en resumé si je lance mon prog depuis le repertoire du projet pas de probleme.
je copie le meme executable et le lance dans un autre repertoire et ça rame completement..

bizarre non ?
meme probleme que ce soit en debug ou release.

ya t'il des choses specifiques à mettre dans le "projet setting" du projet pour une version final ?

Exécute ton prog après avoir enlevé le max de résidents en mémoires notamment les prog antivirus si tu en as, peut être que le ralentissement vient de là, ça m'est déjà arrivé.

LaPatoshe

EUREKA !!!

en fait pour ma version final j'avais prevu de faire un setup, et il se trouve que j'ai ajouté les librairie opengl comme "glut32.dll" etc..
à la racine du jeu pour ceux qui n'ont pas ces librairies (en fait il manque par defaut sous windows : glut32.dll),
et c'est cela qui pose probleme.
j'ai mis ces librairies dans un repertoire "openglLibrairie" pour qu'il n'y ait plus de conflit.
et tout fonctionne.

moralité:
pour ceux qui font de l'OpenGl ne j'amais placer ces librairies au meme niveau que votre programme !

merci quand meme.

A priori, les résidents en mémoires sont hors de cause étant donné que son programme tourne parfaitement dans le répertoire du projet. Un test à faire : copier l'intégralité du projet dans le dossier final (qui porte donc un autre nom) et tester. Si ça marche nickel, c'est qu'il y a un fichier dans le dossier du projet dont dépend ton programme. Dans ce cas, une solution barbare, mais qui fonctionne, est de retirer les fichiers a priori superflus un par un et de tester à chaque fois, jusqu'à ce que le programme rame, pour identifier le fichier. Dans le cas où le programme ramerait avec cette copie, je proposerais un problème lié au nom du répertoire, dont le seul endroit que je connaisse où il puisse être référencé est la base de registre (une petite recherche du répertoire initial du projet donnera vite la réponse). Sinon, comme ça, je ne vois pas.

erf... trop tard pour ma réponse... d'où l'intérêt de ne pas s'endormir sur son clavier :p
Ce n'était donc pas un problème de fichier manquant, mais un fichier en trop. Effectivement, le programme utilise en priorité les librairies présentent dans le dossier du programme avant d'aller chercher dans les dossiers système. Et par certains miracles de windows, ça ne fonctionne pas toujours bien dans cette situation (si quelqu'un a une explication rationnelle à celà, je suis toute ouie)...