Matthew Orlando to Sam
Someone asked in IRC whether they should free the surface from SDL_GetWindowSurface. The doc comment is a bit vague so i checked the code and revised the comment.
Implemented thread priority as the 'nice' value on Linux. High priority threads require root permissions (you shouldn't give your game root permissions though!)
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)
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 ?
Edgar Simo 2011-02-20 10:27:52 PST
Adding patch that adds a simplified API for the haptic subsystem built ontop of
the "real one" for those who want simple rumble without jumping through hoops.
Adds 4 functions:
- extern DECLSPEC int SDLCALL SDL_HapticRumbleSupported(SDL_Haptic * haptic);
- extern DECLSPEC int SDLCALL SDL_HapticRumbleInit(SDL_Haptic * haptic);
- extern DECLSPEC int SDLCALL SDL_HapticRumblePlay(SDL_Haptic * haptic, float
strength, Uint32 length );
- extern DECLSPEC int SDLCALL SDL_HapticRumbleStop(SDL_Haptic * haptic);
Also provided is test/testrumble.c which does test this.
This has all been tested on linux and has worked, but due to being built ontop
of the other haptic API it should work on all OS the same.
Even if we're blitting between two different surfaces their pixels might still overlap, because of SDL_CreateRGBSurfaceFrom(), so always use SDL_BlitCopy() and check for overlap in that function.
When handling overlapping surfaces, don't assume that memcpy() iterates forward, instead use memmove() correctly, and provide a fallback implementation of SDL_memmove() that handles the different cases.
Fixed a bug with SDL_memset() not completely filling lengths that aren't a multiple of 4.
Optimized SDL_memcpy() a bit using the same technique as SDL_memset().
The trick is that if you're using configure and you don't want to have SDL_config.h and SDL_revision.h to show up as modified, you need to configure and build from a separate directory.
You also need to include SDL_revision.h directly if you want to use the SDL_REVISION constant, as a side effect of these changes.
--HG--
rename : include/SDL_config.h.default => include/SDL_config.h
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.
