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?
Thanks!–
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
I really have no need for it, personally. Most of the “utility” functions
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?Thanks!
I agree. SDL should be about abstracting “multimedia”. I don’t really know about C libs, but for C++ this should be soon in BOOST http://www.chaoticmind.net/~hcb/projects/boost.atomic/. Atomics are also coming to C++ standard with compilers already supporting many upcoming features. Also, I am bit skeptical about one person doing atomics for so many platforms and just because of that I have more trust in BOOST or similar.
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
platform application.
With SDL, you can almost create a JVM without any system call! With the
Atomic Operation API, you can now write a Java 5
java.util.concurrent.atomic package 
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.
Regards,
Lo?c
Le 13/04/2010 13:19, Mason Wheeler a ?crit :> I really have no need for it, personally. Most of the “utility” functions
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?Thanks!
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
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
platform application.
With SDL, you can almost create a JVM without any system call! With the
Atomic Operation API, you can now write a Java 5
java.util.concurrent.atomic packageThis 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.Regards,
Lo?cLe 13/04/2010 13:19, Mason Wheeler a ?crit :
I really have no need for it, personally. Most of the "utility"
functions
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?Thanks!
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
LordHavoc
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
Hello,
I have had usage for atomic operations in the past with SDL. However I
ended up just using GCC GNU extensions. I do not think anyone will be
traumatized if it’s left out, however if it’s little work and there are
few maintainability issues I think it can be interesting. I haven’t had
a chance to look at the SDL atomic operations API yet,
EdgarOn 2010?04?13? 06:09, Sam Lantinga wrote:
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?Thanks!
-------------- next part --------------
A non-text attachment was scrubbed…
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: OpenPGP digital signature
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20100413/cf014ee2/attachment.pgp
Looks like I’m going to address three different topics in this message.—
I’ve just read through the replies and I have to say that it would not
break my heart to see it removed from SDL. I got what I really wanted
out of doing the project which was a serious update to my knowledge of
atomic operations and a nice review of atomic op based thread
programming.
I can even come up with a lot of reasons for taking it out. The first
one that comes to mind is that I can only really support Linux and
Windows. To get good support for other platforms requires that people
who have those platforms and who have the expertise step up and add
that support to the library. That has happened a little bit, but not
at the level needed to maintain the library or extend it to new
platforms. That lack of people stepping up is a major vote against
keeping the library in the core of SDL.
The fact that there were so few responses to Sam’s query shows how
little interest their is in the API. Little interest == few people
stepping up.
–
Having atomics in Boost or C++ is not a reason to get rid of the
library. SDL is a C API, not a C++ API. Being a C API makes it much
easier to integrate SDL into many different languages. I haven’t run
into a language in a long time that doesn’t have some mechanism for
talking to C API libraries. That is not true of C++ and will not be
true of the next generation of C++ either. Having a cross platform C
atomics API is a good thing. But, and this is a big BUT, languages
tend to have their own carefully crafted ways of handling threads that
may not be at all compatible with a standalone atomics library.
The atomics library is one of the only parts of SDL that I can think
of that you might not be able to integrate into some programming
languages. That is a good reason to remove it. Gee… I wish I had
thought of that before now. 
–
Reading through the responses I see two different points of view on
what SDL should be. The follow tries to describe the extreme ends of
these points of view:
a Simple Direct abstraction for accessing multimedia capabilities
of a computing platform. I think this view includes the idea of
including a nice set of convenience functions that handle the kinds of
things you need to do to resources to get them ready for use on a
given platform. Things like reading, writing, reformatting,
compositing, scaling, sampling… But, limited to handling just the
multimedia parts of the job.
A complete abstraction of the platform that lets you write code
once and compile and run it anywhere. The APIs that are offered are
the common subset of what each platform can do PLUS a set of query
functions and compile time definitions so that your application can
adjust to the realities of the platform it is running on PLUS a
minimal set of platform specific APIs that are necessary to make
applications work on specific platforms. Ideally this could be
#ifdef’ed so that code will still compile and run on any platform.
Right now SDL is somewhere in the middle between the two end points. I
think that is a good place to be because it has arrived there as a
result of pragmatism and reaction to what SDL users want. What they
want eventually gets written and included. It isn’t perfect, but it is
very very good.
One of the nicest things about SDL is that it is possible to write
good games using just SDL. Having a single library to start with is
more important for learning than people seem to believe. You can learn
all the concepts working with a single library and a single set of
documentation. Think about the beginner who wants to get started but
doesn’t even know how to find all the different libraries needed to
develop a game? The skill level need to be able to decide if you can
even use two libraries in the same program is way beyond any beginner
and beyond some fairly experience programmers. It also helps that
there is a huge community of people who actually answer questions. The
value of having a single point of contact with all the concepts, the
documentation, and a community is immense.
If we wanted to move SDL more toward #1 we could throw out much of SDL
and leave only enough of the graphics and input code so that it
becomes an event based alternative to glut with a very nice input
handler. Sound could be passed off to OpenAL or what ever people
liked. Image handling, IO, and many other things that are currently
part of SDL could be replaced with other existing libraries. We would
just document how to make them work with SDL.
If we wanted to move SDL more toward #2 we would do well to go out an
take a long look at the apache portable runtime, the Netscape portable
runtime, and wxWidgets (everything including the kitchen sink, but you
have to do it their way). Getting to #2 is a major project.
I do not know what the underlying philosophy of SDL is. I’m not sure
there is a stated philosophy. I’m not sure it would be a good idea to
have one. I rather like the idea that SDL is driven by what people
want and by changes in technology. I do believe it is important to
remember that everyone sees the parts of SDL they use as being
important and tend to disregard the rest.
–
This is very interesting to me.
Bob Pendleton
On Mon, Apr 12, 2010 at 11:09 PM, Sam Lantinga wrote:
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?Thanks!
? ? ? ?-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
I totally agree with all this points and I think the SDL core lib should
not get too heavy (for example compared to Qt).
There are many libs that extends SDL so that anyone can use only what he
really needs (SDL_image, SDL_ttf, SDL_gfx, agar, …).
As atomic API may not be a core feature and seems to be useless for C++
developers (I don’t know this language), maybe it should become a
SDL_atomic project.
For the status of the ports of SDL, it would be great to have a page
like this one http://www.videolan.org/vlc/features.html on the SDL web
site. I know, this kind of page is always hard to keep up to date…
Just dreaming : maybe, some day, a forge would host the SDL core and
some extension libs so that one can find these libs easily ; every
project would use the same SCM (Mercurial), the same way of building
(autoconf, other…), night builds for compatibility checking and
atomatic feeding of the ports <> feature list…
Lo?c
Le 14/04/2010 16:55, Bob Pendleton a ?crit :> Looks like I’m going to address three different topics in this message.
I’ve just read through the replies and I have to say that it would not
break my heart to see it removed from SDL. I got what I really wanted
out of doing the project which was a serious update to my knowledge of
atomic operations and a nice review of atomic op based thread
programming.I can even come up with a lot of reasons for taking it out. The first
one that comes to mind is that I can only really support Linux and
Windows. To get good support for other platforms requires that people
who have those platforms and who have the expertise step up and add
that support to the library. That has happened a little bit, but not
at the level needed to maintain the library or extend it to new
platforms. That lack of people stepping up is a major vote against
keeping the library in the core of SDL.The fact that there were so few responses to Sam’s query shows how
little interest their is in the API. Little interest == few people
stepping up.–
Having atomics in Boost or C++ is not a reason to get rid of the
library. SDL is a C API, not a C++ API. Being a C API makes it much
easier to integrate SDL into many different languages. I haven’t run
into a language in a long time that doesn’t have some mechanism for
talking to C API libraries. That is not true of C++ and will not be
true of the next generation of C++ either. Having a cross platform C
atomics API is a good thing. But, and this is a big BUT, languages
tend to have their own carefully crafted ways of handling threads that
may not be at all compatible with a standalone atomics library.The atomics library is one of the only parts of SDL that I can think
of that you might not be able to integrate into some programming
languages. That is a good reason to remove it. Gee… I wish I had
thought of that before now.–
Reading through the responses I see two different points of view on
what SDL should be. The follow tries to describe the extreme ends of
these points of view:
a Simple Direct abstraction for accessing multimedia capabilities
of a computing platform. I think this view includes the idea of
including a nice set of convenience functions that handle the kinds of
things you need to do to resources to get them ready for use on a
given platform. Things like reading, writing, reformatting,
compositing, scaling, sampling… But, limited to handling just the
multimedia parts of the job.A complete abstraction of the platform that lets you write code
once and compile and run it anywhere. The APIs that are offered are
the common subset of what each platform can do PLUS a set of query
functions and compile time definitions so that your application can
adjust to the realities of the platform it is running on PLUS a
minimal set of platform specific APIs that are necessary to make
applications work on specific platforms. Ideally this could be
#ifdef’ed so that code will still compile and run on any platform.Right now SDL is somewhere in the middle between the two end points. I
think that is a good place to be because it has arrived there as a
result of pragmatism and reaction to what SDL users want. What they
want eventually gets written and included. It isn’t perfect, but it is
very very good.One of the nicest things about SDL is that it is possible to write
good games using just SDL. Having a single library to start with is
more important for learning than people seem to believe. You can learn
all the concepts working with a single library and a single set of
documentation. Think about the beginner who wants to get started but
doesn’t even know how to find all the different libraries needed to
develop a game? The skill level need to be able to decide if you can
even use two libraries in the same program is way beyond any beginner
and beyond some fairly experience programmers. It also helps that
there is a huge community of people who actually answer questions. The
value of having a single point of contact with all the concepts, the
documentation, and a community is immense.If we wanted to move SDL more toward #1 we could throw out much of SDL
and leave only enough of the graphics and input code so that it
becomes an event based alternative to glut with a very nice input
handler. Sound could be passed off to OpenAL or what ever people
liked. Image handling, IO, and many other things that are currently
part of SDL could be replaced with other existing libraries. We would
just document how to make them work with SDL.If we wanted to move SDL more toward #2 we would do well to go out an
take a long look at the apache portable runtime, the Netscape portable
runtime, and wxWidgets (everything including the kitchen sink, but you
have to do it their way). Getting to #2 is a major project.I do not know what the underlying philosophy of SDL is. I’m not sure
there is a stated philosophy. I’m not sure it would be a good idea to
have one. I rather like the idea that SDL is driven by what people
want and by changes in technology. I do believe it is important to
remember that everyone sees the parts of SDL they use as being
important and tend to disregard the rest.–
This is very interesting to me.
Bob Pendleton
On Mon, Apr 12, 2010 at 11:09 PM, Sam Lantinga wrote:
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?Thanks!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
I think an add on library would be a good way to handle this.
Personally, I like the idea of having a simple, platform independant
atomic operation API. But if it won’t be supported well then maybe it
shouldn’t be put in the core.
I’d like to get around to using it to provide some feedback on the API
itself. But until then, it looks fun Bob!
– BrianOn 14 April 2010 17:14, Lo?c LAMBERT <dev.lambert at free.fr> wrote:
I totally agree with all this points and I think the SDL core lib should not
get too heavy (for example compared to Qt).
There are many libs that extends SDL so that anyone can use only what he
really needs (SDL_image, SDL_ttf, SDL_gfx, agar, …).As atomic API may not be a core feature and seems to be useless for C++
developers (I don’t know this language), maybe it should become a SDL_atomic
project.
Part of the reason why there has been so little interest in atomics is
because right now so few people actually use atomics on a regular basis.
Most code still isn’t being written to effectively use multiple cores, and
as such people are still using basic threading and mutexes. Atomics are
only really necessary if you need lock-free algorithms. We will all need
lock free algorithms in the future; that future may not quite be there
yet.
I would support keeping them in. It’ll save us having to write this code
later, and I would have used it in my recent GDMag article had I known
that I was going to end up using SDL for it.
My two cents,
Nicholas (descending from the depths of lurker-dom to make his one post
every five years…)On Wed, 14 Apr 2010, Bob Pendleton wrote:
Looks like I’m going to address three different topics in this message.
I’ve just read through the replies and I have to say that it would not
break my heart to see it removed from SDL. I got what I really wanted
out of doing the project which was a serious update to my knowledge of
atomic operations and a nice review of atomic op based thread
programming.I can even come up with a lot of reasons for taking it out. The first
one that comes to mind is that I can only really support Linux and
Windows. To get good support for other platforms requires that people
who have those platforms and who have the expertise step up and add
that support to the library. That has happened a little bit, but not
at the level needed to maintain the library or extend it to new
platforms. That lack of people stepping up is a major vote against
keeping the library in the core of SDL.The fact that there were so few responses to Sam’s query shows how
little interest their is in the API. Little interest == few people
stepping up.–
Having atomics in Boost or C++ is not a reason to get rid of the
library. SDL is a C API, not a C++ API. Being a C API makes it much
easier to integrate SDL into many different languages. I haven’t run
into a language in a long time that doesn’t have some mechanism for
talking to C API libraries. That is not true of C++ and will not be
true of the next generation of C++ either. Having a cross platform C
atomics API is a good thing. But, and this is a big BUT, languages
tend to have their own carefully crafted ways of handling threads that
may not be at all compatible with a standalone atomics library.The atomics library is one of the only parts of SDL that I can think
of that you might not be able to integrate into some programming
languages. That is a good reason to remove it. Gee… I wish I had
thought of that before now.–
Reading through the responses I see two different points of view on
what SDL should be. The follow tries to describe the extreme ends of
these points of view:
a Simple Direct abstraction for accessing multimedia capabilities
of a computing platform. I think this view includes the idea of
including a nice set of convenience functions that handle the kinds of
things you need to do to resources to get them ready for use on a
given platform. Things like reading, writing, reformatting,
compositing, scaling, sampling… But, limited to handling just the
multimedia parts of the job.A complete abstraction of the platform that lets you write code
once and compile and run it anywhere. The APIs that are offered are
the common subset of what each platform can do PLUS a set of query
functions and compile time definitions so that your application can
adjust to the realities of the platform it is running on PLUS a
minimal set of platform specific APIs that are necessary to make
applications work on specific platforms. Ideally this could be
#ifdef’ed so that code will still compile and run on any platform.Right now SDL is somewhere in the middle between the two end points. I
think that is a good place to be because it has arrived there as a
result of pragmatism and reaction to what SDL users want. What they
want eventually gets written and included. It isn’t perfect, but it is
very very good.One of the nicest things about SDL is that it is possible to write
good games using just SDL. Having a single library to start with is
more important for learning than people seem to believe. You can learn
all the concepts working with a single library and a single set of
documentation. Think about the beginner who wants to get started but
doesn’t even know how to find all the different libraries needed to
develop a game? The skill level need to be able to decide if you can
even use two libraries in the same program is way beyond any beginner
and beyond some fairly experience programmers. It also helps that
there is a huge community of people who actually answer questions. The
value of having a single point of contact with all the concepts, the
documentation, and a community is immense.If we wanted to move SDL more toward #1 we could throw out much of SDL
and leave only enough of the graphics and input code so that it
becomes an event based alternative to glut with a very nice input
handler. Sound could be passed off to OpenAL or what ever people
liked. Image handling, IO, and many other things that are currently
part of SDL could be replaced with other existing libraries. We would
just document how to make them work with SDL.If we wanted to move SDL more toward #2 we would do well to go out an
take a long look at the apache portable runtime, the Netscape portable
runtime, and wxWidgets (everything including the kitchen sink, but you
have to do it their way). Getting to #2 is a major project.I do not know what the underlying philosophy of SDL is. I’m not sure
there is a stated philosophy. I’m not sure it would be a good idea to
have one. I rather like the idea that SDL is driven by what people
want and by changes in technology. I do believe it is important to
remember that everyone sees the parts of SDL they use as being
important and tend to disregard the rest.–
This is very interesting to me.
Bob Pendleton
On Mon, Apr 12, 2010 at 11:09 PM, Sam Lantinga wrote:
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?Thanks!
? ? ? ?-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org–
±----------------------------------------------------------
- Bob Pendleton: writer and programmer
- email: Bob at Pendleton.com
- web: www.TheGrumpyProgrammer.com
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
Bob wrote:
I got what I really wanted
out of doing the project which was a serious update to my knowledge of
atomic operations and a nice review of atomic op based thread
programming.
This is my only argument for keeping. SDL already provides threading support, why not provide userspace synchronization techniques as well?
That said, the only two things that SDL would really need to implement are spinlocks and maybe (it’s simple enough to implement this one on one’s own) a spin-x-times lock wrapping a system mutex (which, from my understanding, is essentially the same as Window’s CRITICALSECTION and Linux’s futex).
That lack of people stepping up is a major vote against
keeping the library in the core of SDL.The fact that there were so few responses to Sam’s query shows how
little interest their is in the API. Little interest == few people
stepping up.
agreed, but not really a reason to completely drop the code so much as to make it a side project that is not SDL core
- a Simple Direct abstraction for accessing multimedia capabilities
of a computing platform. I think this view includes the idea of
including a nice set of convenience functions that handle the kinds of
things you need to do to resources to get them ready for use on a
given platform. Things like reading, writing, reformatting,
compositing, scaling, sampling… But, limited to handling just the
multimedia parts of the job.
Well, this IS the implication of SDL’s name… Simple Direct Media (abstraction) Layer.
- A complete abstraction of the platform that lets you write code
once and compile and run it anywhere. The APIs that are offered are
the common subset of what each platform can do
This is what SDL + most of its companion libraries are.
[…] PLUS a set of query
functions and compile time definitions so that your application can
adjust to the realities of the platform it is running on PLUS a
minimal set of platform specific APIs that are necessary to make
applications work on specific platforms. Ideally this could be
#ifdef’ed so that code will still compile and run on any platform.
Well, I personally would like to see some functions providing non-common-denominator functionality on systems supporting it.
For example, how much better would the iPhone port be if it also provided a C layer over the UIKit views, and of course functions to integrate those with windows.
One of the nicest things about SDL is that it is possible to write
good games using just SDL. Having a single library to start with is
more important for learning than people seem to believe. You can learn
all the concepts working with a single library and a single set of
documentation. […] The
value of having a single point of contact with all the concepts, the
documentation, and a community is immense.
Agreed. SDL is what really enabled me to play around with game development for the first time.------------------------
EM3 Nathaniel Fries, U.S. Navy
I think an add on library would be a good way to handle this.
Personally, I like the idea of having a simple, platform independant
atomic operation API. But if it won’t be supported well then maybe it
shouldn’t be put in the core.I’d like to get around to using it to provide some feedback on the API
itself. But until then, it looks fun Bob!
It was a lot of fun! Atomic ops and atomic programming have come a
long way since I first ran into testAndSet on a Univac 1108a…
Bob PendletonOn Wed, Apr 14, 2010 at 3:11 PM, Brian Barrett <brian.ripoff at gmail.com> wrote:
– Brian
On 14 April 2010 17:14, Lo?c LAMBERT <dev.lambert at free.fr> wrote:
I totally agree with all this points and I think the SDL core lib should not
get too heavy (for example compared to Qt).
There are many libs that extends SDL so that anyone can use only what he
really needs (SDL_image, SDL_ttf, SDL_gfx, agar, …).As atomic API may not be a core feature and seems to be useless for C++
developers (I don’t know this language), maybe it should become a SDL_atomic
project.
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
Bob wrote:
I got what I really wanted
out of doing the project which was a serious update to my knowledge of
atomic operations and a nice review of atomic op based thread
programming.This is my only argument for keeping. SDL already provides threading
support, why not provide userspace synchronization techniques as well?
That said, the only two things that SDL would really need to implement are
spinlocks and maybe (it’s simple enough to implement this one on one’s
own) a spin-x-times lock wrapping a system mutex (which, from my
understanding, is essentially the same as Window’s CRITICALSECTION and
Linux’s futex).
You would also like a lock-free queue operations. Much code that currently
uses mutexes can be made much faster an more reliable by replacing shared
memory protected by a mutex or spin-lock with short lock-free queues.
BTW, Three cheers for the Navy!
Bob PendletonOn Wed, Apr 14, 2010 at 7:44 PM, Nathaniel J Fries wrote:
Quote:
That lack of people stepping up is a major vote against
keeping the library in the core of SDL.The fact that there were so few responses to Sam’s query shows how
little interest their is in the API. Little interest == few people
stepping up.agreed, but not really a reason to completely drop the code so much as to
make it a side project that is not SDL coreQuote:
- a Simple Direct abstraction for accessing multimedia capabilities
of a computing platform. I think this view includes the idea of
including a nice set of convenience functions that handle the kinds of
things you need to do to resources to get them ready for use on a
given platform. Things like reading, writing, reformatting,
compositing, scaling, sampling… But, limited to handling just the
multimedia parts of the job.Well, this IS the implication of SDL’s name… Simple Direct Media
(abstraction) Layer.Quote:
- A complete abstraction of the platform that lets you write code
once and compile and run it anywhere. The APIs that are offered are
the common subset of what each platform can doThis is what SDL + most of its companion libraries are.
Quote:
[…] PLUS a set of query
functions and compile time definitions so that your application can
adjust to the realities of the platform it is running on PLUS a
minimal set of platform specific APIs that are necessary to make
applications work on specific platforms. Ideally this could be
#ifdef’ed so that code will still compile and run on any platform.Well, I personally would like to see some functions providing
non-common-denominator functionality on systems supporting it.
For example, how much better would the iPhone port be if it also provided a
C layer over the UIKit views, and of course functions to integrate those
with windows.Quote:
One of the nicest things about SDL is that it is possible to write
good games using just SDL. Having a single library to start with is
more important for learning than people seem to believe. You can learn
all the concepts working with a single library and a single set of
documentation. […] Thevalue of having a single point of contact with all the concepts, the
documentation, and a community is immense.Agreed. SDL is what really enabled me to play around with game development
for the first time.
EM3 Nathaniel Fries, U.S. Navy
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
–
±----------------------------------------------------------
Bob wrote:
You would also like a lock-free queue operations. Much code that currently uses mutexes can be made much faster an more reliable by replacing shared memory protected by a mutex or spin-lock with short lock-free queues.
BTW, Three cheers for the Navy!
Bob Pendleton
Usually I just make a class (or if I were a C purist I’d make C functions, I guess) wrapping the non-threadsafe queue access with a spinlock.
I can’t say I’m well studied in atomic operations, spinlocks in x86 assembly is as far as I’ve practiced (or needed to practice), so is there some better method?
BTW, thanks for the support. I’m in the final months of my two year training cycle. x.x------------------------
EM3 Nathaniel Fries, U.S. Navy
Part of the reason why there has been so little interest in atomics is
because right now so few people actually use atomics on a regular basis.
Most code still isn’t being written to effectively use multiple cores, and
as such people are still using basic threading and mutexes. Atomics are only
really necessary if you need lock-free algorithms. We will all need lock
free algorithms in the future; that future may not quite be there yet.I would support keeping them in. It’ll save us having to write this code
later, and I would have used it in my recent GDMag article had I known that
I was going to end up using SDL for it.My two cents,
Nicholas (descending from the depths of lurker-dom to make his one post
every five years…)
I for one appreciate your emergence from lurker-dom :). That was a good
article. I’m just getting into parallel programming, but mostly from the
distributed angle with MPI (I’m writing a game now that runs on one of our
supercomputer clusters). Even so, I’ve already run into places I would love
to use atomics, mostly for the simplicity they provide over more verbose
methods. I don’t really care if they’re in SDL proper or an extension,
but having them around is great.
Jonny DOn Wed, Apr 14, 2010 at 1:43 PM, Nicholas Vining wrote:
seconded!
the main sdl library should be kept as thin as possible, whereas all
the extra cross platform functionality (such as atomics) could be
written in an additional library, SDL_extra, or something
VittorioOn Wed, Apr 14, 2010 at 6:14 PM, Lo?c LAMBERT <dev.lambert at free.fr> wrote:
I totally agree with all this points and I think the SDL core lib should not
get too heavy (for example compared to Qt).
There are many libs that extends SDL so that anyone can use only what he
really needs (SDL_image, SDL_ttf, SDL_gfx, agar, …).As atomic API may not be a core feature and seems to be useless for C++
developers (I don’t know this language), maybe it should become a SDL_atomic
project.For the status of the ports of SDL, it would be great to have a page like
this one http://www.videolan.org/vlc/features.html on the SDL web site. I
know, this kind of page is always hard to keep up to date…Just dreaming : maybe, some day, a forge would host the SDL core and some
extension libs so that one can find these libs easily ; every project would
use the same SCM (Mercurial), the same way of building (autoconf, other…),
night builds for compatibility checking and atomatic feeding of the ports <>
feature list…Lo?c
Le 14/04/2010 16:55, Bob Pendleton a ?crit :
Looks like I’m going to address three different topics in this message.
I’ve just read through the replies and I have to say that it would not
break my heart to see it removed from SDL. I got what I really wanted
out of doing the project which was a serious update to my knowledge of
atomic operations and a nice review of atomic op based thread
programming.I can even come up with a lot of reasons for taking it out. The first
one that comes to mind is that I can only really support Linux and
Windows. To get good support for other platforms requires that people
who have those platforms and who have the expertise step up and add
that support to the library. That has happened a little bit, but not
at the level needed to maintain the library or extend it to new
platforms. That lack of people stepping up is a major vote against
keeping the library in the core of SDL.The fact that there were so few responses to Sam’s query shows how
little interest their is in the API. Little interest == few people
stepping up.–
Having atomics in Boost or C++ is not a reason to get rid of the
library. SDL is a C API, not a C++ API. Being a C API makes it much
easier to integrate SDL into many different languages. I haven’t run
into a language in a long time that doesn’t have some mechanism for
talking to C API libraries. That is not true of C++ and will not be
true of the next generation of C++ either. Having a cross platform C
atomics API is a good thing. But, and this is a big BUT, languages
tend to have their own carefully crafted ways of handling threads that
may not be at all compatible with a standalone atomics library.The atomics library is one of the only parts of SDL that I can think
of that you might not be able to integrate into some programming
languages. That is a good reason to remove it. Gee… I wish I had
thought of that before now.–
Reading through the responses I see two different points of view on
what SDL should be. The follow tries to describe the extreme ends of
these points of view:
a Simple Direct abstraction for accessing multimedia capabilities
of a computing platform. I think this view includes the idea of
including a nice set of convenience functions that handle the kinds of
things you need to do to resources to get them ready for use on a
given platform. Things like reading, writing, reformatting,
compositing, scaling, sampling… But, limited to handling just the
multimedia parts of the job.A complete abstraction of the platform that lets you write code
once and compile and run it anywhere. The APIs that are offered are
the common subset of what each platform can do PLUS a set of query
functions and compile time definitions so that your application can
adjust to the realities of the platform it is running on PLUS a
minimal set of platform specific APIs that are necessary to make
applications work on specific platforms. Ideally this could be
#ifdef’ed so that code will still compile and run on any platform.Right now SDL is somewhere in the middle between the two end points. I
think that is a good place to be because it has arrived there as a
result of pragmatism and reaction to what SDL users want. What they
want eventually gets written and included. It isn’t perfect, but it is
very very good.One of the nicest things about SDL is that it is possible to write
good games using just SDL. Having a single library to start with is
more important for learning than people seem to believe. You can learn
all the concepts working with a single library and a single set of
documentation. Think about the beginner who wants to get started but
doesn’t even know how to find all the different libraries needed to
develop a game? The skill level need to be able to decide if you can
even use two libraries in the same program is way beyond any beginner
and beyond some fairly experience programmers. It also helps that
there is a huge community of people who actually answer questions. The
value of having a single point of contact with all the concepts, the
documentation, and a community is immense.If we wanted to move SDL more toward #1 we could throw out much of SDL
and leave only enough of the graphics and input code so that it
becomes an event based alternative to glut with a very nice input
handler. Sound could be passed off to OpenAL or what ever people
liked. Image handling, IO, and many other things that are currently
part of SDL could be replaced with other existing libraries. We would
just document how to make them work with SDL.If we wanted to move SDL more toward #2 we would do well to go out an
take a long look at the apache portable runtime, the Netscape portable
runtime, and wxWidgets (everything including the kitchen sink, but you
have to do it their way). Getting to #2 is a major project.I do not know what the underlying philosophy of SDL is. I’m not sure
there is a stated philosophy. I’m not sure it would be a good idea to
have one. I rather like the idea that SDL is driven by what people
want and by changes in technology. I do believe it is important to
remember that everyone sees the parts of SDL they use as being
important and tend to disregard the rest.–
This is very interesting to me.
Bob Pendleton
On Mon, Apr 12, 2010 at 11:09 PM, Sam Lantinga wrote:
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?Thanks!
? ? ? -Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
keep the sdl runtime ‘SIMPLE’. leave everything else outside the core
runtime.On Sat, Apr 17, 2010 at 5:50 AM, Vittorio G. <vitto.giova at yahoo.it> wrote:
seconded!
the main sdl library should be kept as thin as possible, whereas all
the extra cross platform functionality (such as atomics) could be
written in an additional library, SDL_extra, or something
VittorioOn Wed, Apr 14, 2010 at 6:14 PM, Lo?c LAMBERT <dev.lambert at free.fr> wrote:
I totally agree with all this points and I think the SDL core lib should
not
get too heavy (for example compared to Qt).
There are many libs that extends SDL so that anyone can use only what he
really needs (SDL_image, SDL_ttf, SDL_gfx, agar, …).As atomic API may not be a core feature and seems to be useless for C++
developers (I don’t know this language), maybe it should become a
SDL_atomic
project.For the status of the ports of SDL, it would be great to have a page like
this one http://www.videolan.org/vlc/features.html on the SDL web site.
I
know, this kind of page is always hard to keep up to date…Just dreaming : maybe, some day, a forge would host the SDL core and some
extension libs so that one can find these libs easily ; every project
would
use the same SCM (Mercurial), the same way of building (autoconf,
other…),
night builds for compatibility checking and atomatic feeding of the ports
<>
feature list…Lo?c
Le 14/04/2010 16:55, Bob Pendleton a ?crit :
Looks like I’m going to address three different topics in this message.
I’ve just read through the replies and I have to say that it would not
break my heart to see it removed from SDL. I got what I really wanted
out of doing the project which was a serious update to my knowledge of
atomic operations and a nice review of atomic op based thread
programming.I can even come up with a lot of reasons for taking it out. The first
one that comes to mind is that I can only really support Linux and
Windows. To get good support for other platforms requires that people
who have those platforms and who have the expertise step up and add
that support to the library. That has happened a little bit, but not
at the level needed to maintain the library or extend it to new
platforms. That lack of people stepping up is a major vote against
keeping the library in the core of SDL.The fact that there were so few responses to Sam’s query shows how
little interest their is in the API. Little interest == few people
stepping up.–
Having atomics in Boost or C++ is not a reason to get rid of the
library. SDL is a C API, not a C++ API. Being a C API makes it much
easier to integrate SDL into many different languages. I haven’t run
into a language in a long time that doesn’t have some mechanism for
talking to C API libraries. That is not true of C++ and will not be
true of the next generation of C++ either. Having a cross platform C
atomics API is a good thing. But, and this is a big BUT, languages
tend to have their own carefully crafted ways of handling threads that
may not be at all compatible with a standalone atomics library.The atomics library is one of the only parts of SDL that I can think
of that you might not be able to integrate into some programming
languages. That is a good reason to remove it. Gee… I wish I had
thought of that before now.–
Reading through the responses I see two different points of view on
what SDL should be. The follow tries to describe the extreme ends of
these points of view:
a Simple Direct abstraction for accessing multimedia capabilities
of a computing platform. I think this view includes the idea of
including a nice set of convenience functions that handle the kinds of
things you need to do to resources to get them ready for use on a
given platform. Things like reading, writing, reformatting,
compositing, scaling, sampling… But, limited to handling just the
multimedia parts of the job.A complete abstraction of the platform that lets you write code
once and compile and run it anywhere. The APIs that are offered are
the common subset of what each platform can do PLUS a set of query
functions and compile time definitions so that your application can
adjust to the realities of the platform it is running on PLUS a
minimal set of platform specific APIs that are necessary to make
applications work on specific platforms. Ideally this could be
#ifdef’ed so that code will still compile and run on any platform.Right now SDL is somewhere in the middle between the two end points. I
think that is a good place to be because it has arrived there as a
result of pragmatism and reaction to what SDL users want. What they
want eventually gets written and included. It isn’t perfect, but it is
very very good.One of the nicest things about SDL is that it is possible to write
good games using just SDL. Having a single library to start with is
more important for learning than people seem to believe. You can learn
all the concepts working with a single library and a single set of
documentation. Think about the beginner who wants to get started but
doesn’t even know how to find all the different libraries needed to
develop a game? The skill level need to be able to decide if you can
even use two libraries in the same program is way beyond any beginner
and beyond some fairly experience programmers. It also helps that
there is a huge community of people who actually answer questions. The
value of having a single point of contact with all the concepts, the
documentation, and a community is immense.If we wanted to move SDL more toward #1 we could throw out much of SDL
and leave only enough of the graphics and input code so that it
becomes an event based alternative to glut with a very nice input
handler. Sound could be passed off to OpenAL or what ever people
liked. Image handling, IO, and many other things that are currently
part of SDL could be replaced with other existing libraries. We would
just document how to make them work with SDL.If we wanted to move SDL more toward #2 we would do well to go out an
take a long look at the apache portable runtime, the Netscape portable
runtime, and wxWidgets (everything including the kitchen sink, but you
have to do it their way). Getting to #2 is a major project.I do not know what the underlying philosophy of SDL is. I’m not sure
there is a stated philosophy. I’m not sure it would be a good idea to
have one. I rather like the idea that SDL is driven by what people
want and by changes in technology. I do believe it is important to
remember that everyone sees the parts of SDL they use as being
important and tend to disregard the rest.–
This is very interesting to me.
Bob Pendleton
On Mon, Apr 12, 2010 at 11:09 PM, Sam Lantinga wrote:
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?Thanks!
-Sam Lantinga, Founder and President, Galaxy Gameworks LLC
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org