* Window creation fails in the colormap code on DirectColor visuals:
* XA_RGB_BEST_MAP not found and could not be created
* I'm disabling this for now until Bob can look at it. We don't need
* it until we implement the gamma fading using DirectColor RGB ramps
*/
From: Couriersud
Subject: 32 & 16 bit versions of blendrect and blendline
attached are 32, 16 and 15 bit versions of the blendrect and blendline
functionality. There was an issue with the bresenham alg. in drawline
which I also fixed.
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.
The API specifies that SDL_OpenAudio() will fill out the 'desired' audio spec
with the correct samples and size set by the driver. This value is important
since it may be used by applications that size audio buffers, etc.
However, we want to allow advanced applications to call SDL_OpenAudioDevice()
which gets passed a const 'desired' parameter, and have the correct data filled
into the 'obtained' parameter, possibly allowing or not allowing format changes.
So... 'obtained' becomes the audio format the user callback is expected to use,
and we add flags to allow the application to specify which format changes are
allowed.
Note: We really need to add a way to query the 'obtained' audio spec.
From: Couriersud
Subject: SDL: Mouse last_x, last_y into SDL_Mouse
the attached diff moves the static vars last_x and last_y into
SDL_Mouse. These, as far as I understand it, should be tied to the
individual mouse.
The patch also makes the code check for out of window conditions of
mouse->x,y when relative movements are passed to MouseSendMotion.
Also attached is the latest DirectFB code (dfb20081208) supporting
multiple mice and keyboards. This works quite well with sdlmame now. It
however needs more testing with different directfb configurations.
correct value for YUV textures. Yay!
I'm still cheering for Ryan's pixel shader instead, since once it works
different shaders can handle all the YUV formats.
From: Couriersud
Subject: SDL: Relative mouse movements
The patch below will reenable processing of relative mouse movements.
The DirectFB drivers generates those in "grabbed" mode. These ensure,
that even in fullscreen mode relative movements are reported. SDLMAME
depends on this for games with trackballs.
Looking at the code I ask myself whether relative movements should be
handled in the drivers (x11, directfb). Both x11 and directfb are able
to report relative movements. This would leave it to the driver to use
the most appropriate method for relative movements when at the border of
a fullscreen window or being "grabbed".
From: Couriersud
Subject: Re: SDL: Keyboard layout unknown
I have attached a diff which will add an additional keyboard layout to
the x11 driver. The issue arose, when I moved to ubuntu intrepid. I was
only able to map the keys available on my keyboard. The differences to
the existing keyboard was the mapping of HOME,UP,DOWN and some other
keys.
Now only one issue remains. Dead keys (e.g. ^, ` ') on european
keyboards do not generate a "scancode" event. Just a text event when the
key is composed (e.g. ?? ?? ??).
Don't try to RLE encode surfaces that have alpha channel and alpha modulation
Don't turn on blending when converting an RGB surface to RGBA format
Do turn on blending when converting colorkey to alpha channel
From: Couriersud
Subject: SDL : Diff for directfb driver
please find attached a diff against SVN containing the following:
- Updated README.DirectFB a bit
- Fix compile issue with debug output
- Fix display mode setting/switching for directfb >= 1.2.2
From: Couriersud
Subject: LPGL and closed-source license / Re: [Bug 607] Texture palette not up
Permission granted to release code under both LPGL and closed-source
commercial license.
Please find attached a minor patch fixing vsync handling in the directfb
driver and containing a small update to README.directfb
One or two things got moved around, but largely this is hooked up correctly
in the Unix configure system now: it can be dynamically loaded and fallback
gracefully if not available, or libXi can be directly linked to libSDL.
XInput support can be --disable'd from the configure script, too (defaults to
enabled).
Please note that while the framework is in place to gracefully fallback, the
current state of the source requires XInput. We'll need to adjust a few
things still to correct this.
Stephen L Moshier wrote:
>
> pow(x,y) returns 0 when x is very close to -1.0 and y is very large.
> The following test program prints
>
> pow(1.0000000000000002e+00 4.5035996273704970e+15) = 2.7182818284590455e+00
> pow(-1.0000000000000002e+00 4.5035996273704970e+15) =0.0000000000000000e+00
> pow(9.9999999999999978e-01 4.5035996273704970e+15) = 3.6787944117144222e-01
> pow(-9.9999999999999978e-01 4.5035996273704970e+15) = 0.0000000000000000e+00
>
> which is incorrect for the negative arguments raised to an odd integer
> power.
>
> -----
> double pow (double, double);
>
> int
> main ()
> {
> double x, y, z;
>
> x = 1.0 + pow (2.0, -52.0);
> y = 1.0 + pow (2.0, 52.0);
> z = pow (x, y);
> printf ("pow(%.16e %.16e) = %.16e\n", x, y, z);
> x = -x;
> z = pow (x, y);
> printf ("pow(%.16e %.16e) = %.16e\n", x, y, z);
> x = 1.0 - pow (2.0, -52.0);
> z = pow (x, y);
> printf ("pow(%.16e %.16e) = %.16e\n", x, y, z);
> x = -x;
> z = pow (x, y);
> printf ("pow(%.16e %.16e) = %.16e\n", x, y, z);
> }
> -----
>
> Here is a patch for newlib/libm/math/epow.c:
Patch checked in and duplicated for ef_pow.c. Thanks.
-- Jeff J.
From: Couriersud
Subject: Re: Updated DirectFB driver for SDL1.3
attached is a patch which brings the directfb driver in line with
current svn. In addition:
* driver now is in line with the structure of the X11 driver.
This adds a couple of files.
* driver now supports relative mouse movements
Using the following sequence
SDL_Init(..:)
SDL_CreateWindow(..., SDL_WINDOW_OPENGL)
SDL_DestroyWindow
SDL_CreateWindow(..., SDL_WINDOW_OPENGL)
SDL will crash in X11_GL_GetVisual. This is due to the fact that
during SDL_DestroyWindow X11_GL_Shutdown was called because the last window
has been closed.
On the next call to SDL_CreateWindow the library is still loaded and only the
memory is reinitialized. Function pointers such as gl_data->glXChooseVisual
will not be reinitialized.
Consequently, SDL will crash due to a NULL pointer access.
The attached patch corrects the behaviour.
From: Couriersud
Subject: Updated DirectFB driver for SDL1.3
please find attached a patch for an updated directfb driver for SDL1.3.
It does now
- properly supported the new input api.
- send unicode text events
- support directfb windows
- support multiple screens
- support hardware YUV scaling for the first YUV texture created.
- support hardware scaling for textures.
- properly interpret streaming access
- support software opengl if one manages to install the mesa directfb
driver (broken/not broken in mesa svn)
Within bugzilla (http://bugzilla.libsdl.org/show_bug.cgi?id=603) there
is another patch which fixes a crash due to GL context creation.
Kind regards,
couriersud
Many-mouse and tablet support
by Szymon Wilczek, mentored by Ryan C. Gordon
Everything concerning the project is noted on the wiki:
http://wilku.ravenlord.ws/doku.php?id=start
http://bugzilla.libsdl.org/show_bug.cgi?id=589
I was going to add the current window to the OpenGL context info, but that
doesn't fix the case where you set the current context to NULL and then set
the current context to the same window it had before.
This also doesn't take into account changes to the window that might affect
the context, such as viewport changing or fullscreen/windowed mode changing.
Any ideas?
working earlier this week.
I added some more trace code to SDL_x11events.c
In SDL_X11opengl.c I modified SDL_GL_GetSwapInterval() so that it returns a pretty good value even if you have the SGI swap extension instead of the MESA swap
extension. I just saved the value you set and return it too you.
is incorrect. The result is that an illegal access is being made in X_PumpEvents when it tries to look up the windows ID of the source of an event. Taking out that
call does not seem to have any effect on the testgl. But, I would be happy if someone else took a look at this problem and found a fix higher up the stack.
From: Calvin Vette
Subject: Fix to compile SDL-1.2 SVN on OS X Leopard
I found I needed to add a conditional check for Leopard to compile
cleanly on 1.2-SVN (20071114):
#include <AudioUnit/AudioUnit.h>
#ifdef AVAILABLE_MAC_OS_X_VERSION_10_5_AND_LATER
#include <AudioUnit/AUNTComponent.h>
#endif
where there is now just:
#include <AudioUnit/AudioUnit.h>
From: Christian Walther
Subject: Re: SDL 1.3 keyboard plan
> 2007-08-18 19:15:51.454 checkkeys[5795] *** _NSAutoreleaseNoPool():
> Object 0x532750 of class NSSelectionArray autoreleased with no pool
> in place - just leaking
This is fixed by the attached patch.
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
From: Couriersud
Subject: fix for audio dsp exit crash / various dfb issues
The current code will crash on exiting an application. The attached diff
fixes the issue.
Prepping for using MMX and SSE intrinsics instead of inline assembly.
.. except for memcpy equivalents which only get faster if they can
exploit the parallelism of loading into multiple SIMD registers. :)
From: Couriersud
Subject: Some SDL1.3 patches
LoadLibrary will call X11_GL_Initialize. If LoadLibrary is called before
a window is created, it will crash since structures are not properly set
up.
From: couriersud arcor.de
To: slouken@libsdl.org
Subject: Directfb driver for SDL1.3
Hi,
the attachment contains a patch for a SDL1.3 directfb driver. It supports:
- Renderer "directfb":
Hardware acceleration as supported by the underlying directfb driver. With a
radeon X850, testsprite2 runs at 50% to 70% of OpenGL (X11, dri) performance.
Also supports hardware accelerated yuv overlays. This must be enabled by sett
ing:
export SDL_DIRECTFB_YUV_DIRECT=1
- Renderer "opengl"
Supports software opengl using mesa opengl (make linux-directfb).
Some more information may be found in README.DirectFB
There will certainly still be some bugs, and there is some debug code around.
When I find some time, I will compile against directfb-0.9.25 as distributed
with ubuntu 7.04.
The diff also contains a fix for SDL_LockYUVOverlay fixing a bug in *pixels
and pitches initialization.
Kind regards,
couriersud
- SDL_Surface is a system memory representation of pixel data
- SDL_Texture is a video memory representation of pixel data
The concept of SDL_Surface with SDL_HWSURFACE is no longer used.
Separated SDL_Texture types by usage rather than memory type
- SDL_TEXTUREACCESS_STATIC is for rarely changed pixel data,
can be placed in video memory.
- SDL_TEXTUREACCESS_STREAMING is for frequently changing pixel
data, usually placed in system memory or AGP memory.
Optimized the SDL_compat usage of the OpenGL renderer by only
using one copy of the framebuffer instead of two.
