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.
"Mac OS X/x86 won't build the MMX/YUV inline assembly without optimizations
enabled (not enough registers), so for now, we only build it if we see
the __OPTIMIZE__ #define, which GCC provides when you build at -O1 or higher."
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.
(This already had a concession for devices opened via the 1.2 entry points,
I've changed it to respect the environment variable and do it for all devices
now.)
I'm not entirely happy with them. Maybe the right way to go is to leave
SDL_iconv() taking a non-const inbuf? How often are we converting const
strings anyway?
From: "Eyal Lotem"
To: "SDL Mailing List" <sdl@lists.libsdl.org>
Subject: [SDL] Bug in GL_SWAP_CONTROL extension name.
The checked extension name is incorrect.
The attached patch fixes it to the correct name.
I don't think that under any setup, this extension name was ever
correct, which is why its not OR'd against the old check.
This fixes the "tear effect" (vsync problems) I had here with nVidia
GLX drivers.
Eyal
bitshift an Sint64, but it can't find this function since we don't use the
C runtime on Windows.
Division doesn't have this problem, though. Strange.
Thanks, Suzuki Masahiro.
