From: Christian Walther
Subject: SDL 1.3 Xcode projects
Here are my promised updates to the Xcode projects. They work as far
as I'm using them, but I have not tested them thoroughly, and there
may still be some cruft left. In particular, I haven't checked whether
the frameworks still work on older versions of Mac OS X (are we still
targeting 10.2?), and whether Altivec/SSE optimizations are properly
done. Of note: I incremented the framework version to B to enable SDL
1.2 and 1.3 to coexist in a single framework.
Let me know if you see any problems.
Greetings
Christian
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
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. :)
- 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.
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?
On tracing it turns out to fail from SDL_WM_SetCaption()
On going through the function it looks like the SDL_free() function is called
every alternate time with an invalid pointer that has already been freed.
display, which is a fast path used for the whole-surface SDL 1.2 API.
Solved the flicker problems by implementing a backbuffer in the GDI renderer.
Unfortunately, now using the GDI renderer with a backbuffer and HBITMAPs is
significantly slower than SDL's surface code. *sigh*
Added DirectInput joystick code, contributed by Glenn Maynard.
This fixes a problem with the Windows Multimedia joystick driver
not showing all 6 axes on a GameCube controller converter, which
was donated by Jacob Kolding.
Currently there are two Classic-only drivers defined in "SDL_config_macos.h",
and the ones in "SDL_config_macosx.h" are Mach-O/framework-only (i.e. not CFM)
As a workaround, I disabled CDROM and JOYSTICK when building SDL for CFM
Carbon.
The current SVN trunk is missing the SDLCALL specifier at numerous locations.
It has to be added for all (possibly user provided) callbacks.
I stumbled over this while creating a makefile for the OpenWatcom compiler for
Win32.
- A change to define CXX in fatbuild, which comforts the configure script a little, even if we don't use C++ anywhere.
- Some code to see how many CPU cores exist and parallelize make across them.
- CFLAGS that apply to both archs are specified seperately (-O3, -pipe, etc)
- -fvisibility=hidden for the gcc4 builds
- a "clean", "clean-ppc" and "clean-x86" command
- Fix to SDL_config_macosx.h for the HAVE_ALLOCA_H thing.
Now builds on an Intel Mac.
The SDL platform header shouldn't dictate the OS target API for other
applications. The build system should define the target API for building
SDL internally.
[I'm fixing this for the public headers, but I'm not going to bother for the SDL library code (yet)]
To clarify: Normaly, GCC (or, to be precise, the preprocessor) will ignore
this, and compile the code happily. However, one can specify -Wundef to get a
warning about this.
One can probably argue whether to consider this a bug or not; but I think that
(a) from a semantic point of view, using "#if FOO" when FOO is not defined is
strange, and (b) since it is possible to trigger a warning about this, and a
trivial fix exists, it should be corrected.
I can think of two alternative patches, BTW:
1) Simply use #define HAVE_FOO 0, instead of not defining HAVE_FOO at all
2) Change
#if HAVE_FOO
to
#if HAVE_FOO+0
which always does the right thing.
But I think I still prefer the attached patch :-).
The proper name of Apple's operating system is "Mac OS X" not "MacOS X", as can
bee seen in many places, for example http://www.apple.com/macosx/). This
contrasts the naming of the old operating system, which was called "MacOS" and
today is often refered to as "MacOS Classic".
The attached patches fixes the misuse of the name "MacOS X" in both the SDL12
and sdlweb CVS modules.
The current definition of int32_t, uint32_t, uintptr_t
doesn't match what the Mac system headers already have...
Since it's an old 16/32 bit platform, the system headers
expect the types to use "long" and not "int" like they do.
When switching to "UNIX-style paths" as needed for the new includes,
including <GL/gl.h> and <GL/glu.h> doesn't work anymore on Mac OS...
The two headers are really located in the OpenGL SDK 1.2 CFM like this:
OpenGL:Headers:gl.h
OpenGL:Headers:glu.h
There are also some compat copies, that *used* to work with Mac paths:
OpenGL:Headers:GL/gl.h
OpenGL:Headers:GL/glu.h
The easiest fix is to make SDL_opengl.h include the proper header names,
by adding a special case for the MACOS platform in addition to the MACOSX
SDL_config.h is no longer in CVS. Instead, configure will generate it for
systems that use configure, and we always copy SDL_config.h.default to
SDL_config.h before generating a snapshot or release archive.
Also fixed a couple of uninstall issues.
Integrated most of the NetBSD and DragonFly patches at:
ftp://ftp.netbsd.org/pub/NetBSD/packages/pkgsrc/devel/SDL/patches/
Thanks to Thomas Klausner for defailed information on the patches
fixed bugs 159 and 160:
+ added threaded timers support
! fixed restoring sdl window focus (AV in windows message handler)
! disabled forgotten cdrom and joystick in config file.
* disabled minimizing sdl window while loosing focus.
PocketPC does not have a task bar, so it is an inconvenient and unusual
behaviour for PPC users.
+ added WIN_Paint handler for GAPI
! fixed loosing focus while using GAPI videi driver
+ added TestTimer project
* removed unnecessary macros (ENABLE_WINDIB ...) from projects
From: "William Petiot [exoide]"
Subject: Re: [SDL] cvs version: standard win32 SDL.DLL file test [patch]
I found a bug or two in previous patch, so here is a patch to correct this.
From: "William Petiot [exoide]"
Subject: Re: [SDL] cvs version: questions regarding HAVE_STDIO_H in standard w
I managed to get a first implementation of it, which I tested for "simple" use
with tests sample apps, they work ok. I think this needs more tests.
Here is the diff against CVS/SDL12, attached.
FIXME:
Change #include <stdlib.h> to #include "SDL_stdlib.h"
Change #include <string.h> to #include "SDL_string.h"
Make sure nothing else broke because of this...
