Frank Zago to SDL
There's also a patch to adapt one test for the nds, and that adds several
makefiles to compile these tests. Whenever you apply it, could you completely
remove the test/nds-test-progs/sprite and test/nds-test-progs/sprite2
directories ?
Removed misleading hide/unhide Cocoa notifications.
We have no way of knowing when a Cocoa window is maximized and then restored (right?)
Disabled spamy mouse motion events by default.
Common.c now destroys the SDL_Window upon a SDL_WINDOWEVENT_CLOSE event to ensure that all windows get closed properly and the new code to handle the last window closes gets executed.
* Added display parameter to many internal functions so video modes can be set on displays that aren't the public current one.
* The fullscreen mode is associated with fullscreen windows - not displays, so different windows more naturally have a mode associated with them based on their width and height. It's no longer necessary to specify a fullscreen mode, a default one will be picked automatically for fullscreen windows.
From: Couriersud
Subject: Re: Aw: Experience using SDL1.3 in sdlmame/Proposal for api additions
> For consistency you'd probably want:
> SDL_SetRenderDrawColor(Uint8 r, Uint8 g, Uint8 b, Uint8 a);
> SDL_SetRenderDrawBlendMode(SDL_BlendMode blendMode);
> SDL_RenderLine(int x1, int y1, int x2, int y2);
> SDL_RenderFill(SDL_Rect *rect);
>
> You probably also want to add API functions query the current state.
>
I have implemented the above api for the opengl, x11, directfb and
software renderers. I have also renamed *TEXTUREBLENDMODE* constants to
BLENDMODE*. The unix build compiles. The windows renderer still needs to
be updated, but I have no windows development machine at hand. Have a
look at the x11 renderer for a sample.
Vector games now run at 90% both on opengl and directfb in comparison to
sdlmame's own opengl renderer. The same applies to raster games.
The diff also includes
a) Changed XDrawRect to XFillRect in x11 renderer
b) A number of changes to fix blending and modulation issues in the
directfb renderer.
From: Sam Lantinga
Subject: SDL 1.3 keyboard plan
After lots of discussion with Christian, this is what we came up with:
> So, to sum up...
> SDLK_* become the physical keys, starting at > (1<<21)
> We create a macro SDLK_INDEX(X)
> We have two functions SDL_GetLayoutKey(SDLKey) and SDL_GetKeyName()
> SDL_GetLayoutKey maps to UCS4 for printable characters, and SDLK* for
non-printable characters
> and does so based on the OS's current keyboard layout
> SDL_GetKeyName() handles both SDLK_* and UCS4, converting UCS4 to UTF-8 and
converting SDLK_* into our names, which are UTF-8 for printable characters.
> WASD folks use SDLK_*, and 'I' folks use SDL_GetLayoutKey(SDLK_*)
Here is the patch he came up with, and his e-mail about it:
Date: Fri, 17 Aug 2007 19:50:28 +0200
From: Christian Walther
Subject: Re: SDL 1.3 keyboard plan
> Sounds great, go ahead and send me a patch.
Here goes! Thanks for having a look. Don't hesitate to comment if
anything does not conform to your ideas.
One caveat: Committing this now may break compilability of some video
drivers - specifically, if they use any of the SDLK_* codes that were
obsoleted and moved into SDL_compat.h. I only tried Cocoa (which did
break, but is already fixed) and X11 (which didn't, but then its key
handling is #iffed out). If that's a problem, it may need to go into
a branch.
-Christian
available and to keep people form having to install yet another library I have added the essential parts of Xmu in
src/video/extensions/XmuStdCmap and an include file in src/video/extensions. The support makes use of standard X11 mechanisms to
create color maps and make sure that an application uses the same color map for each window/visual combination. This should make it
possible for gamma support to be implemented based on a single color map per application.
Hurm... it looks like "make indent" modified a few extra files. Those are getting committed too.
