t.grundner@goto3d.de 2011-09-01 03:59:17 PDT
I figured out what is going on. GCC 4.5.2 assumes the stack is 16 byte aligned
by default. Therefore there are no AND alignment corrections necessary if we
wish to align a stack variable to a 16 byte boundary. That is bad if your OS
ABI is not 16 byte aligned. Windows 32 bit stacks are 4 byte aligned. This
results in the above mentioned SIGSEGV. This is also no problem if I compile
both SDL.dll and my app with MingW because MinGW/GCC inserts a

        andl    $-16, %esp

instruction right in the beginning of the main function. So at least the stack
of the thread calling the main function is 16 byte aligned. But as soon as I
start to use the SDL.dll from an application not compiled by MinGW there is no
ANDL safing my app.

However there is a GCC option that can change the default stack alignment:

        -mpreferred-stack-boundary=num

Setting num=2 assumes a the stack is aligned to a 4 byte boundary. This results
in GCC inserting the necessary

        andl    $-16, %esp

into SDL_FillRect. Rebuilding SDL with

       ./configure "CFLAGS=-mpreferred-stack-boundary=2 -g -O3"

solved the problem.

IMHO this should also be a problem on Solaris.

The following links contain further information:

http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options

http://www.agner.org/optimize/calling_conventions.pdf

Fixed bug 1338 - Direct3D renderer should set D3DCREATE_FPU_PRESERVE for not behaving vastly different on doubles (causes 3rd party lib crashes!)

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)

Gueniffey 2011-11-23 04:11:31 PST

The attached simple patch adds a timestamp to all SDL events. It is useful to
dismiss old events and add UI responsiveness (my application does some
extensive tasks that creates a delay in the event queue handling. With this
patch, I can deal only with the most recent events.

Gueniffey 2011-11-23 04:06:31 PST

The attached patch adds native support for
SDL_PIXELFORMAT_ARGB8888, SDL_PIXELFORMAT_RGB888, SDL_PIXELFORMAT_BGR888

Thanks to Dimiter 'malkia' Stanev for the fix!

Fixes build.

Better fix, iterate backwards over the array so we don't care whether the close code shuffles things down.

Thanks to Vittorio Giovara for the patch!

First pass at a simple drag and drop API, allowing you to accept files dropped into your application.

This way subclasses can use it without a lot of casting.

Thanks to Vittorio Giovara for the patch!

Thanks to Vittorio Giovara for the patch!

Thanks to Vittorio Giovara for the patch!

This isn't strictly needed by SDL, but it's a good example for other projects.

Fixed where we set the content scale - it's used by the renderbufferStorage:GL_RENDERBUFFER_OES call.

Thanks to Marcus von Appen for the patch!

In landscape mode the frame stays the same, and the transform property is modified with the appropriate rotation.
The touch coordinates are rotated by the transform, so if I want to normalize them by the frame rect, I have to transform the frame rect first.

To answer the FIXME, no, we shouldn't force this.  The fullscreen flag implies borderless behavior even though the flag isn't set on the window (in case fullscreen is toggled)

The iOS driver sets the fullscreen and shown flags on the window during creation, so we need the mode code to be aware of that, since none of the other fullscreen/shown code paths get run.
FIXME: Maybe we need a better way of detecting that?