Ryan has added a number of audio improvements, mostly with new 32-bit and
float audio formats, and I have continued to solidify the updated 2D video
API. There are a lot of pieces still in flux, but feel free to check it
out and voice your thoughts on the progress so far.
Currently the following video drivers are supported:
Windows: OpenGL, Direct3D 9, GDI
Mac OS X: OpenGL
UNIX: OpenGL
General: Software on top of existing video drivers
Notice that the 3D drivers are implemented first, to make sure the new
API takes advantage of full 3D hardware acceleration, when available.
You can play with the files testwm2.c, testsprite2.c, testgl2.c in the
test directory to see some examples of using the new video API.
There are quite a few bugs and patches waiting in bugzilla, and as I
have time, I’ll be adding them to subversion, thanks everyone! Currently
my hands are full working on the expansion for World of Warcraft, and
getting ready for my family to all start school this fall.
Enjoy!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
Ryan has added a number of audio improvements, mostly with new 32-bit and
float audio formats, and I have continued to solidify the updated 2D video
API. There are a lot of pieces still in flux, but feel free to check it
out and voice your thoughts on the progress so far.
Currently the following video drivers are supported:
Windows: OpenGL, Direct3D 9, GDI
Mac OS X: OpenGL
UNIX: OpenGL
General: Software on top of existing video drivers
Notice that the 3D drivers are implemented first, to make sure the new
API takes advantage of full 3D hardware acceleration, when available.
You can play with the files testwm2.c, testsprite2.c, testgl2.c in the
test directory to see some examples of using the new video API.
There are quite a few bugs and patches waiting in bugzilla, and as I
have time, I’ll be adding them to subversion, thanks everyone! Currently
my hands are full working on the expansion for World of Warcraft, and
getting ready for my family to all start school this fall.
Enjoy!
-Sam Lantinga, Senior Software Engineer, Blizzard Entertainment
There are quite a few bugs and patches waiting in bugzilla, and as I
have time, I’ll be adding them to subversion, thanks everyone!
testgl2 and testsprite2 works great on my system,
only testwm2 does nothing, okay it shows a window border.
The first thing i would like to have changed
is to be able to install it in the standard
locations.
As there are a lot of old apps that run with SDL 1.2
and never will be updated to be able to install/use
SDL 1.2 and SDL 2.0 this is absolutely necessary.
How about modifying the sdl-config to use
–use-version=
or
–at-least= and
–at-most= for more control.
sdl-config could assume sdl 1.2 if none of these are specified. This
would allow more installed versions than just two.
This way one could have SDL 1.2, 1.3 and development installed at the
same time.
This would be totally future proof concept as I can see it.
This of course would also need the change to the linking flags etc of
the sdl-config so that the correct version of the library would be
used.
The only change for SDL 1.2 program would then be to add one option for
the sdl-config to try out of the SDL 1.3 compatibility layer.On Thursday 14 September 2006 09:58, Sam Lantinga wrote:
only testwm2 does nothing, okay it shows a window border.
That’s what it’s supposed to do.
It’s the first test I run of a new windowing system driver,
when the rendering subsystem may not yet be implemented.
The first thing i would like to have changed
is to be able to install it in the standard
locations.
It’s on the TODO list, but I’m holding off, debating whether to use
the prefix SDL13 or SDL2
How about modifying the sdl-config to use
–use-version=
or --at-least= and
–at-most= for more control.
sdl-config could assume sdl 1.2 if none of these are specified. This would
allow more installed versions than just two. This way one could have SDL
1.2, 1.3 and development installed at the
same time.
This would be totally future proof concept as I can see it.
This of course would also need the change to the linking flags etc of
the sdl-config so that the correct version of the library would be used.
The only change for SDL 1.2 program would then be to add one option for
the sdl-config to try out of the SDL 1.3 compatibility layer.
The problem is not modifying sdl-config to put out the right
include and libs stuff. When you have the source code from
a game for example it is no problem to recompile it using
a comp. header so that in the end it uses SDL 1.3, but for
most commercial apps you do not have the source from.
Under Windows you just put the old SDL12.dll in the
directory, but on Linux the app searches for the correct sdl lib.
You would need a comp. lib that is 100% API and ABI compatible
to the old SDL 1.2.
The easiest solution is to allow SDL1.2 and SDL2.0
to be in the same place.
How about modifying the sdl-config to use
–use-version=
or --at-least= and
–at-most= for more control.
sdl-config could assume sdl 1.2 if none of these are specified.
This would allow more installed versions than just two. This way
one could have SDL 1.2, 1.3 and development installed at the
same time.
This would be totally future proof concept as I can see it.
This of course would also need the change to the linking flags etc
of the sdl-config so that the correct version of the library would
be used.
The only change for SDL 1.2 program would then be to add one option
for the sdl-config to try out of the SDL 1.3 compatibility layer.
The problem is not modifying sdl-config to put out the right
include and libs stuff. When you have the source code from
a game for example it is no problem to recompile it using
a comp. header so that in the end it uses SDL 1.3, but for
most commercial apps you do not have the source from.
But those would automatically use the correct SDL if the libSDL.so
symlink points to libSDL-1.2.so.0 (ie SDL 1.2 library). SDL 1.3 would
be libSDL-1.3.so.0. So every new compilation using the sdl-config could
chose which SDL lib to use.
Under Windows you just put the old SDL12.dll in the
directory, but on Linux the app searches for the correct sdl lib.
You would need a comp. lib that is 100% API and ABI compatible
to the old SDL 1.2.
As I stated there is nothing that can stop you from using more than one
SDL library in the same place.
The easiest solution is to allow SDL1.2 and SDL2.0
to be in the same place.
As it can be. The only additions are SDL 1.3 has to use different
include dir say SDL1.3. I would change SDL 1.2 to SDL1.2 too and made
symlink for compatibility. Now sdl-config can do all the necessary
parts. This isn’t restricted to two versions either.
No hasels with different sdl-config scripts.
The newest can allways provide compatible behaviour for the older
libraries.
After all this is the way this should have been in the first place.
FLTK FLTK2
GTK GTK2
This is artificial hacking, because of braindead package managers.
For example in Gentoo there is no such packages as GTK2. Only
different versions. There can be installed one version for gtk±1.x and
one for gtk±2.x. And when gtk±3.x comes it will add another slot.On Thursday 14 September 2006 19:38, Torsten Giebl wrote:
