Right, but you don’t have to DOWNLOAD stdio seperately! 
Of course you do. I’ve had to tell lots of people to install
glibc-devel in order to build programs.
I suppose you’re right, but I think this scenario is a bit different than
making yet another SDL_* library that SDL depends on.
Adding features to SDL that help it accomplish it’s goals is in absolutely
no way “bloating” the API. It is providing SDL with the functionality it
Of course it is, if those features could be useful to other people who
don’t want to carry around SDL’s baggage.
From this perspective you’re probably right. It prevents other utilities
from having to use all of SDL. I was arguing with the perspective that
adding this to SDL would be un-necessary bloat within SDL. I see this
library as being a critical part of enhancing SDL.–
Brian
I think that’s a pretty weak argument. None of SDL’s API calling
conventions, etc., strike me as purposefully consistent except in
their namespace wart. The ABI seems to break with some regularity.
Yeah, that’s a sad part of learning how to make a consistent API on the fly.
Ah well.
There is a reason that Unix-style programming and development is so
productive--it is built around the idea of small, independent
programs, libraries, etc., that can be connected in interesting and
efficient ways.
This is true.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Sam Lantinga wrote:
As I’m working with assembly, it becomes very nice to be able to detect
what features are available on the current platform.
So I’m adding an API to SDL to detect these.
If you are adding such machine depending stuff:
I have following function:
/**
** Read the tsc (time-stamp counter) register of the processor.**
** @return the rtc register
*/
static __inline u_int64_t rdtsc(void)
{
#ifdef i386
u_int64_t rv;
__asm __volatile(".byte 0x0f, 0x31" : "=A" (rv));
#endif
#ifdef alpha
int rv;
__asm __volatile("rpcc %0" : "=r" (rv));
#endif
return rv;
}
This function needs no context switch and could be used for
very small delays or to time (benchmark) routines.
Perhaps this is also useful for the library?
Bye,
Johns
Become famous, earn no money, create graphics for FreeCraft.
http://FreeCraft.Org - A free fantasy real-time strategy game engine
http://fgp.cjb.net - The FreeCraft Graphics Project
I still don’t see where “bloat” is coming from! All SDL modules video,
audio, cdrom, timer, threads, etc. do not have any interdependancies
besides the core SDL stuff (RWops, byte-ordering, error messages, etc.).
Even the documentation (as sparse as it is) is split into the main
functional categories. You can’t get much more “modularized” than that.
If you have any problems deciding what you want to go in your program,
type configure --help and check out all of the --enable options. You can
"modularize" your build process to your hearts content.
If it wasn’t for these abstractions (I think it’s pretty cool), some ports
wouldn’t be possible, the upcoming port for PSX won’t have threads or
timers initially, but will have video, audio, and cdrom.
The programs written in SDL decide what capabilities they need. So what
if you have a massive SDL shared library with every possible routine - it
is a shared library and there will be apps that need all of the
functionality.
MarcusOn Thu, 16 Mar 2000 hayward at slothmud.org wrote:
Right, but you don’t have to DOWNLOAD stdio seperately!
Of course you do. I’ve had to tell lots of people to install
glibc-devel in order to build programs.
I suppose you’re right, but I think this scenario is a bit different than
making yet another SDL_* library that SDL depends on.
Adding features to SDL that help it accomplish it’s goals is in absolutely
no way “bloating” the API. It is providing SDL with the functionality it
Of course it is, if those features could be useful to other people who
don’t want to carry around SDL’s baggage.
From this perspective you’re probably right. It prevents other utilities
from having to use all of SDL. I was arguing with the perspective that
adding this to SDL would be un-necessary bloat within SDL. I see this
library as being a critical part of enhancing SDL.
–
Brian
Michael Vance wrote:
the modules should have a consistent API so it is easy to learn and the
general pattern is easily understandable (the purpose of STL).
I think that’s a pretty weak argument. None of SDL’s API calling
conventions, etc., strike me as purposefully consistent except in
their namespace wart. The ABI seems to break with some regularity.
Maybe… actually I had another API in mind when I wrote the mail.
ClanLibs raison d’etre (where are those acecnts on an English
keyboard???) is to unite all that low level libs in one easy way and to
learn one high level API (and to add functionality that isn’t provided
by other libs).
There is a reason that Unix-style programming and development is so
productive--it is built around the idea of small, independent
programs, libraries, etc., that can be connected in interesting and
efficient ways.
Yes, but most beginners and ‘switchers’ want a single API to do what
they want. What is the purpose of learning a dozen different APIs with
different design patterns if you can have one conistent one that unites
what you need. Sure for a general purpose the small independet libs goal
is the best one, but if you aim at something particular like game
development you better have one API that unites them. I did port OpenUT
to use SDL because at that time it was the easiest way to get fullscreen
without fearing to crash the X Server. Sure, I just could have ripped
SDLs fullscreen code (I added some fullscreen code to OpenUT that is not
based on SDL, too, but it proved to be less stable) but I thought like I
don’t want to maintain that part.
Unix may have some very cool libraries that suit your needs but you
either don't know them or they are way to specialized and you will end
up writing a wrapper by yourself to use them. Basically it all boils
down that you want something like MS did. One API, one compiler, one way
to do it! I am not a MS fan, but one thing they did understand is that
time is money and that the fewer you have to learn leads to the less
amount of time spent with development. Also note that the
interoperability of many libs may become a problem too. My uncle did
work on the navigation/ radar system of the Tornado and one of the main
problems he had was to unite the different APIs and modules. So on the
one hand it is cool to have different choices and modules, but on the
other hand you want other people to figure out the details - especially
if you interact with many modules/ libs.
--
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
Adding features to SDL that help it accomplish it’s goals is in absolutely
no way “bloating” the API. It is providing SDL with the functionality it
Of course it is, if those features could be useful to other people who
don’t want to carry around SDL’s baggage.
Thats why we have Open Source. If you want to use the functions, take them
out of SDL and use them.
Long live the confused,
Akawaka.On Thu, 16 Mar 2000, Michael Vance wrote:
Bother! said Capt. Pooh, as antimatter containment was lost.
Yes, but most beginners and ‘switchers’ want a single API to do what
they want. What is the purpose of learning a dozen different APIs with
Without being too arrogant, I’m not really interested in the opinions
of those with little experience.
different design patterns if you can have one conistent one that unites
what you need. Sure for a general purpose the small independet libs goal
Because it never works out that the monolithic implementation is a)
easier to use or b) cleaner in implementation and evolution.
either don’t know them or they are way to specialized and you will end
up writing a wrapper by yourself to use them. Basically it all boils
Hm? Any programming exercise involves abstraction, so I don’t quite
understand what you’re saying.
down that you want something like MS did. One API, one compiler, one way
to do it! I am not a MS fan, but one thing they did understand is that
time is money and that the fewer you have to learn leads to the less
Development under Windows is so painful I don’t know where to
start. Their “one way” cost me time and money because I could never
get anything done using their tools. Their API style (COM) was
incredibly awkward to use and resulted in unreadable and
unmaintainable code. The APIs evolved at such a rate that it was
painful to keep up with (ie, D3D vs. OpenGL) the exciting new versions
and incompatabilities.
Rant, rant, rant :).
m.On Fri, Mar 17, 2000 at 12:41:15AM +0100, Daniel Vogel wrote:
–
Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire
Thats why we have Open Source. If you want to use the functions, take them
out of SDL and use them.
Yech.
“Thou shalt not duplicate code.”
Especially when there’s no reason to do so.
m.On Fri, Mar 17, 2000 at 12:52:44AM +0000, Martin Donlon wrote:
–
Programmer “Ha ha.” “Ha ha.” "What are you laughing at?"
Loki Software "Just the horror of being alive."
http://lokigames.com/~briareos/ - Tony Millionaire
Thats why we have Open Source. If you want to use the functions, take them
out of SDL and use them.
Yech.
“Thou shalt not duplicate code.”
Especially when there’s no reason to do so.
Folks, these are very good points, and I’ve decided not to add CPU functions
to the SDL API, but your discussion is now suited more towards an advocacy
list. Please take it offline at this point, or to an advocacy list.
Thanks.
-Sam Lantinga (slouken at devolution.com)
Lead Programmer, Loki Entertainment Software> On Fri, Mar 17, 2000 at 12:52:44AM +0000, Martin Donlon wrote:
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec
Michael Vance wrote:
Without being too arrogant, I’m not really interested in the opinions
of those with little experience.
Hehe, if an API is not easily understandable it is crap. So if a
beginner can’t understand it you should consider changing it. A
professional can adapt to any API - how ugly it may be - that makes him/
her a professional.
Because it never works out that the monolithic implementation is a)
easier to use or b) cleaner in implementation and evolution.
I doubt that. Actually I think ClanLib is doing a good job at it. If you
don’t believe in a) and b) why does OpenAL have 2d sound support ;–)
Okay, this is getting too off topic so I apologize for it and will keep
further mails private.
Hm? Any programming exercise involves abstraction, so I don’t quite
understand what you’re saying.
What I wanted to say is that too many small little libs will only force
you to write a unified wrapper for them that will allow you to use them
in a ‘standard’ way. Like having a common API pattern for all of them.
Development under Windows is so painful I don’t know where to
start. Their “one way” cost me time and money because I could never
get anything done using their tools. Their API style (COM) was
Okay, maybe it was not the best example as their APIs are suboptimal
(although some people tell me that MFC really is not crap), but only
having one API is a big plus. On second thought it really was a bad
example…
Rant, rant, rant :).
Yes How about a sdl-rant@ mailing list ;)–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right