At least, I can toggle between a fullscreen surface and a windowed
surface over a gtk widget! It is possible!
But, randomly (actually, I cant tell you the reason), the application
crashes, sometimes in SDL_UnRLESurface, or in SDL_FreeFormat (both
called in SDL_FreeSurface)
My code is:
if (screen->surface)
{
SDL_FreeSurface (screen->surface);
screen->surface = NULL;
}
where the screen->surface is the fullscreen surface that was being
displayed before
Any suggestion? The code works with 75% of success… I mean, I can
return back to windowed mode like the 75% of the times.–
signed
derethor of centolos
if (screen->surface)
{
SDL_FreeSurface (screen->surface);
screen->surface = NULL;
}
where the screen->surface is the fullscreen surface that was being
displayed before
Yeah, you shouldn’t do this, the screen surface is managed internally
by SDL.
This should probably be made more explicit in the documentation. PySDL also
calls SDL_FreeSurface on the primary surface.–
Rainer Deyke (root at rainerdeyke.com)
Shareware computer games - http://rainerdeyke.com
"In ihren Reihen zu stehen heisst unter Feinden zu kaempfen" - Abigor
Yeah, you shouldn’t do this, the screen surface is managed internally
by SDL.
This should probably be made more explicit in the documentation. PySDL also
calls SDL_FreeSurface on the primary surface.
Its in the documentation some where because I remember reading it (and I wrote
my code to make sure that the screen surface wasn’t explicitly free’ed)
although I looked and can’t find it now…
I have noticed that the win32 version is lacking TGA support due to a
missing LOAD_TGA flag in the visual C++ workspace preprocessor directives.
So, Sam and the other authors might want to fix that :))
About opengl under windows, I tried to load opengl32.dll using
SDL_GL_LoadLibrary(“opengl32.dll”) and get ALL gl functions using
SDL_GetProcAddr() but the application crashes. The wierd is that it does
not crash when it loads the library or the opengl symbols, it crashes when
it uses them. (I check if they are loaded correctly or not, the lib too).
The same code works fine on linux with libGL.so, although it crashes if I
do not specify a library through SDL_LoadLibrary() which should not, since
it should load libGL.so.1 by default.
Anyone has any idea pleaseeeeeeeeeeeeeeee reply.
I need to get the current x-window bpp,width, height.
When I used SDL_GetVideoInfo() with 24bpp display the function reported
32bpp. With 16bpp display it works fine. Can somebody tell me a safe
method to read the BPP?
thanks
I need to get the current x-window bpp,width, height.
When I used SDL_GetVideoInfo() with 24bpp display the function reported
32bpp. With 16bpp display it works fine. Can somebody tell me a safe
method to read the BPP?
There are two styles of 24 bpp. The first is 24 bits per pixel with
24 bits of useful color information, the second is 32 bits per pixel
with 24 bits of useful color information. Pixel access with the second
format is faster than the first format, so tends to be used by the
hardware more often than true 24 bpp. SDL reports the native pixel
format of the surface, rather than the depth.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
The problem is that I need to know BPP for opengl initialization.
On a 24bpp display SDL_GetVideoInfo returns 32bpp which causes SDL to
report an error with “Coundn’t find GLX info”.
I have also noticed that if I initialize SDL for 16bpp it automatically
sets the opengl to the correct 24bpp values (using SDL_GL_SetAttribute).
It is working on my system but IS it a safe method to use for all
hardware?On Sat, 2 Dec 2000, Sam Lantinga wrote:
I need to get the current x-window bpp,width, height.
When I used SDL_GetVideoInfo() with 24bpp display the function reported
32bpp. With 16bpp display it works fine. Can somebody tell me a safe
method to read the BPP?
There are two styles of 24 bpp. The first is 24 bits per pixel with
24 bits of useful color information, the second is 32 bits per pixel
with 24 bits of useful color information. Pixel access with the second
format is faster than the first format, so tends to be used by the
hardware more often than true 24 bpp. SDL reports the native pixel
format of the surface, rather than the depth.
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
The problem is that I need to know BPP for opengl initialization.
On a 24bpp display SDL_GetVideoInfo returns 32bpp which causes SDL to
report an error with “Coundn’t find GLX info”.
I have also noticed that if I initialize SDL for 16bpp it automatically
sets the opengl to the correct 24bpp values (using SDL_GL_SetAttribute).
It is working on my system but IS it a safe method to use for all
hardware?
Pass in 0 for the bpp value when setting an OpenGL mode, and the GL attributes
will be used to pick the actual display depth for the video mode.
(Loki folks, can you confirm that this is correct?)
See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software
The problem is that I need to know BPP for opengl initialization.
On a 24bpp display SDL_GetVideoInfo returns 32bpp which causes SDL to
report an error with “Coundn’t find GLX info”.
I have also noticed that if I initialize SDL for 16bpp it automatically
sets the opengl to the correct 24bpp values (using SDL_GL_SetAttribute).
That is because there most likely don’t exist any contexts with a 16 bit color
buffer. Keep in mind that the value is a minimum desired value.
It is working on my system but IS it a safe method to use for all
hardware?
On Windows it is possible to change the bitdepth on the fly but that is not
currently possible with GL on Linux so you are stuck with the bitdepth your X
server is currently running.
Pass in 0 for the bpp value when setting an OpenGL mode, and the GL attributes
will be used to pick the actual display depth for the video mode.
16/16 might be a better idea (a driver might expose some strange visuals…
better safe than sorry ;))
16 bit: 16 bit color buffer, 16 bit depth buffer
32 bit: 24 bit color buffer, 24 bit depth buffer
(don’t get fooled, most HW out there only has a 24 bit Z buffer so don’t
request 32 bit as it will fail on most cards)
On Linux it doesn’t really matter at the time but you could check for the
current resolution and then request what I wrote above.
Yeah, you shouldn’t do this, the screen surface is managed internally
by SDL.
This should probably be made more explicit in the documentation. PySDL also
calls SDL_FreeSurface on the primary surface.
It’s safe to call SDL_FreeSurface() on the primary surface, it’s just a
noop. The problem occurs when you call it after you set a new video mode
or quit the SDL video subsystem entirely.
Akawaka, can you add a note to the documentation?
Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software