Sam Lantinga <slouken@libsdl.org> [Sat, 31 Jan 2004 06:49:18 +0000] rev 796
*** empty log message ***
Sam Lantinga <slouken@libsdl.org> [Thu, 29 Jan 2004 16:15:12 +0000] rev 795
Check for altivec assembly support before trying to use it. :)
Sam Lantinga <slouken@libsdl.org> [Thu, 29 Jan 2004 16:14:09 +0000] rev 794
Updated for the latest version of automake
Sam Lantinga <slouken@libsdl.org> [Thu, 29 Jan 2004 05:22:23 +0000] rev 793
Altivec detection on non-MacOS X systems
Sam Lantinga <slouken@libsdl.org> [Thu, 29 Jan 2004 04:39:08 +0000] rev 792
Added an exports target so I can make the exports all at once. :)
Sam Lantinga <slouken@libsdl.org> [Thu, 29 Jan 2004 04:35:51 +0000] rev 791
*** empty log message ***
Sam Lantinga <slouken@libsdl.org> [Wed, 28 Jan 2004 22:01:02 +0000] rev 790
Date: Wed, 28 Jan 2004 20:25:54 +0100
From: Thomas Jarosch
Subject: Re: [SDL] DSPF_RBG15 in src/video/directfb/SDL_DirectFB_video.c
In my local DirectFB 0.1.19 copy, DSPF_RGB15 is an alias for DSPF_ARGB1555.
They seem to have it removed in DirectFB CVS.
As DSPF_RGB15 was only an alias, the attached patch
can safely be applied to SDL and won't brake older DirectFB versions.
Sam Lantinga <slouken@libsdl.org> [Wed, 28 Jan 2004 01:57:34 +0000] rev 789
Date: Wed, 28 Jan 2004 02:37:04 +0100
From: Max Horn
Subject: Small libtool patch (framework related)
here is a small patch for ltmain.sh. It corrects a problems with the
libSDL.la file, which prevented applications using a version of libtool
w/o framework support (read: all currently released libtool version) to
not being able to link with SDL anymore. I also notified the libtool
maintainers, as the same problem exists in libtool CVS.
Sam Lantinga <slouken@libsdl.org> [Mon, 26 Jan 2004 06:33:27 +0000] rev 788
Updated Project Builder projects
Sam Lantinga <slouken@libsdl.org> [Sat, 24 Jan 2004 15:55:00 +0000] rev 787
Date: Sat, 24 Jan 2004 14:49:58 +0100
From: Stephane Marchesin
Subject: Re: [SDL] 3DNow! detection on a P4 system
Well... I found another bug : 3dnow was detected on P2/P3 cpus. So I
took one more look at the code and found a mistake in
CPU_getCPUIDFeaturesExt :
The condition for having extended cpuinfo is that when we query extended
cpuinfo we get a result >= 0x80000001. So we must exit if eax < 0x80000001.
The attached patch does that.