I wish that SDL went a bit further with this - for example abstracting bsdsockets would be nice (note: I know SDL_net exists, but I don’t see it so much as an abstraction of bsdsockets, furthermore
it’s not part of SDL itself).
But that said, I have not had opportunity to use most of the SDL functionality because I maintain native ports of my main project (Windows, OSX, Linux, PS3) as well as SDL (Windows, OSX, Linux), so
most of the code can’t use the (quite lovely) SDL features.
Major porting-related modules in my project are net, video, memory, virtualized filesystem (with semi-frequent changes in the searchpath, with zip loading), sound, cdaudio (not applicable on some),
threading, library loading (not applicable to platforms that lack it or have major differences in its behavior, such as PS3 and iPhone).
SDL abstracts some of these features, but I had to make my own abstractions for several of them (net, threading, library loading, memory) due to lack of reliance on SDL.
Obviously I can’t discuss any core details of PS3 due to NDA so I won’t get into that, but suffice to say there are huge differences on that platform (and not strictly platform-related, for example
using the Sony-supplied optimized zip decompression is a requirement, besides obvious rendering differences as well).
I have no current plans to migrate to SDL 1.3 as it does not look mature yet.
There are a few bugs left to fix in SDL 1.2 that I think deserve to be fixed, requiring migration to SDL 1.3 to get bugfixes would not be reasonable - however I realize this is mostly a matter of
"patch it yourself, submit patch" at this point.
This is just my current feelings on SDL, I think it’s a fantastic library and I feel it should abstract away a few more platform differences in the core library, however I have a bias in this regard
as I like to minimize compile-time dependencies (accordingly I do not currently use the high-level libraries such as SDL_mixer, SDL_image, SDL_net, because I already have to maintain native ports with
all of this functionality).
I’m thrilled when I encounter a polished little game on multiple platforms using SDL, like Neverball for example, I think SDL excels at this sort of portability (games written specifically for SDL,
not merely having SDL bolted on as in my case).On 04/13/2010 12:32 PM, Lo?c LAMBERT wrote:
Just my point of view… I see SDL more like a portable ‘hardware
abstract layer’ (many OSes, many platforms) than just a multimedia library.
So, tools like timer, mutex, thread, fonts (SDL_ttf), network (SDL_net),
etc can be really useful in many cases to build a portable cross
With SDL, you can almost create a JVM without any system call! With the
Atomic Operation API, you can now write a Java 5
This point of view is a bit optimistic because every thing is not
available everywhere and some parts may be more or less mature.
There are other libs for one or another feature, but I prefer limit the
number of dependencies.
Le 13/04/2010 13:19, Mason Wheeler a ?crit :
I really have no need for it, personally. Most of the "utility"
in SDL, the stuff that’s not directly related to the core functionality
of providing support for multimedia, appears from my perspective
as just a reimplementation of stuff that’s been in Delphi’s standard
library for at least a decade, and this is one of them.
----- Original Message ----
From: Sam Lantinga
Subject: [SDL] Poll: Atomic Operations?
It’s been a while since Bob implemented the Atomic Operations API.
I’m curious how many people are using or are planning to use it in the
future? Does anyone have feedback on the functionality or API?
SDL mailing list
SDL at lists.libsdl.org
SDL mailing list
SDL at lists.libsdl.org
Author of DarkPlaces Quake1 engine - http://icculus.org/twilight/darkplaces
Co-designer of Nexuiz - http://alientrap.org/nexuiz
"War does not prove who is right, it proves who is left." - Unknown
"Any sufficiently advanced technology is indistinguishable from a rigged demo." - James Klass
"A game is a series of interesting choices." - Sid Meier