Window creation crashes

[spackle]

I'm using VS2008 and WinXP SP3 and all SFML programs crash when trying to create the window (this includes the samples.) For some reason this only happens in release builds. The things I've already tried:

* Checked and double-checked to make sure it's linking against the right versions of the libs and all is well in that regard.
* Recompiling the whole thing but that had no effect.
* Tried using both the static and dynamic libs.

I get the following warning when compiling the static Window library which may or may not be an issue:

winmm.lib(WINMM.dll) : warning LNK4006: __NULL_IMPORT_DESCRIPTOR already defined in opengl32.lib(OPENGL32.dll); second definition ignored
winmm.lib(WINMM.dll) : warning LNK4221: no public symbols found; archive member will be inaccessible

Anyone got any idea what's going on?

Thanks.

[spackle]

Perhaps I was not the only person who didn't  know what was going on here?

But I'm happy to say I do now. The SFML libraries were being compiled with SSE2 support enabled which my old processor doesn't support (see Configuration Properties -> C/C++ -> Code Generation -> Enable Enhanced Instruction Set in your project properties (for VS users only obviously.))

Just thought I'd update this post with the solution in case anyone else has this problem some time in the future.

We now return you to your regularly scheduled programming (pun intended.)

[T.T.H.]

Confirmed! Disabling SSE optimizations solves one of my two problems, thank you so much!

By the way: how did you find that out? Trial and error? Knowledge?

[Laurent]

I've removed SSE2 optimizations from Visual C++ projects, thanks for your feedback

[T.T.H.]

Just for the aftermath some info: according to a tool reading the CPUID of my processor I do have an AMD Athlon XP 2000+ at 1666 MHz which has the features SSE, SSE FP, SSE MX, MMX, MMX+, 3DNow!, 3DNow!+, CMOV and MTRR. Please note that there is nothing like SSE2 or so in the list.

Fact is that with all SSE optimizations turned off SFML is on the "safe side" aka "less troubles" aka "beginner friendly".

On the other hand it scares me a bit that enabling an optimization of the compiler produces code which causes horrific behaviour on processors not having the features necessary for said optimization. Is it common like that? Is there no "fall back path" during runtime in case the feature is missing? is the behavior really that horrific (crashes without any hint on what went wrong)?

[zarka]

On the other hand it scares me a bit that enabling an optimization of the compiler produces code which causes horrific behavior on processors not having the features necessary for said optimization. Is it common like that?

Which is why you have to know what you tell your compiler to do! The scary thing is that Visual Studio neatly hides all this so people usually have no clue what they tell the compiler to do for them. If you tell your compiler to SSE2 optimize your code you will not support older machines.

Is there no "fall back path" during runtime in case the feature is missing? is the behavior really that horrific (crashes without any hint on what went wrong)?

If there was a fall back it would probably make it much slower then just running without SSE which wouldn't make sense. If you want to support older machines and have SSE optimizations you will have to compile multiple exes.

[bullno1]

This is one of the reason people fell for .NET . It has in-place optimization.

If you want to support older machines and have SSE optimizations you will have to compile multiple exes.

Or maybe a "launcher" that detects CPU types then launch the correct exes.

Thanks for bringing this up, I might need to deal with old machines.