(See mailing list message with subject "Streaming textures not properly initialized?")

The render viewport is automatically re-centered when the window changes size, so applications that don't care will not have to handle recalculating their rendering coordinates.

Fixed API for drawing and filling multiple rectangles - the parameter should be an array of rects, not an array of pointers to rects.

Fixed API for updating window rects for consistency with other APIs - the order is pointer to array followed by count in array.

On 02/12/2011 01:44 PM, Sam Lantinga wrote:
> BTW, you probably want to nuke the NDS renderer and just implement these three
> functions instead:
>     int (*CreateWindowFramebuffer) (_THIS, SDL_Window * window, Uint32 *
> format, void ** pixels, int *pitch);
>     int (*UpdateWindowFramebuffer) (_THIS, SDL_Window * window, int numrects,
> SDL_Rect * rects);
>     void (*DestroyWindowFramebuffer) (_THIS, SDL_Window * window);

Patch attached. The renderer for the DS is not used anymore, but I left the
file in place if someone wants to finish it.

I've also added a README.ds and fixed the spinlocks.

Fixed creating render texture framebuffer.
Removed the need for palette watch, added surface format caching.
Added an SDL_DONTFREE flag so you can't free the window and 1.2 shadow surfaces.

The following patch fixes some of the bitrot for the Nintendo DS port.
The support is still basic at the moment, but it allows to run the "general"
test under the current head of tree (parent: 5269:11bd1585efb5 tip).
Most of the patch is mine, but I integrated a couple changes that John
Magnotti posted on Feb 1st.

Prefer the OpenGL ES 2.0 context when it's available, make it possible to create an OpenGL 2.0 context on iPhoneOS

This compiles, but it untested.

attached is a working directfb driver diff which works with the current
changes. There are a number of changes around it as well, e.g.
configure.in.

The directfb renderdriver right now still depends on a some "includes"
from src/video/directfb. That's why it is not yet moved to the new
render folder.

--HG--
rename : src/render/direct3d/SDL_d3drender.c => src/render/direct3d/SDL_render_d3d.c
rename : src/render/opengl/SDL_renderer_gl.c => src/render/opengl/SDL_render_gl.c
rename : src/render/opengles/SDL_renderer_gles.c => src/render/opengles/SDL_render_gles.c
rename : src/render/software/SDL_renderer_sw.c => src/render/software/SDL_render_sw.c
rename : src/render/software/SDL_renderer_sw_c.h => src/render/software/SDL_render_sw_c.h

Added a way to get a framebuffer interface for a window, and also a way to create a software renderer for an arbitrary surface.
The software renderer has been re-routed to use the framebuffer interface, which makes it possible to have software rendering available even on simple ports.

This allows me to reduce the set of formats supported by the renderers to the most optimal set, for a nice speed boost.

--HG--
rename : src/video/SDL_yuv_mmx.c => src/render/SDL_yuv_mmx.c
rename : src/video/SDL_yuv_sw.c => src/render/SDL_yuv_sw.c
rename : src/video/SDL_yuv_sw_c.h => src/render/SDL_yuv_sw_c.h
rename : src/video/mmx.h => src/render/mmx.h

Moved the rendering code out to a separate directory in the hope that it can someday be completely decoupled from the rest of the library and be expanded to an awesome 2D on 3D library.

--HG--
rename : src/video/windows/SDL_d3drender.c => src/render/direct3d/SDL_d3drender.c
rename : src/video/SDL_renderer_gl.c => src/render/opengl/SDL_renderer_gl.c
rename : src/video/SDL_renderer_gles.c => src/render/opengles/SDL_renderer_gles.c
rename : src/video/SDL_renderer_sw.c => src/render/software/SDL_renderer_sw.c