- 09 Mar, 2011 8 commits
-
-
Sam Lantinga authored
Slightly speeded up event history processing each frame
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
- 08 Mar, 2011 5 commits
-
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
- 07 Mar, 2011 25 commits
-
-
Sam Lantinga authored
-
Sam Lantinga authored
Jesse Anders 2011-03-05 23:30:09 PST It seems that in Windows XP, setting SDL_GL_ACCELERATED_VISUAL to 1 actually disables hardware acceleration and puts OpenGL in software mode. In the source code, the corresponding WGL attribute is first set here: *iAttr++ = WGL_ACCELERATION_ARB; *iAttr++ = WGL_FULL_ACCELERATION_ARB; Later, this code: if (_this->gl_config.accelerated >= 0) { *iAttr++ = WGL_ACCELERATION_ARB; *iAttr++ = (_this->gl_config.accelerated ? WGL_GENERIC_ACCELERATION_ARB : WGL_NO_ACCELERATION_ARB); } Sets it again if SDL_GL_ACCELERATED_VISUAL has a value other than the default. More importantly, the documentation I found states that WGL_GENERIC_ACCELERATION_ARB asks for an MDC driver, which, although I don't know much about this topic, doesn't seem like the correct choice here. As mentioned previously, the end effect is that requesting hardware acceleration in Windows XP actually forces the renderer into software mode (on my system at least), which I'm guessing isn't the desired behavior.
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
Removed the NDS hack for ARGB1555 surfaces, since it's a general problem; added full color expansion for 16 bpp packed pixels.
-
Sam Lantinga authored
Fixed bitmap order interpretation; SDL defaults to MSB ordering so a bitstream corresponds to a pixel stream. The bitmap ordering is defined such that the numbering refers to the pixel index from left to right, and the number position refers to the bit position in the byte. SDL_BITMAPORDER_4321 is the fourth pixel at the high bit and the first pixel at the low bit (LSBFirst) SDL_BITMAPORDER_1234 is the first pixel at the high bit and the fourth pixel at the low bit (MSBFirst)
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
-
Sam Lantinga authored
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 ?
-
- 05 Mar, 2011 1 commit
-
-
Sam Lantinga authored
-
- 01 Mar, 2011 1 commit
-
-
Sam Lantinga authored
-