This actually ends up being quite a bit slower on my MacBook, but I'm
checking it in to test on a PPC iMac.
Maybe someone knows why it's slower?
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%402595
The SDL 1.2 API version of testsprite went from 120 FPS to 320 FPS. :)
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%402592
a renderer based on a framebuffer.
Fixed an initialization bug with the dummy video display mode.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%402589
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
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%402588
- 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.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%402584
Added SDL_VIDEO_OPENGL_CGL to the default Mac OS X config file.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%402552
This fix is overkill, but approved by Doug Lea, and he'll be releasing a
new version of his malloc.c sometime next month.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%402547
"Mac OS X/x86 won't build the MMX/YUV inline assembly without optimizations
enabled (not enough registers), so for now, we only build it if we see
the __OPTIMIZE__ #define, which GCC provides when you build at -O1 or higher."
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%402528
available and to keep people form having to install yet another library I have added the essential parts of Xmu in
src/video/extensions/XmuStdCmap and an include file in src/video/extensions. The support makes use of standard X11 mechanisms to
create color maps and make sure that an application uses the same color map for each window/visual combination. This should make it
possible for gamma support to be implemented based on a single color map per application.
Hurm... it looks like "make indent" modified a few extra files. Those are getting committed too.
--HG--
extra : convert_revision : svn%3Ac70aab31-4412-0410-b14c-859654838e24/trunk%402509
