The linux code appears to be complete and *should* be the base of all Unix and GCC based versions. The macosx and win32 versions
are currently just copies of the dummy code. I will begin working on the windows version as soon as this check in is done. I
need someone to work on the Mac OS X version.
I'm afraid that this check in will break QNX (Sorry!)
Unfortunately the audio and cdrom systems do not build at all, and if you
disable those, SDL still fails to link with these errors:
Undefined symbols:
"_OBJC_IVAR_$_NSScreen._frame", referenced from:
-[NSScreen(NSScreenAccess) setFrame:] in SDL_cocoamodes.o
"_KLGetKeyboardLayoutProperty", referenced from:
_UpdateKeymap in SDL_cocoakeyboard.o
_UpdateKeymap in SDL_cocoakeyboard.o
"_KLGetCurrentKeyboardLayout", referenced from:
_UpdateKeymap in SDL_cocoakeyboard.o
ld: symbol(s) not found
/test/testatomic.c performs absolutely basic tests to show that the function work as expected. Need a second test to do more detailed tests.
/include/SDL_atomic.h provides declarations for all included functions.
/src/atomic/linux/SDL_atomic.c provided all the functions. On a generic built the 64 bit functions work, but they are emulated. On a build for -march=pentium and above the 64 bit functions use native instructions
/src/atomic/dummy/SDL_atomic.c emulates all the operations using SDL_mutex.h.
/src/atomic/win32/SDL_atomic.c is a copy of dummy
/src/atomic/macosx/SDL_atomic.s is a copy of dummy
These versions of SDL_atomic.c provide a frame work for building the library with a mixture of native and emulated functions. This allows the whole library to be provided on all platforms. (I hope.)
I hope this fits with the SDL philosophy of either providing a common subset or emulating when the platform is missing a feature.
I have not added dummy, macosx, or win32 to the build. They are there as place holders for future work.
I have modified congifure.in to compile sources in /src/atomic/linux. (The SDL configure.in file is an amazing piece of work and I hope I didn't mess it up. :-)
It also update configure.in to compile the linux version of the library. The three versions are all dummies
implementations that do nothing. They are being checked in as place holders. Mostly, I just wanted to get
place holders and the configure.in checked in.
Since many different event structures include windowID it should be placed near
the beginning of the structure (preferably right after type) so it's position
is the same between different events.
This is to avoid code like this:
if (event.type == SDL_WINDOWEVENT)
win = event.window.windowID;
else if ((SDL_EVENTMASK(event.type) & SDL_KEYEVENTMASK) != 0)
win = event.key.windowID;
else if (event.type == SDL_TEXTINPUT)
win = event.text.windowID;
else if (event.type == SDL_MOUSEMOTION)
win = event.motion.windowID;
else if ((SDL_EVENTMASK(event.type) & (SDL_MOUBUTTONDOWNMASK |
SDL_MOUBUTTONUPMASK)) != 0)
win = event.button.windowID;
else if (event.type == SDL_MOUSEWHEEL)
win = event.wheel.windowID;
...
in favor of:
win = event.window.windowID;
I have prepared a set of patches to readd WindowsCE support to SDL 1.3.
I've created a new GAPI/Rawframebuffer and a DirectDraw renderer.
Both renderers are work in progress and there are several unimplemented
cases. (Notably
RenderLine/RenderPoint/RenderFill/QueryTexturePixels/UpdateTexture and
texture blending )
Nevertheless I am successfully using these renderers together with the
SDL software renderer. (On most devices the SDL software renderer will
be much faster as there are only badly optimized vendor drivers available)
I send these patches now in this unpolished state because there seems to
be some interest in win ce and someone has to start supporting SDL 1.3
Now on to the patches:
wince_events_window_fixes.patch
fixes some wince incompatibilities and adds fullscreen support via
SHFullScreen. NOTE: This patch shouldn't have any side effects on
Windows, but I have NOT tested it on Windows, so please double-check.
This patch doesn't dependent on the following ones.
wince_renderers_system.patch
This patch does all necessary modifications to the SDL system.
- it adds the renderers to the configure system
- it adds the renderers to win32video
SDL_ceddrawrender.c
SDL_ceddrawrender.h
SDL_gapirender_c.h
SDL_gapirender.c
SDL_gapirender.h
these files add the new render drivers and should be placed in
src/video/win32
Some notes to people who want to test this:
- I have only compiled sdl with ming32ce, so the VisualC files are not
up to date
- As mingw32ce has no ddraw.h this file must be taken from the MS SDK
and modified to work with gcc
- I had to modify line 2611 in configure.in to
EXTRA_LDFLAGS="$EXTRA_LDFLAGS -lcoredll -lcommctrl -lmmtimer
-Wl,--image-base -Wl,0x10000"
otherwise GetCPinfo wouldn't link. If someone knows whats causing this
I'd be happy to hear about it.
It would be great if these patches could make their way into SVN as this
would make collaboration much much easier.
I'm out of office for the next week and therefore will be unavailable
via email.
Regards
Stefan
#define SDL_NO_COMPAT
before you include SDL.h then SDL_compat.h will never be included in your code.
This is useful for making sure that your code uses only SDL 1.3 features.
It is also handy for finding things that are in SDL_compat.h that belong elsewhere.
From: Luke Benstead
Subject: OpenGL 3.0 Context Creation
I've attached a patch which implements OpenGL 3.x context creation on
the latest SVN. I've added two options to SDL_GL_SetAttribute, these
are SDL_GL_CONTEXT_MAJOR_VERSION and SDL_GL_CONTEXT_MINOR_VERSION.
These default to 2 and 1 respectively. If the major version is less
than 3 then the current context creation method is used, otherwise the
appropriate new context creation function is called (depending on the
platform).
Sample code:
if (SDL_Init(SDL_INIT_VIDEO) != 0) {
printf("Unable to initialize SDL: %s\n", SDL_GetError());
return 1;
}
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION, 3); //Without these 2 lines, SDL will create a GL 2.x context
SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION, 0);
SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
SDL_Surface* screen = SDL_SetVideoMode( 640, 480, 16, SDL_OPENGL | SDL_FULLSCREEN );
I've implemented context creation on both Win32 and X and run basic
tests on both. This patch doesn't provide access to all the options
allowed by the new context creation (e.g. shared contexts, forward
compatible contexts) but they can be added pretty easily.
From: "Mike Gorchak"
Subject: New QNX patches
Please apply patch qnx4.diff, which is attached. What has been done:
1)Added back OpenGL ES renderer for QNX target. Added few corrections to
OpenGL ES renderer to let it work under QNX. OpenGL ES renderer do not
support textures under QNX, so I think some additional work must be done.
2) Added GL_OES_query_matrix extension to SDL_opengles.h header file, which
required by OpenGL ES 1.1 specification.
3) Added attribute clearing at the entrance of function
SDL_GL_GetAttribure(). Added error checking into the function
SDL_GL_GetAttribure(), because some attributes can't be obtained in OpenGL
ES 1.0.
4) Porting testdyngles to OpenGL ES 1.0 (1.1 has glColor4ub() and
glColor4f() functions, but 1.0 has glColor4f() only).
5) Added error checking after obtaining attributes using
SDL_GL_GetAttribute() function to the testgl2 and testgles.
6) Small correction to testmultiaudio with printing errors.
7) Added software and accelerated OpenGL ES 1.0 support into the QNX GF
driver.
Please remove ./src/audio/nto directory - it will not be used anymore.
Please create ./src/audio/qsa directory and add content of the archive
qsa.tar.gz into this directory. I rewrote some sound code, added support for
multiple audio cards, enumeration, etc. Added initial support for capture.
As far as I can understand SDL 1.3 is not supporting audio capture right now
? Sam, Am I right ? Or audio capture must be supported through the
PlayDevice routine ?
And last, please put file SDL_gf_opengles.c to the ./src/video/qnxgf
directory. It is OpenGL ES 1.1 emulation layer for some functions, which are
not supported by OpenGL ES 1.0.
From: "Mike Gorchak"
Subject: Re: About QNX support in SDL 1.3
Here is another batch of patches.
1) Makefile.in - added SDL_opengles.h header as header to install.
2) configure.in - Added special define to detect Common Lite OpenGL ES
library in case if Common library is not installed. Added check for
clock_gettime in libc (in QNX it is in libc).
3) SDL_config.h.in - Added SDL_VIDEO_RENDER_OPENGL_ES and
SDL_VIDEO_OPENGL_ES declarations for configure script autodetection.
4) SDL_opengles.h - Added GL_API definition if it is not defined. Added
extension GL_OES_draw_texture because OpenGL ES Renderer uses it without
declaration. Added GL_OES_vertex_buffer_object extension, which is supported
under QNX OpenGL ES. Added GL_OES_single_precision extension.
5) To the test directory I've added building OpenGL ES test applications
through the autotools suite. Was support for iPhone IDE building only.
From: "Mike Gorchak"
Subject: About QNX support in SDL 1.3
Right now I'm working on QNX SDL 1.3 drivers implementation and looks like a
lot of code must be completely reworked. But I'm ready for it :) Also I want
to add QNX Graphics Framework SDL driver, which is fullscreen graphics
framework, with support of hardware accelerated OpenGL ES implementations.
This Graphics Framework (called GF in QNX) could also use QNX Photon (window
manager GUI) as window manager.
In the attachment initial patch for QNX support in SDL 1.3
Description From esigra 2008-01-07 16:20:21 (-) [reply]
I try to get a clean compile for a project using SDL. But I get warnings
from SDL headers when I use -Wold-style-cast. This is especially bad
because I plan to build the software with -Werror=old-style-cast when we
have switched over to GCC 4.2, which has that option.
But this problem can be fixed in the SDL headers. I checked out the SVN
version and made some patches. See the attached patch.
* Some math functions become intrinsic in release mode, so we need to
convert all the math functions into SDL math functions, like we did
with the stdlib functions.
* Constant initializers of 8-bit values become calls to memset() in
release mode, but memset() itself is an intrinsic when explicitly
called. So we'll just explicitly call memset() in those cases.
From: Couriersud
Subject: SDL1.3 DirectFB patches
The attached contains the following directfb changes:
- Dynamic loading of libdirectfb.so. This may to turned off as well in configure
- Use linux-input by default. May be switched off by environment variable.
- Added some code which will use directfb's x11 backend when DISPLAY is set.
From: Couriersud
Subject: Fusionsound audio driver
attached is a diff containing a audio driver for the FusionSound
library. This sound library is closely related to DirectFB and uses the
same transport (fusion) as DirectFB when running applications "remote",
i.e. over the network. As such, it natively redirects sound where
DirectFB redirects video. This may be handy for everyone using SDL over
DirectFB.
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.
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.
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
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?
