Generates a surface of depth 0, it should generate a good default (f.e. 16bpp).
And it switches back after it has displayed my title-screen into an unreadable
textmode.
After killing the progamm, the videomode could be restored with textmode.
But the examples works fine (only the text is now blue), so it could be my
failure.
The win32 version didn’t switch into fullscreen mode (last working version
1.0.0)
I get only a black screen, after a short periode the programm just exits.
No message, no information.
Bye
Johns–
Become famous, earn no money, create graphics for FreeCraft.
Generates a surface of depth 0, it should generate a good default (f.e. 16bpp).
Hmm, yes I’ll fix this when I get a chance. Patches are welcome.
The win32 version didn’t switch into fullscreen mode (last working version
1.0.0)
I get only a black screen, after a short periode the programm just exits.
No message, no information.
Do the test programs have the same problem on your system?
The most common cause of this problem is not properly locking the surfaces
and using the pitch of the surface. You should use print statements to
debug this kind of problem - narrow down the exact location your program
crashes.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Generates a surface of depth 0, it should generate a good default (f.e. 16bpp).
Hmm, yes I’ll fix this when I get a chance. Patches are welcome.
The win32 version didn’t switch into fullscreen mode (last working version
1.0.0)
I get only a black screen, after a short periode the programm just exits.
No message, no information.
Do the test programs have the same problem on your system?
The most common cause of this problem is not properly locking the surfaces
and using the pitch of the surface. You should use print statements to
debug this kind of problem - narrow down the exact location your program
crashes.
Hi,
I have found the problem, you should write somewhere in the docs in big letters:
SDL_Surface::pixels is only valid after SDL_LockSurface.
I’m not sure if SDL_Surface::pixels is than constant or could it be changed
between different Lock/Unlock calls?
Bye,
Johns–
Become famous, earn no money, create graphics for FreeCraft.
I have found the problem, you should write somewhere in the docs in
big letters:
SDL_Surface::pixels is only valid after SDL_LockSurface.
I’m not sure if SDL_Surface::pixels is than constant or could it be changed
between different Lock/Unlock calls?
I don’t know for SDL itself, but for some DirectDraw drivers, they are
not constant in some cases (for the TNT2 notably, dunno for others).
BTW, Lock/Unlock has HUGE overhead on some of the more advanced video
boards (pipeline flush and possibly a copy of the surface into system
memory, copying back into video memory on Unlock), so beware!–
Pierre Phaneuf
Systems Exorcist
I have found the problem, you should write somewhere in the docs in big letters:
SDL_Surface::pixels is only valid after SDL_LockSurface.
I’m not sure if SDL_Surface::pixels is than constant or could it be changed
between different Lock/Unlock calls?
It can change between lock and unlock calls.
If SDL_MUSTLOCK(surface) is false, then you don’t need to lock the surface
and the value of pixels will never change.
See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
