a problen when making .exe with release

[NoamMiz]

Hi all.

I'm using SFML for almost a year, and i have not problem at all with it.
I built a 2D game using SFML and i want to make an .exe file for my game.
i passed all the tutorials i've seen in the site, and i followed all the insructions correctly.
when i'm running my exe file after making release, in each run i can't see other images in my game.
for example: the first screen is a background image and some small images.
some run of the game i cant see the background image,  in other run i cant see other image and the background image seen well.
the images that i cant see changes in every run of the game.

im using static linking just like it explained in the tutorials.

is anyone have a clue what problem can it be??

tnx Noam

[eXpl0it3r]

This sounds pretty strange since it seems to be randomly. But I can guarantee that SFML does do any magic but only what it gets told. So chances are that although you've followed the tutorials closely, a bug has crawled into your code. Can you provide it?

[NoamMiz]

Hmmm,

2 thingg i forgot to mention:
1 - In Debug mode, the game work propertly.
no bugs or anything like that.
only when im swtiching to Release mode and im doung ReBuild, i get this strange problem.

2 - im a student at college and we all using SFML library.
all my colleagues did exactly what i did (linker configuration etc..) and for them it works fine.

so (im pretty sure) this strange problem is not coming from my code, and i did all the configuration well.

[Celtic Minstrel]

Does your game output any error messages to the console?

[eXpl0it3r]

1 - In Debug mode, the game work propertly.
no bugs or anything like that.
only when im swtiching to Release mode and im doung ReBuild, i get this strange problem.

2 - im a student at college and we all using SFML library.
all my colleagues did exactly what i did (linker configuration etc..) and for them it works fine.

Yes this excludes your code.
So I'd guess it has something to do with the library version. Which version do you use and are you all using the same?

How uptodate is your OpenGL driver?

[Dobi]

2 - im a student at college and we all using SFML library.
all my colleagues did exactly what i did (linker configuration etc..) and for them it works fine.

Are your colleagues running the exact same code or are they just using the same configuration as you but for their own code?
If the second is true: Perhaps you are relying on behaviour of your compiler in debug mode (preinitialize otherwise randomly garbage filled memory ranges with zero or something like that). Or are u using sprite instances that were initialized (and thus point to) image instanced that already ran out of scope? Perhaps you can reduce your problem to a minimum example that reproduces this bevaviour for you and that you can post here.

[NoamMiz]

nope.. 

As i said, in debug mode the game works well.
this strange problem come only when im running the game from release mode.

maybe it somthing that related to the linker -> input? i added 5 files to additional dependencies:
sfml-window-s.lib
sfml-system-s.lib
sfml-graphics-s.lib
sfml-audio-s.lib
sfml-main.lib

for static linkning.

Do you think it related to this? or to something similar to this?

[NoamMiz]

Yes this excludes your code.
So I'd guess it has something to do with the library version. Which version do you use and are you all using the same?

How uptodate is your OpenGL driver?

wee all using 1.6 sfml for visual studio 2008.

i dont know hot uptodate my OpenGL driver. how can i check this?

[NoamMiz]

Are your colleagues running the exact same code or are they just using the same configuration as you but for their own code?
If the second is true: Perhaps you are relying on behaviour of your compiler in debug mode (preinitialize otherwise randomly garbage filled memory ranges with zero or something like that). Or are u using sprite instances that were initialized (and thus point to) image instanced that already ran out of scope? Perhaps you can reduce your problem to a minimum example that reproduces this bevaviour for you and that you can post here)

They using configuration as me but for thier own code.

im usung sprite instances that initialized with image from ImgaeFactory (singletone class so the instance of the class is not destroy and therefor the images dont destroy.

i'll try to reduce to a minimum program, and i'll see if this problem repeat.

[eXpl0it3r]

They using configuration as me but for thier own code.

Oh I thought it was the same code... So it probably still is your code, with some strange initilazing...

im usung sprite instances that initialized with image from ImgaeFactory (singletone class so the instance of the class is not destroy and therefor the images dont destroy.

Global variables are evil and from time to time SFML has some problems with it, regarding loading order of graphics stuff.

[NoamMiz]

Global variables are evil and from time to time SFML has some problems with it, regarding loading order of graphics stuff.

Can you be more specific?
i have a global instance name:"ImageFactory".
inside this instance i'm holding all my images.
the purpose of this is to hold on memmory only one image for few sprites (sprites with same image).

Do you think it's something that related to this ?

[Celtic Minstrel]

Global variables are evil and from time to time SFML has some problems with it, regarding loading order of graphics stuff.

Global variables are also necessary in some situations, unless you want to pass things around to every function in your program.

I think what Exploiter's trying to get at though is that if you have global variables you can get things being initialized in the wrong order. This really depends a lot on just how your ImageFactory class works. If this isn't what you've done already, I would suggest making sure any actual loading of images does not occur before your main function is called. That is, don't do it in an ImageFactory constructor. Instead do it in an init() method and call that from main.

[Nexus]

Global variables are also necessary in some situations, unless you want to pass things around to every function in your program.

They are mostly not really necessary. Even if they seem to initially simplify things, global variables bring a lot of problems which aren't worth the trouble in the long term. If dependencies are kept local, they are much easier to maintain and to debug, while global variables can easily introduce unwanted side effects that are hard to track. Additionally, globals are a problem because of the undefined initialization and destruction order in multiple translation units, and because of the bigger complexity in multi-threaded programs.

Furthermore, it isn't true that you have to pass everything anywhere when you abandon global variables. As dependencies between different modules are now obvious, one tends to reflect twice before creating them, which leads to a more well-thought design. Of course, some parameters are necessary, but they mainly concern constructors. The passed argument can then be stored as class member and is automatically visible in member functions, but local to the class only.

[Laurent]

There are two different things that mustn't be confused.

1. Global variables -- I'm talking about any global access, not just variables that are declared in the global scope; these can be useful, especially in big projects to access the higher-level object(s) of modules

2. Global scope construction and destruction; this should totally be avoided because of initialization order which is undefined between translation units

Conclusion: you can provide global access to objects, but this shouldn't prevent you from initializing and destroying them at the right place, at the right time.

[Celtic Minstrel]

Of course, some parameters are necessary, but they mainly concern constructors. The passed argument can then be stored as class member and is automatically visible in member functions, but local to the class only.

This does kinda make sense. I actually did this to reduce the usage of one of my globals a little while ago.