We now do FULL or NO accel based on the app's preference. If the app didn't
specify, we do FULL then fall back to NO.
(Not specifying anything--a true "don't care" scenario--breaks some ATI
drivers, so we try to keep to the spirit of it while forcing a specific
state.)
Previously, it would always do FULL, and try NO if it failed and the app
had requested NO or DONTCARE.
This is a transplant of hg changesets a04171d6fa11 and d0b7c45e982e from the
SDL-1.2 branch.
Fixes Bugzilla #1254.
--HG--
extra : rebase_source : db951d96e685e17a4d71fe2aa3d65043661ccccc
Nitz
In Function X11_DispatchEvent(_THIS), case SelectionNotify :
static void
X11_DispatchEvent(_THIS)
{
// Some Code
case SelectionNotify: {
//Some Code
SDL_bool expect_lf = SDL_FALSE;
char *start = NULL; // Initialised with NULL
char *scan = (char*)p.data;
char *fn;
char *uri;
int length = 0;
while (p.count--) {
if (!expect_lf) {
if (*scan==0x0D) {
expect_lf = SDL_TRUE;
} else if(start == NULL) {
start = scan;
length = 0;
}
length++;
} else {
if (*scan==0x0A && length>0) {
uri = malloc(length--);
memcpy(uri, start, length); // Problem is Here, start is still NULL if control comes to else statement without initialising the start pointer, which is wrong
uri[length] = 0;
fn = X11_URIToLocal(uri);
if (fn) SDL_SendDropFile(fn);
free(uri);
}
expect_lf = SDL_FALSE;
start = NULL;
}
scan++;
}
}
As shown above how start pointer remains NULL, Patch for this issue would be:
if (*scan==0x0D) {
expect_lf = SDL_TRUE;
}
if(start == NULL) {
start = scan;
length = 0;
}
Just replace else if statement with if.
This ensures that we only no-op redundant calls if they're made on the
same thread as the last MakeCurrent with those arguments. This should
maek SDL behave better with multithreaded environments.
This code was written almost 2 years ago, and the flag hasn't been
changed since. Cleaning up the code by removing the conditional blocks,
so that they behave the same way they have for the past two years.
FULLSCREEN_TOGGLEABLE used to cause us to use
-[NSOpenGLContext setFullScreen] and a pixel format with
NSOpenGLPFAFullScreen.
Kang Seonghoon
While BMP format supports alpha channel, it is enabled only when the header is at least 56 bytes long (BITMAPV3INFOHEADER and later). For very common 40-byte-long header (BITMAPINFOHEADER) 32bpp format should be interpreted as BGRX format, but currently SDL interprets them as BGRA format and causes a significant compatibility problem as many 32bpp files use a padding byte of 0 ("transparent" in BGRA interpretation).
---
I fixed this by checking to see if the alpha channel is all 0, and if so, setting it opaque.
Kang Seonghoon
While BMP format supports alpha channel, it is enabled only when the header is at least 56 bytes long (BITMAPV3INFOHEADER and later). For very common 40-byte-long header (BITMAPINFOHEADER) 32bpp format should be interpreted as BGRX format, but currently SDL interprets them as BGRA format and causes a significant compatibility problem as many 32bpp files use a padding byte of 0 ("transparent" in BGRA interpretation).
Sylvain
1/ Load an Image XPM with IMG_ReadXPMFromArray()
2/ Try to set a ColorKey on it.
I notice that :
- the SDL_Surface that is created from XPM has a palette !
- the colorkey is a RBG.
it crashes (SIGSEGV) inside the SDL_SetColorKey function:
"surface->format->palette->colors[surface->map->info.colorkey].a"
Vittorio Giovara
I find that the calling point in SDL_uikitappdelegate.m is dangerous as the -(void) postFinishLaunch method can be overridden when subclassing.
Could this be moved in inside the init or in the didFinishLaunchingWithOptions method which are always called even when subclassed?
Having the SDL functions inline is causing build issues, and in the case of malloc(), etc. causing malloc/free mismatches, if the application build environment differs from the SDL build environment.
In the interest of safety and consistency, the functions will always be in the SDL library and will only be redirected to the C library there, if they are available.
See the following threads on the SDL mailing list for the gruesome details:
* SDL_stdinc.h inlines problematic when application not compiled in exact same feature environment
* Error compiling program against SDL2 with -std=c++11 g++ flag
Philipp Wiesemann
SDL_Keysym contains a deprecated field for unicode which may be removed for SDL 2.0 release.
As far as I can tell the field is not set on all "major" platforms and therefore will not be useful for most users. Its existence in a public header therefore becomes (in my opinion) only confusing.
buckyballreaction
On some Windows systems, when switching from fullscreen to windowed mode in my game, the CPU will spike and the application never shows the window again.
See the part of the e-mail thread here:
http://lists.libsdl.org/pipermail/sdl-libsdl.org/2013-June/088626.html
I change the window by calling:
SDL_SetWindowFullscreen(gScreenInfo.sdlWindow, SDL_FALSE);
SDL_SetWindowSize(gScreenInfo.sdlWindow, sdlWindowWidth, sdlWindowHeight);
which you can see in our source:
https://code.google.com/p/bitfighter/source/browse/zap/VideoSystem.cpp#377
Then all of a sudden the application gets stuck in WIN_PumpEvents() in SDL_windowsevents.c. I turned on WMMSG_DEBUG and found that there was an endless stream of WM_EVENT messages. I also found that where WM_PAINT is being handled in the callback WIN_WindowProc(), ValidateRect is somehow not clearing, or it is persisting, the WM_EVENT message like it's supposed to (according to the docs).
This may be a hardware issue. The issue has appeared on three different systems, one of them sporadically:
- Windows XP SP3 running in VMware 9.0 (without VMWare 3D acceleration, but with the tools and drivers installed), Host: openSUSE 12.3 x86_64, NVidia NVS 3100M
- Windows XP SP3 64bit running in VirtualBox, Host: Debian Wheezy (stable), Mobility Radeon HD 4100 (this was the sporadic one)
- Windows 7 64 bit, Radeon 6770
This will help reduce issues like that reported in bug 1819:
Wouter van Oortmerssen 2013-04-23 20:12:07 EDT
#0 0x01d1e881 in __HALT ()
#1 0x01c58971 in _CFRuntimeCreateInstance ()
#2 0x02e4acc1 in GSFontCreateWithName ()
#3 0x00adc0e1 in UINewFont ()
#4 0x00adc24c in +[UIFont systemFontOfSize:traits:] ()
#5 0x00adc298 in +[UIFont systemFontOfSize:] ()
#6 0x009fb5d9 in +[UITextFieldLabel defaultFont] ()
#7 0x00a8ccd5 in -[UILabel _commonInit] ()
#8 0x00a8ce14 in -[UILabel initWithFrame:] ()
#9 0x00a052eb in -[UITextField createTextLabelWithTextColor:] ()
#10 0x009fbede in -[UITextField initWithFrame:] ()
#11 0x00152ead in -[SDL_uikitview initializeKeyboard] at /Users/aardappel/lobster/external/SDL-2.0.0-7046/Xcode-iOS/SDL/../../src/video/uikit/SDL_uikitview.m:208
#12 0x0015290c in -[SDL_uikitview initWithFrame:] at /Users/aardappel/lobster/external/SDL-2.0.0-7046/Xcode-iOS/SDL/../../src/video/uikit/SDL_uikitview.m:50
#13 0x00153b5b in -[SDL_uikitopenglview initWithFrame:scale:retainBacking:rBits:gBits:bBits:aBits:depthBits:stencilBits:majorVersion:] at /Users/aardappel/lobster/external/SDL-2.0.0-7046/Xcode-iOS/SDL/../../src/video/uikit/SDL_uikitopenglview.m:53
#14 0x001524ff in UIKit_GL_CreateContext at /Users/aardappel/lobster/external/SDL-2.0.0-7046/Xcode-iOS/SDL/../../src/video/uikit/SDL_uikitopengles.m:114
#15 0x0015078f in SDL_GL_CreateContext at /Users/aardappel/lobster/external/SDL-2.0.0-7046/Xcode-iOS/SDL/../../src/video/SDL_video.c:2666
#16 0x000d8c5c in SDLInit(char const*, vec<int, 2>&) at /Users/aardappel/lobster/dev/xcode/lobster/../../src/sdlsystem.cpp:193
This fixes an issue where we were using the wrong macros to extract the position from WM_MOUSEMOVE, so negative values were behaving incorrectly.
These would be generated in multimon situations, or if you use SetCapture.
Fixes http://bugzilla.libsdl.org/show_bug.cgi?id=1175
We get an WM_MOUSELEAVE when we switch to relative mode, even though the cursor is still in the window.
Ignoring this event to not end up with a NULL mouse focus.
This fixes http://bugzilla.libsdl.org/show_bug.cgi?id=1861
Alex Szpakowski
When calling SDL_SetWindowPosition(window, SDL_WINDOWPOS_CENTERED, SDL_WINDOWPOS_CENTERED), the window moves to the correct position but it seems to internally set its x/y position values to the literal value of the SDL_WINDOWPOS_CENTERED define.
This causes all sorts of problems when SDL functions which use the window position (e.g. SDL_SetWindowGrab) are called after the aforementioned SDL_SetWindowPosition call.
Looking at the SDL_SetWindowPosition code, it seems that SDL_SendWindowEvent with the SDL_WINDOWEVENT_MOVED event is called at the end of the function using the literal value of the SDL_WINDOWPOS_CENTERED define, instead of the newly set window->x and window->y values.
SDL_SendWindowEvent then sets the values of window->windowed.x and window->windowed.y to that value (0x2FFF0000, aka 805240832.)
I have attached a patch which changes SDL_SetWindowPosition to make sure SDL_SendWindowEvent is called with the correct coordinate values, if SDL_WINDOWPOS_CENTERED is used (fixes the issue for me.)
Tested with Mac OS 10.8.3.
