You can also directly check it out with this command:
cvs -d :pserver:guest at libsdl.org:/home/sdlweb/libsdl.org/cvs co -r branch_1_3_x SDL12
This branch is based on the SDL 1.2.6 release. As additional 1.2.x releases
are made, I will merge the fixes into the SDL 1.3 branch.
Currently the only addition the SDL 1.3 branch is the implementation of
OpenGL render targets for offscreen hardware accelerated rendering. This
appears to work fine on Linux with NVidia cards, and I’m interested in
feedback for other cards and drivers. There is a crash in NVOGLNT.DLL
under Windows, and I have a report in to NVidia about it, but I haven’t
heard back. If anybody figures it out, please let me know!
The new functions are:
SDL_GL_CreateRenderTarget()
SDL_GL_GetRenderTargetAttribute()
SDL_GL_BindRenderTarget()
SDL_GL_LockRenderTarget()
SDL_GL_UnlockRenderTarget()
SDL_GL_FreeRenderTarget()
You can see a demo of them in the new testrendertarget.c file in the
test subdirectory.
Enjoy!
-Sam Lantinga, Software Engineer, Blizzard Entertainment
Hi,On Sunday 21 September 2003 21:01, Sam Lantinga wrote:
It will not be binary compatible with SDL 1.2, although it should be
backwards compatible, possibly only requiring a recompile.
Do I understand you correctly in that programs compiled against SDL 1.2.x
will no longer work with SDL 1.3.x without a recompile?
I really don’t like this idea - I’m not looking forward to the horrors
caused by distributions that won’t install both SDL 1.2.x and SDL 1.3.x in
parallel correctly, for example. If ABI breakage is inevitable, it might be
better to just call it SDL 2.x, even if it’s just for the psychological
effect - people are used to ABI changes on major versions, so it wouldn’t
be as bad.
(On the other hand, if people hear “SDL 2.x”, they might expect more new
features than are actually there sigh)
The SDL 1.3 branch is an unstable branch of SDL where we can add the
most often requested and easy to implement API features.
I have some suggestions.
There are two frequently asked questions that could be solved more clearly.
-How do I make SDL use x as backend?
-Export SDL_VIDEODRIVER=backend
-It still says no available video device.
-SDL blits are darn slow. X can do it faster.
-You should check that your surfaces are of the same format, use SDL_DisplayFormat.
Scenario 1 is not that easy for newbies or support persons over the
phone. What is happening is that the requested backend isn’t compiled
in. How about a more useful error message, like “backend override,
requested backend not compiled in” for an API (and ABI) compatible
solution, or a way to list all possible backends of the libSDL.so (or
.dll) loaded?
In scenario 2, I suggest having some kind of a flag to
SDL_BlitSurface, like SDL_FASTBLIT, that will just FAIL with an error
if the blit needs some sort of conversion. Or a new function,
SDL_FastBlitSurface. Whatever. The point is explicit fast blit
requesting, which is usually used when putting sprites etc on screen,
whereas converting blits are used in stuff that do … well
… conversion. Like SDL_GL_LoadTexture in testgl.c. Fast blitting for
conversion or convert-blitting for sprites, both are just wrong by
nature.–
Petri Latvala
testrendertarget failed to create render target, but is correctly linked
to libGL.so.1. testgl is working.
More below,
Carsten
Test results:
Linux 2.4.22, gcc version 2.95.3 20010315
XFree86 4.20, Voodoo 3 3000
Vendor : VA Linux Systems, Inc.
Renderer : Mesa DRI Voodoo3 20010501 x86
Version : 1.2 Mesa 3.4.2
…/testrendertarget
Failed to create render target, using screen buffer
testrendertarget: opengl error: 1281 (0x0501)
7 frames in 5.542 seconds = 1.26308 FPS
./testgl
Screen BPP: 16
Vendor : VA Linux Systems, Inc.
Renderer : Mesa DRI Voodoo3 20010501 x86
Version : 1.2 Mesa 3.4.2
Extensions : GL_ARB_multitexture GL_ARB_transpose_matrix GL_EXT_abgr
GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_histogram
GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_polygon_offset
GL_EXT_rescale_normal GL_EXT_stencil_wrap GL_EXT_texture3D
GL_EXT_texture_env_add GL_EXT_texture_object GL_EXT_texture_lod_bias
GL_EXT_vertex_array GL_HP_occlusion_test GL_MESA_window_pos
GL_MESA_resize_buffers GL_NV_texgen_reflection GL_PGI_misc_hints
GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_pixel_texture
GL_SGIS_texture_edge_clamp GL_SGIX_pixel_texture
Currently the only addition the SDL 1.3 branch is the implementation
of OpenGL render targets for offscreen hardware accelerated rendering.
This
appears to work fine on Linux with NVidia cards, and I’m interested in
feedback for other cards and drivers. There is a crash in NVOGLNT.DLL
under Windows, and I have a report in to NVidia about it, but I
haven’t heard back. If anybody figures it out, please let me know!
If I change sample.bmp from 8bit color to 24bit, I get no more opengl
error, but still “failed to create render target” ( it shows just
multiple “mesa” strings ).
testrendertarget failed to create render target, but is correctly linked
to libGL.so.1. testgl is working.
Vendor : VA Linux Systems, Inc.
Renderer : Mesa DRI Voodoo3 20010501 x86
Version : 1.2 Mesa 3.4.2
Extensions : GL_ARB_multitexture GL_ARB_transpose_matrix GL_EXT_abgr
GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_histogram
GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_polygon_offset
GL_EXT_rescale_normal GL_EXT_stencil_wrap GL_EXT_texture3D
GL_EXT_texture_env_add GL_EXT_texture_object GL_EXT_texture_lod_bias
GL_EXT_vertex_array GL_HP_occlusion_test GL_MESA_window_pos
GL_MESA_resize_buffers GL_NV_texgen_reflection GL_PGI_misc_hints
GL_SGI_color_matrix GL_SGI_color_table GL_SGIS_pixel_texture
GL_SGIS_texture_edge_clamp GL_SGIX_pixel_texture
The render target code relies on the GLX_SGIX_fbconfig and GLX_SGIX_pbuffer
extensions which are probably not present in your driver. Do you see them
in the output from glxinfo?
See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment
No, the driver doesn`t have these extensions (glxinfo output).
It is now time to get a new video card ?
My mail about “solving” the opengl error was wrong. The error was
about the bitmap size (rescaled sample.bmp to 256x105), not about color
depth. Maybe because of the hardware limitation texture size of the
Voodoo3 (256x256).
CarstenOn Tue, 23 Sep 2003 06:41:08 -0700 Sam Lantinga wrote:
The render target code relies on the GLX_SGIX_fbconfig and
GLX_SGIX_pbuffer extensions which are probably not present in your
driver. Do you see them in the output from glxinfo?
