From: Couriersud
Subject: fix for audio dsp exit crash / various dfb issues
The current code will crash on exiting an application. The attached diff
fixes the issue.
Prepping for using MMX and SSE intrinsics instead of inline assembly.
.. except for memcpy equivalents which only get faster if they can
exploit the parallelism of loading into multiple SIMD registers. :)
From: Couriersud
Subject: Some SDL1.3 patches
LoadLibrary will call X11_GL_Initialize. If LoadLibrary is called before
a window is created, it will crash since structures are not properly set
up.
From: couriersud arcor.de
To: slouken@libsdl.org
Subject: Directfb driver for SDL1.3
Hi,
the attachment contains a patch for a SDL1.3 directfb driver. It supports:
- Renderer "directfb":
Hardware acceleration as supported by the underlying directfb driver. With a
radeon X850, testsprite2 runs at 50% to 70% of OpenGL (X11, dri) performance.
Also supports hardware accelerated yuv overlays. This must be enabled by sett
ing:
export SDL_DIRECTFB_YUV_DIRECT=1
- Renderer "opengl"
Supports software opengl using mesa opengl (make linux-directfb).
Some more information may be found in README.DirectFB
There will certainly still be some bugs, and there is some debug code around.
When I find some time, I will compile against directfb-0.9.25 as distributed
with ubuntu 7.04.
The diff also contains a fix for SDL_LockYUVOverlay fixing a bug in *pixels
and pitches initialization.
Kind regards,
couriersud
- SDL_Surface is a system memory representation of pixel data
- SDL_Texture is a video memory representation of pixel data
The concept of SDL_Surface with SDL_HWSURFACE is no longer used.
Separated SDL_Texture types by usage rather than memory type
- SDL_TEXTUREACCESS_STATIC is for rarely changed pixel data,
can be placed in video memory.
- SDL_TEXTUREACCESS_STREAMING is for frequently changing pixel
data, usually placed in system memory or AGP memory.
Optimized the SDL_compat usage of the OpenGL renderer by only
using one copy of the framebuffer instead of two.
