SFML community forums
Help => General => Topic started by: Dig on May 02, 2010, 11:44:10 pm
-
I've built the SFML2 libraries and examples from the code::blocks project (why can't we have MinGW makefiles??). They run fine but have errors on exit (this program needs to be closed etc.,).
This looks like a return of the bad old default font error that I thought I read was fixed. Is there something I'm doing wrong here, or has it returned and will be fixed before the official release of SFML2?
Running Windows 7 if that makes a difference.
Cheers,
Nick
-
why can't we have MinGW makefiles??
Feel free to contribute ;)
This looks like a return of the bad old default font error that I thought I read was fixed. Is there something I'm doing wrong here, or has it returned and will be fixed before the official release of SFML2?
As far as I know this bug is really fixed in SFML 2. Does it happen with all the graphics samples? Can you try to extract a minimal piece of code that reproduces the problem?
-
It happens with all the graphic samples built without modification from the Code::Blocks project (SFML2).
Doesn't happen with the console samples (voip, networking etc.,).
I'll play around further in the morning and see if I can get a minimal example together. I'm on a different computer at the moment and don't want to install Code::Blocks (and I haven't made and contributed MinGW makefiles yet :) ).
Cheers
-
I've had this problem too, after recently upgrading to SFML2. I also built from the Code::Blocks workspace.
Same thing, when I close the window I get an error that the app has crashed.
It's not the Close() function itself, but maybe it has something to do with the deconstruction?
*shrug*
[EDIT]
... It's not the deconstructor. Messing with some pointers says no to that.
-
Hmm... Something very strange is happening.
I built it all again from today's svn trunk on windows XP (Code::Blocks, MinGW) and it works without error. The executable can be run on my Windows 7 machine without error as well.
But the executable built on Windows 7 has the error.
For some reason I can't build the current trunk on the Window 7 machine.
My suspicion is I have a dodgy configuration somewhere along the line. If I can pinpoint it further I'll update you all.
EDIT
Got it built on Windows 7 and it has an error on close, the minimal code is just:
int main()
{
// Create the main window
sf::Window App(sf::VideoMode(640, 480, 32), "SFML Window");
return EXIT_SUCCESS;
}
Window opens and closes immediately with an error. Copying the same executable to my Windows XP machine the window opens and immediately closes with NO error. Same program built on Windows XP has no error on either machine.
I'll keep investigating...
-
I'm not sure if it's relevant, but are you running x64 Windows 7 and 32-bit XP?
I'm on 64-bit 7, so it might have something to do with the issue if you are as well.
-
Yes indeed, sorry should've mentioned that, 64-bit Windows 7, 32-bit windows XP.
Executable builds on both machines and runs on both (i.e., the windows 7 executable runs on the windows xp machine fine and vice versa).
Error only occurs when its built and run on windows 7 and occurs in any app that opens a window.
Curious.
-
Have you tried running the program in xp emulated mode?
-
I still get a crash when running in XP mode, don't know about Dig.
-
I'm still having this problem.
It appears the problem is in "atioglxx.dll", or so says the windows error report.
Inferring from that, it seems that something in SFML is conflicting with that DLL.
*shrugs*
-
Sounds like a driver problem with ati?
Maybe you could try updating?
-
It's quite possible that it is.
Although, I'm as updated as I get.(I made sure of this as soon as I got this error) I have a driver supplied by Sony, as I own a VAIO. There might be a few things wrong.
I'll go test on my desktop machine later, which doesn't have third-party-based driver implementations, to help narrow down the problem.
-
I have the same problem.
I've tested lots of different drivers (catalyst from 8 to 10) and it must be something wrong with SFML2 window.dll.
(http://img33.imageshack.us/img33/290/errormty.jpg)
Would be so great if you could fix it.
-
I have an idea of the origin of this problem, but unfortunately it cannot be fixed easily. It will require a major modification of how SFML works.
-
a major modification
:shock: SFML 3 already ?
:lol:
-
SFML 3 already ?
Since SFML 2 is not out yet, there's no need to think about SFML 3 :P
-
*facepalm*
Feel like doing a whole lot of work on SFML, there, Laurent? :lol:
If it is SFML itself, though, I'd just have to build SFML2 on a machine that didn't give me those problems, yeah? Theoretically it should work out.