Fri, 30 Dec 2011 06:01:09 -0500 Fixed bug 907 - SDL window restore SDL_VIDEORESIZE event issue... SDL-1.2
Sam Lantinga <slouken@libsdl.org> [Fri, 30 Dec 2011 06:01:09 -0500] rev 6124
Fixed bug 907 - SDL window restore SDL_VIDEORESIZE event issue... cjj_009@yahoo.com 2009-12-14 20:32:35 PST I've been working on an SDL/OpenGL program, that among other things, must deal with resizing events in order to adjust the aspect ratio. It doesn't always seem to get the SDL_VIDEORESIZE event when it should, causing the aspect ratio to not be adjusted as needed. I've run it in debug mode and made these observations: *When it initially starts up, if I maximize the window, it receives the SDL_VIDEORESIZE event as needed. *If, after starting up the the application and maximizing the window, I then restore the window by double clicking the title bar, it does NOT receive the SDL_VIDEORESIZE event. *I can repeat the last two steps, and it will get continue to get the SDL_VIDEORESIZE on the maximize but not get one on the restore. *If I then do a slight adjustment to the width or height of the window, it will get the SDL_VIDEORESIZE event. *From then on, if I do restore operations to the window, the SDL_VIDEORESIZE event will be caught properly. See http://forums.libsdl.org/viewtopic.php?t=5291 for additional information. vgvgf 2010-03-28 15:15:16 PDT Proposed patch for SDL_resize.c The width and height values stored in SDL_VideoSurface are the sizes of the video surface when it was created. So, when the window is rezised back to its creation size, the following condition will make the SDL_PrivateResize function stop, and the video resize msg won't be queued. if ( ! SDL_VideoSurface || ((w == SDL_VideoSurface->w) && (h == SDL_VideoSurface->h)) ) { return(0); } Sam Lantinga 2011-12-30 02:59:51 PST I'm okay with applying this patch, but be aware that the expected response to a resize message is that you call SDL_SetVideoMode() again with the new mode. This signals SDL that you're expecting the new size, and there may be other problems if you don't do this.
Fri, 30 Dec 2011 04:04:34 -0500 Added some sanity checks to prevent buffer overflows. SDL-1.2
Ryan C. Gordon <icculus@icculus.org> [Fri, 30 Dec 2011 04:04:34 -0500] rev 6123
Added some sanity checks to prevent buffer overflows. Fixes Bugzilla #1074. (I think.)
Fri, 30 Dec 2011 04:03:31 -0500 Fixed compiler warning for unused variable. SDL-1.2
Ryan C. Gordon <icculus@icculus.org> [Fri, 30 Dec 2011 04:03:31 -0500] rev 6122
Fixed compiler warning for unused variable.
Fri, 30 Dec 2011 03:18:26 -0500 Fixes for setting custom cursor in quartz target. SDL-1.2
Ryan C. Gordon <icculus@icculus.org> [Fri, 30 Dec 2011 03:18:26 -0500] rev 6121
Fixes for setting custom cursor in quartz target. This fixes a logic error, and allows setting the cursor from off the main thread, which isn't strictly a good idea, but previous versions of SDL on Mac OS X apparently allowed it, so we'll make the effort here. Fixes Bugzilla #1355. Thanks to Alexei Svitkine for the patch!
Thu, 29 Dec 2011 13:54:22 -0500 Fixed documentation typo
Sam Lantinga <slouken@libsdl.org> [Thu, 29 Dec 2011 13:54:22 -0500] rev 6120
Fixed documentation typo
Thu, 29 Dec 2011 13:51:42 -0500 Fixed so the header is consistent with the source
Sam Lantinga <slouken@libsdl.org> [Thu, 29 Dec 2011 13:51:42 -0500] rev 6119
Fixed so the header is consistent with the source
Thu, 29 Dec 2011 12:21:49 -0500 Added release notes for SDL 1.2.15 SDL-1.2
Sam Lantinga <slouken@libsdl.org> [Thu, 29 Dec 2011 12:21:49 -0500] rev 6118
Added release notes for SDL 1.2.15
Thu, 29 Dec 2011 11:17:09 -0500 Updated the dist target to include build project directories SDL-1.2
Sam Lantinga <slouken@libsdl.org> [Thu, 29 Dec 2011 11:17:09 -0500] rev 6117
Updated the dist target to include build project directories
Thu, 29 Dec 2011 05:36:39 -0500 Fixes bug 1296 - SDL_SetVideoMode crashes because of unaligned MOVAPS instruction
Sam Lantinga <slouken@libsdl.org> [Thu, 29 Dec 2011 05:36:39 -0500] rev 6116
Fixes bug 1296 - SDL_SetVideoMode crashes because of unaligned MOVAPS instruction 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
Thu, 29 Dec 2011 05:18:16 -0500 Fixed bug 1338 - Direct3D renderer should set D3DCREATE_FPU_PRESERVE for not behaving vastly different on doubles (causes 3rd party lib crashes!)
Sam Lantinga <slouken@libsdl.org> [Thu, 29 Dec 2011 05:18:16 -0500] rev 6115
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)
(0) -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 tip