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.

--HG--
rename : src/video/SDL_blendline.c => src/render/software/SDL_blendline.c
rename : src/video/SDL_blendpoint.c => src/render/software/SDL_blendpoint.c
rename : src/video/SDL_draw.h => src/render/software/SDL_draw.h
rename : src/video/SDL_drawline.c => src/render/software/SDL_drawline.c
rename : src/video/SDL_drawpoint.c => src/render/software/SDL_drawpoint.c

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

The rendering functions take a context so it's clear what window they're drawing to.  This also potentially opens to the door to multi-threaded rendering in the future.

Making the API simpler, the renderer present semantics are always having a backbuffer and then discarding it.  This is best for hardware accelerated rendering.

--HG--
extra : rebase_source : bbe6641fce097c79ccd47f4e1ea6b27683fd0acb

--HG--
extra : rebase_source : 880752438aae8f6526503d220bad91aabc3a7d1c

--HG--
extra : rebase_source : f06ea01caa64c8ad14170c723e5af52dad64d779

--HG--
extra : rebase_source : d00f0590e133604070f978762a6728b4afde02ca

Making the API simpler, scaling is always defined as linear interpolation and should be supported as much as possible on all renderers.

--HG--
extra : rebase_source : 4edac7fd162a2eb37a50159b958db37a03e944a5

--HG--
extra : rebase_source : 3fc2560c02393bf9e7c46360fc24f2585c9409be

 Vittorio Giovara      2011-02-01 02:25:48 PST

i have attached an updated patch that fixes this behaviour

 Vittorio Giovara      2011-02-01 02:21:50 PST

with the attached patch, the opengles context will always use the maximum
screensize available; this is particularly useful for supporting retina display
on latest iphone.

please note: Apple documentation warns that using the "upscaled" gl context
actually uses more memory and bandwitdh, so it might be worth to let the user
decide whether to disable it or not, either with a flag or a sdl function...