Jonas Thiem 2011-11-29 12:28:02 PST
Direct3D renderer should set D3DCREATE_FPU_PRESERVE for not behaving vastly
different to OpenGL/software rendering on doubles and break some libraries
really badly.
Most notable affected example: Lua, which does the most unpredictable things
which are really almost impossible to debug/find out for beginners who never
heard this culprit exists.
Since I believe all renderers should behave the same on that doubles simply
work as expected in a program, this should really be changed! (also this wasted
a few days of my life wondering why everything in my program was so broken)
Frank Zago to SDL
I've cleaned up a few bugs in the nds code. A few more tests now pass.
There's still a few things to do, but overall I think it's starting to be in a
good shape.
The patch also includes a bug fix for SDL_ConvertSurfaceFormat() (gcc warning).
Frank Zago to SDL
For those interested, here's a snapshot of the current port. I did away with
most of the previous attempt which was based of the sprite engine, because the
support is limited to 128 64x64 sprites. Instead I'm using the gl engine.
The drawback is that either the frame buffer or the gl engine can be used
because there's not that much video memory on a DS.
With minimal changes to their code, it can now run the following tests: ,
testspriteminimal, testscale and testsprite2. The last 2 only run under the
emulator for some reason. The tests are not included in this patch for size
reason.
In 16 bits mode, the 16th bit indicated transparency/opacity. If 0, the color
is not displayed. So I had to patch a few core file to set that bit to 1. See
patch for src/video/SDL_RLEaccel.c and src/video/SDL_blit.h. Is that ok, or is
there a better way ?
The nds also doesn't support windowed mode, so I force the fullscreen in
src/video/SDL_video.c. Is that ok, or is there a better way ?
To get a smaller library, I also tried to not compile the software renderer
when the hardware renderer is compiled in, and define SDL_NO_COMPAT; however
the compilation eventually fails in SDL_surface.c because SDL_SRCCOLORKEY is
defined in SDL_compat.h. Is SDL_NO_COMPAT only for application and not SDL
itself ?
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.
There's a new event that's always sent when the window changes size, and that event is what the renderers listen for to determine if they need to rebind their context.
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.
