Everyone read please!

Joe_Tennies · January 18, 2002, 8:47am

This is my personal understanding of SDL and how it should be designed
(please tell me if I’m wrong)

SDL is designed to be a low-level cross-platform method to implement various
systems that are different amongst various OSs/WMs.

This means that a functions like SDL_TicksSince() should NOT be implemented
in the SDL. There is nothing specific to the OS about it. Any call that
only does calls into the SDL is not worth implementing. The only way
something should be added to SDL that can already be gotten from SDL (no
matter how difficult) is if there are OS specific optimizations that can be
used to get that value quicker.

This is good for abstracting OS specific parts. This is bad for the casual
programmer/newbie. Therefore, I propose we make 2 public domain .h files
(SDLu and SDLGLu). These would contain common ways to do various things
people may not realize they can do indirectly from SDL. It will also be
made known that the .h files contain ‘catch-all’ versions of how to complete
a given task and can be made faster if some knowledge is known beforehand
about the data being passed to it.

People may be saying ‘why public domain?’ I suggest public domain because
it will allow people to look at the code and see how such things can be
implemented (therefore open-sourced, which I doubt anyone will complain
about). It should be public domain over LGPL because I proposed they be
just .h files. This means just including these libraries force the program
to be completely open-sourced. (It actually forces it to be open-sourced if
they use an implementation to do something used in the .h file after looking
at the .h file – including trivial things.) This would also allow people
to ‘pull’ several functions they use out and just include those ones. It is
also HIGHLY unlikely that such implementations will change. The SDL is
standardized, therefore the implementation to get a given result will not
either.

Jimmy · January 18, 2002, 9:16am

Right off, I don’t know about anyone else, but I think the subject here
is just obnoxious. I thought somehow spam had gotten filtered into my
SDL box by mistake.

This is my personal understanding of SDL and how it should be designed
(please tell me if I’m wrong)

SDL is designed to be a low-level cross-platform method to implement various
systems that are different amongst various OSs/WMs.

This means that a functions like SDL_TicksSince() should NOT be implemented
in the SDL. There is nothing specific to the OS about it. Any call that
only does calls into the SDL is not worth implementing. The only way
something should be added to SDL that can already be gotten from SDL (no
matter how difficult) is if there are OS specific optimizations that can be
used to get that value quicker.
I can agree with this.

This is good for abstracting OS specific parts. This is bad for the casual
programmer/newbie. Therefore, I propose we make 2 public domain .h files
(SDLu and SDLGLu). These would contain common ways to do various things
people may not realize they can do indirectly from SDL. It will also be
made known that the .h files contain ‘catch-all’ versions of how to complete
a given task and can be made faster if some knowledge is known beforehand
about the data being passed to it.

People may be saying ‘why public domain?’ I suggest public domain because
it will allow people to look at the code and see how such things can be
implemented (therefore open-sourced, which I doubt anyone will complain
about).
Any open license will allow this.

It should be public domain over LGPL because I proposed they be
just .h files. This means just including these libraries force the program
to be completely open-sourced.
SDL has been released with LGPL precisely to avoid this. Why would you
want to contribute to a project with a spirit that is so different than
the project you’re contributing to. Not to mention the fact that the
adoption rate would be nill. AND even more importantly, you’re talking
about the GPL here, not public domain.
All public domain licenses have been historicly even more lenient
towards commercialization and extension without publication.

(It actually forces it to be open-sourced if

they use an implementation to do something used in the .h file after looking
at the .h file – including trivial things.) This would also allow people
Code in headers is baaad.On Fri, 2002-01-18 at 11:46, Fro Joe wrote:

to ‘pull’ several functions they use out and just include those ones. It is
also HIGHLY unlikely that such implementations will change. The SDL is
standardized, therefore the implementation to get a given result will not
either.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–

End of Rant.

Jimmy
JimmysWorld.org

StephenJSweeney · January 18, 2002, 9:39am

I just didn’t even understand the message at all! Especially that bit
about SDL being bad for newbies… The only reason I took up C was because
SDL made it look so easy(!)> -----Original Message-----

From: Jimmy [SMTP:jimmy at jimmysworld.org]
Sent: Friday, January 18, 2002 5:16 PM
To: SDL Mailing List
Subject: Re: [SDL] EVERYONE READ PLEASE!

Right off, I don’t know about anyone else, but I think the subject here
is just obnoxious. I thought somehow spam had gotten filtered into my
SDL box by mistake.

On Fri, 2002-01-18 at 11:46, Fro Joe wrote:

This is my personal understanding of SDL and how it should be designed
(please tell me if I’m wrong)

SDL is designed to be a low-level cross-platform method to implement
various
systems that are different amongst various OSs/WMs.

This means that a functions like SDL_TicksSince() should NOT be
implemented
in the SDL. There is nothing specific to the OS about it. Any call
that
only does calls into the SDL is not worth implementing. The only way
something should be added to SDL that can already be gotten from SDL (no
matter how difficult) is if there are OS specific optimizations that can
be
used to get that value quicker.
I can agree with this.

This is good for abstracting OS specific parts. This is bad for the
casual
programmer/newbie. Therefore, I propose we make 2 public domain .h
files
(SDLu and SDLGLu). These would contain common ways to do various things
people may not realize they can do indirectly from SDL. It will also be
made known that the .h files contain ‘catch-all’ versions of how to
complete
a given task and can be made faster if some knowledge is known
beforehand
about the data being passed to it.

People may be saying ‘why public domain?’ I suggest public domain
because
it will allow people to look at the code and see how such things can be
implemented (therefore open-sourced, which I doubt anyone will complain
about).
Any open license will allow this.

It should be public domain over LGPL because I proposed they be
just .h files. This means just including these libraries force the
program
to be completely open-sourced.
SDL has been released with LGPL precisely to avoid this. Why would you
want to contribute to a project with a spirit that is so different than
the project you’re contributing to. Not to mention the fact that the
adoption rate would be nill. AND even more importantly, you’re talking
about the GPL here, not public domain.
All public domain licenses have been historicly even more lenient
towards commercialization and extension without publication.

(It actually forces it to be open-sourced if

they use an implementation to do something used in the .h file after
looking
at the .h file – including trivial things.) This would also allow
people
Code in headers is baaad.

to ‘pull’ several functions they use out and just include those ones.
It is
also HIGHLY unlikely that such implementations will change. The SDL is
standardized, therefore the implementation to get a given result will
not
either.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–

End of Rant.

Jimmy
JimmysWorld.org

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Jim_Wilson · January 18, 2002, 9:49am

Jimmy said:

Right off, I don’t know about anyone else, but I think the subject here
is just obnoxious. I thought somehow spam had gotten filtered into my
SDL box by mistake.

Agreed, And I skipped reading it just because I don’t like being told what to
do with my email.

Joe_Tennies · January 18, 2002, 11:10am

SDL is far from the easiest method to implement anything. It’s actually
quite low-level.

SDL also has many things that can be figured out with only a couple calls.
This is what makes it so powerful, but not everyone realizes some of these
things at first glance.

I can’t even begin to count how often the question ‘How do I make a OpenGL
Texture from a SDL_Surface?’ has come up. Then there’s these recent things.
I think that a SDLu and SDLGLu that would be distributed with the SDL
developement kit would help (or just making a seperate DL on the same page).> ----- Original Message -----

From: sweenes@fnb.co.uk (Steven Sweeney))
To:
Sent: Friday, January 18, 2002 11:35 AM
Subject: RE: [SDL] EVERYONE READ PLEASE!

I just didn’t even understand the message at all! Especially that bit
about SDL being bad for newbies… The only reason I took up C was because
SDL made it look so easy(!)

-----Original Message-----
From: Jimmy [SMTP:jimmy at jimmysworld.org]
Sent: Friday, January 18, 2002 5:16 PM
To: SDL Mailing List
Subject: Re: [SDL] EVERYONE READ PLEASE!

Right off, I don’t know about anyone else, but I think the subject here
is just obnoxious. I thought somehow spam had gotten filtered into my
SDL box by mistake.

On Fri, 2002-01-18 at 11:46, Fro Joe wrote:

This is my personal understanding of SDL and how it should be designed
(please tell me if I’m wrong)

SDL is designed to be a low-level cross-platform method to implement
various
systems that are different amongst various OSs/WMs.

This means that a functions like SDL_TicksSince() should NOT be
implemented
in the SDL. There is nothing specific to the OS about it. Any call
that
only does calls into the SDL is not worth implementing. The only way
something should be added to SDL that can already be gotten from SDL
(no

matter how difficult) is if there are OS specific optimizations that
can

be

used to get that value quicker.
I can agree with this.

This is good for abstracting OS specific parts. This is bad for the
casual
programmer/newbie. Therefore, I propose we make 2 public domain .h
files
(SDLu and SDLGLu). These would contain common ways to do various
things

people may not realize they can do indirectly from SDL. It will also
be

made known that the .h files contain ‘catch-all’ versions of how to
complete
a given task and can be made faster if some knowledge is known
beforehand
about the data being passed to it.

People may be saying ‘why public domain?’ I suggest public domain
because
it will allow people to look at the code and see how such things can
be

implemented (therefore open-sourced, which I doubt anyone will
complain

about).
Any open license will allow this.

It should be public domain over LGPL because I proposed they be
just .h files. This means just including these libraries force the
program
to be completely open-sourced.
SDL has been released with LGPL precisely to avoid this. Why would you
want to contribute to a project with a spirit that is so different than
the project you’re contributing to. Not to mention the fact that the
adoption rate would be nill. AND even more importantly, you’re talking
about the GPL here, not public domain.
All public domain licenses have been historicly even more lenient
towards commercialization and extension without publication.

(It actually forces it to be open-sourced if

they use an implementation to do something used in the .h file after
looking
at the .h file – including trivial things.) This would also allow
people
Code in headers is baaad.

to ‘pull’ several functions they use out and just include those ones.
It is
also HIGHLY unlikely that such implementations will change. The SDL
is

standardized, therefore the implementation to get a given result will
not
either.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–

End of Rant.

Jimmy
JimmysWorld.org

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Mathieu_Girard · January 18, 2002, 11:25am

My two cents :

He just propose a OpenGL’s Glut.h like for SDL.
Wanna get Double-Click ? It’s in SDL_lut.h or something
like that. It’s not a bad idea… we can put in somes
function like fade_in, fade_out, etc… but look what OpenGL
done with his Glut.h … they flushed it. (I’m right ??)
All guys I know start with it, and flush it after 1 or 2 weeks
of development…

And the utilization of Glut.h is very slow… non-optimized
methods… etc… (Should be the same for SDLGlut.h… fade_out
in all valid video_mode, full screen or not, etc… but imagine
the FAT fade_out function this can made… I don’t see
for now the need of a glut like in SDL… SDL got SOMES examples
to show everyone how to work with it. Just look Parralax 2 := it
show you how to use SDL. Parralax 3 show you how to optimize it.
Somes others show their way to Fade_in/Out. Optimized or not!
We don’t need more !!

…I’m right ?? ehe

Jim Wilson wrote:> Jimmy said:

Right off, I don’t know about anyone else, but I think the subject here
is just obnoxious. I thought somehow spam had gotten filtered into my
SDL box by mistake.

Agreed, And I skipped reading it just because I don’t like being told what to
do with my email.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

.

Bill_Kendrick · January 18, 2002, 11:39am

Just curious… what does double-clicking have to do with OpenGL?
Or did I not understand what you meant.

-bill!
who wants to do an SDL_prefs library which transparently handles
.rc, .INI and whatever-Macs/BeOS-use :)On Fri, Jan 18, 2002 at 02:23:16PM -0500, Gerard wrote:

My two cents :

He just propose a OpenGL’s Glut.h like for SDL.
Wanna get Double-Click ? It’s in SDL_lut.h or something

David_Olofson · January 18, 2002, 12:12pm

My two cents :

He just propose a OpenGL’s Glut.h like for SDL.
Wanna get Double-Click ? It’s in SDL_lut.h or something

Just curious… what does double-clicking have to do with OpenGL?
Or did I not understand what you meant.

I think Gerard is referring to the general idea of “toolkit libraries”;
not specifically GLUT.

-bill!
who wants to do an SDL_prefs library which transparently handles
.rc, .INI and whatever-Macs/BeOS-use

You might find some ideas in the config_parser_t class in Kobo Deluxe. It
doesn’t deal with platform specific APIs, but it does parse command line
arguments as well as configuration files, and connects the data directly
to variables. There’s also support for default values, copying of entire
configurations, command line “commands” and other handy stuff.

Oh, and there’s also a portable file path manager/translator, a stack
based “application state manager” and other fun stuff that I can’t even
remeber. Most of it is C++, and at least the state manager seems pretty
hard to port to C in any useful way. The new audio engine is still 100%
C, though.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 18 January 2002 20:38, William Kendrick wrote:

On Fri, Jan 18, 2002 at 02:23:16PM -0500, Gerard wrote:

Mathieu_Girard · January 18, 2002, 12:14pm

Did you read me to the end ?

Just curious… what does double-clicking have to do with OpenGL?
Or did I not understand what you meant.

It’s a comparation! Not more. (e.g. : GL has done stuff this way, why
we don’t do the same way)

He just said that if you add somes “DELUXE” stuff to SDL,
add it in a separated .h . For all the guys who don’t
want a nice but slow function like fade_out or DblClickDetect
or else, just not include SDLdeluxefunction.h !!! It’s easy to
understand no? And it gave the possibility to newbies
to use the DblClick and fade_out function (just include the
f**k’n .h! ).

And in my last message, I was telling that we don’t need yet
this kind of .h . Perhaps later, but not yet!

SDL is enough easy for now! We got plenty of demos/apps with
open code… so… + a little and precise API…

William Kendrick wrote:> On Fri, Jan 18, 2002 at 02:23:16PM -0500, Gerard wrote:

My two cents :

He just propose a OpenGL’s Glut.h like for SDL.
Wanna get Double-Click ? It’s in SDL_lut.h or something

Just curious… what does double-clicking have to do with OpenGL?
Or did I not understand what you meant.

-bill!
who wants to do an SDL_prefs library which transparently handles
.rc, .INI and whatever-Macs/BeOS-use

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

.

David_Olofson · January 18, 2002, 12:23pm

SDL is far from the easiest method to implement anything. It’s
actually quite low-level.

Maybe that’s exactly why it’s simple and straightforward to some people -
like those of us who used to do everything in assembly language,
accessing the hardware directly…? Anything higher level than raw frame
buffers and audio streams is just added complexity!

SDL also has many things that can be figured out with only a couple
calls. This is what makes it so powerful, but not everyone realizes
some of these things at first glance.

Yeah. You have to know what you want to do, and how it’s actually done.

I can’t even begin to count how often the question ‘How do I make a
OpenGL Texture from a SDL_Surface?’ has come up. Then there’s these
recent things. I think that a SDLu and SDLGLu that would be distributed
with the SDL developement kit would help (or just making a seperate DL
on the same page).

Maybe… But judging by the lack of such libraries (despite many ideas,
and many started projects, it seems!), it’s hard to come up with
something that’s easier to learn than just writing the code yourself, and
at the same time powerful enough to actually do something useful.

It’s mostly trivial code that can be found in countless versions in
different projects, so it can’t be the implementation part that’s
troublesome…

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 18 January 2002 19:33, Fro Joe wrote:

Jimmy · January 18, 2002, 12:30pm

The larger issue at work here was the idea of having simple utility
add-on libraries for SDL. I think that’s where double-click came from.
GL functions where just a different example. Though double-click is a
particularly bad example given it was beaten with the repetitive stick
only a measurement of hours ago in a different discussion. Makes it
easy to confuse with the old issue.

He does mention something I agree with and that’s that every time big
time-saver utility libraries like this get started it becomes apparent
that in most every case efficiency or mode/design issues make the canned
functions useless, or so wildly inefficient that they are effectively
useless.

By time you have a useful short-cut function written that is
sufficiently flexible to be used across all possible modes it’s so fat
and ugly that it can’t be realistically used anyway. Either it’s too
slow or it has so many special rules associated with it that it never
quite fits.

It’s probably better to show people the way to do something with
tutorials than to write a utility library to do it for them.On Fri, 2002-01-18 at 14:38, William Kendrick wrote:

On Fri, Jan 18, 2002 at 02:23:16PM -0500, Gerard wrote:

My two cents :

He just propose a OpenGL’s Glut.h like for SDL.
Wanna get Double-Click ? It’s in SDL_lut.h or something

Just curious… what does double-clicking have to do with OpenGL?
Or did I not understand what you meant.

-bill!
who wants to do an SDL_prefs library which transparently handles
.rc, .INI and whatever-Macs/BeOS-use

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
–

End of Rant.

Jimmy
JimmysWorld.org

David_Olofson · January 18, 2002, 1:19pm

[…]

By time you have a useful short-cut function written that is
sufficiently flexible to be used across all possible modes it’s so fat
and ugly that it can’t be realistically used anyway. Either it’s too
slow or it has so many special rules associated with it that it never
quite fits.
[…]

A totally different design approach that seems to work better in real
life is the “engine model”, which I’m using quite heavily nowadays. The
basic idea is to cut down the number of situations where a function call
directly performs a very specific operation on some data, and instead
focus on passing your data to an engine, and “explaining” to it what to
do - but not how to do it.

That allows for much more implementation flexibility and heavier
optimization than traditional libraries, without having those nasty
"special cases" leaking through the API.

However, now we’re talking about very high level beats - far from toolkit
libraries! Seems like high or low level APIs are fine for libraries
and engines, but anything in between just has to suck.

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |-------------------------------------> http://olofson.net -'On Friday 18 January 2002 21:30, Jimmy wrote:

slouken · January 18, 2002, 1:24pm

It’s probably better to show people the way to do something with
tutorials than to write a utility library to do it for them.

I agree. Tutorials rock. Most people just want the pieces that interest
them, and usually have half of what they need already anyway.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Bob_Pendleton · January 18, 2002, 2:27pm

Jimmy wrote:

It’s probably better to show people the way to do something with
tutorials than to write a utility library to do it for them.

I think that is an important observation. It would be great if people
turned their clever and creative snips of SDL code into tutorials. There
are many cases where it is much easier to cut, paste, and edit an
example to do what you want than it is to figure out that some library
routine will do the same job if you just read and understand the 5 pages
of documentation.

	Bob P.--

±-----------------------------------+

Bob Pendleton is seeking contract +
and consulting work. Find out more +
at http://www.jump.net/~bobp +
±-----------------------------------+

Mathieu_Girard · January 18, 2002, 2:47pm

David Olofson wrote:

I think Gerard is referring to the general idea of “toolkit libraries”;
not specifically GLUT.

Yep, exactly what I means… but it’s a bad idea. Tutorials and
example code are much
better and more effective for learning experiences than just easy but
shitty functions

“Excuse/pardon” me if sometimes I’m hard to understand. English
is not my “first/birth/familiar/whatever!!!” languages.
I’m a french Canadian…

So… Codez pleins de jeux toute la fin de semaine!!!
So… let’s code somes games all the weekend!

See you monday! (somes problems with rpppoe/MASQ kernel module ;o( )

Mathieu_Girard · January 18, 2002, 2:52pm

Bob Pendleton wrote:

I think that is an important observation. It would be great if people
turned their clever and creative snips of SDL code into tutorials.

Tell me if it’s a good “tutorial” idea : a C/C++ Squeletton projects +
makefile stuff ??
My makefile don’t work yet but I’m reading “GNU autoconf, automake and
libtool” so
it 'll work soon (So i’m still compiling with a 1 miles long g++
command…)

Just to help people to start a new “SDL Object Oriented” project… no ?

Bob_Pendleton · January 18, 2002, 3:06pm

mgirard wrote:

Bob Pendleton wrote:

I think that is an important observation. It would be great if people
turned their clever and creative snips of SDL code into tutorials.

Tell me if it’s a good “tutorial” idea : a C/C++ Squeletton projects +
makefile stuff ??
My makefile don’t work yet but I’m reading “GNU autoconf, automake and
libtool” so
it 'll work soon (So i’m still compiling with a 1 miles long g++
command…)

Yes, I’d love to see that.

Just to help people to start a new “SDL Object Oriented” project… no ?

On the other hand, if you just want a simple makefile that will compile
your SDL program let me know and I will send you one that is already set
up to compile SDL programs using G++. I think the guy who invented Make
was the first and only person to actually write a makefile. Everyone
else just copies one they found sitting around on disk some where and
editted it for their own use. Please, feel free to write your own, but
if you just want to compile and run, let me know and I’ll send you one.

Bob Pendleton--

±-----------------------------------+

Bob Pendleton is seeking contract +
and consulting work. Find out more +
at http://www.jump.net/~bobp +
±-----------------------------------+

Jason_Farmer · January 18, 2002, 5:05pm

SDL is far from the easiest method to implement anything. It’s
actually quite low-level.

This is my 1st post, so go easy on me

IMHO, SDL is quite low level, but that’s where it’s power lies. Also, because
it’s not bogged down with helper functions, it’s easier to learn. The term
Less is more actually applies here.

Maybe that’s exactly why it’s simple and straightforward to some people -
like those of us who used to do everything in assembly language,
accessing the hardware directly…? Anything higher level than raw frame
buffers and audio streams is just added complexity!

I use SDL in Delphi and Kylix (object Pascal) and I was used to the
simplicity of the DelphiX components and was a little worried about coming
down from the comfy high level components to SDL. I can see why newbies might
feel overwhelmed at first.

But after reading the documentation and playing with the examples, I found it
just as easy to use… even easier in some cases because it wasn’t wrapped up
in some obscure object structure that needed learning before you got anything
done.

Also, SDL is much simpler to use than DirectX ever was.

SDL also has many things that can be figured out with only a couple
calls. This is what makes it so powerful, but not everyone realizes
some of these things at first glance.

Yeah. You have to know what you want to do, and how it’s actually done.

I reckon that if a developer wants to use helper functions, they’ll either
write their own or get them from elsewhere when they think they need them.

What might be better, instead of writing a large and complicated set of
helper functions and making them a part of SDL (SDL would then be known as
klunky and bloated and after a while, mostly redundant), How about a tips and
tricks section or Knowledge base to the LibSDL website (or some other site)
where techniques like Double clicking and getting the number of ticks since
the game started or how to make OpenGL textures from SDL surfaces could be
explained. They could include basic code snippets to get the general idea
across and then leave it to the developer to find a better way on their own.

I can’t even begin to count how often the question ‘How do I make a
OpenGL Texture from a SDL_Surface?’ has come up. Then there’s these
recent things. I think that a SDLu and SDLGLu that would be distributed
with the SDL developement kit would help (or just making a seperate DL
on the same page).

Maybe… But judging by the lack of such libraries (despite many ideas,
and many started projects, it seems!), it’s hard to come up with
something that’s easier to learn than just writing the code yourself, and
at the same time powerful enough to actually do something useful.

It’s mostly trivial code that can be found in countless versions in
different projects, so it can’t be the implementation part that’s
troublesome…

I agree.
Keep it small, Keep it simple and leave the code bloat to Other Libraries.

Jason Farmer
Cerebral Bicycle CompanyOn Friday 18 January 2002 8:22 pm, you wrote:

On Friday 18 January 2002 19:33, Fro Joe wrote:

Joe_Tennies · January 18, 2002, 5:07pm

Part of this conversation came from the discussion about double clicks and
Uint64 timers that has been rampaging the SDL list. (I must say I probably
helped it out some before I started thinking about it.)

I am not talking about GLUT though. I am trying to draw an equivalence to
GLU.

First, glut added much functionality that SDL adds (standard method to open
a window, mouse and keyboard handling, etc.)

GLU added things like Perspective, Ortho 3D, and things like that (I am
hoping I got those correct, Red Book is not right next to me.) Those are
things I’m talking about implementing. Things that can be fairly easily
abstracted from the functions in SDL, but may not be quite so visible at
first glance. It would add a layer of abstraction to some functions in SDL
that would make it easier for a newbie to look at and go OHHH. And then
they can look through and optimize their code at a later time.

Here’s my basic proposal:

Nothing over like 10 lines of actual code
Well documented to say why the code there works and perhaps suggestions to
optimize it.

// Returns time between baseTime and Current Time in MS.
// Does cover wrapping of Uint32
Uint32 SDLu_TimeSince(Uint32 baseTime)
{
// works because value is unsigned and the way it overflows
return (SDL_GetTicks() - baseTime);
}

Fade effects are WAY more than I am talking about. I mean things that are
only a couple lines and may not be obvious to the newbie. Basically, take a
second semester C/C++ programmer (no graphics, no in depth). Now make the
things that you take for granted because you’ve seen them before in the
AMIGA or C64 obvious to them. (Chances are they won’t even remember the
C64… lucky if AMIGA.)

That is my goal. Nothing fancy, just things that are not blatently obvious
to someone w/ a year experince programming. Again, we make it known that
these functions may be “all purpose” and may not be optimized for a specific
case they are taking into account. Again, nothing system specific, as those
should be in the SDL, but things just 1 level higher.> ----- Original Message -----

From: nbs@sonic.net (Bill Kendrick)
To:
Sent: Friday, January 18, 2002 1:38 PM
Subject: Re: [SDL] EVERYONE READ PLEASE!

On Fri, Jan 18, 2002 at 02:23:16PM -0500, Gerard wrote:

My two cents :

He just propose a OpenGL’s Glut.h like for SDL.
Wanna get Double-Click ? It’s in SDL_lut.h or something

Just curious… what does double-clicking have to do with OpenGL?
Or did I not understand what you meant.

-bill!
who wants to do an SDL_prefs library which transparently handles
.rc, .INI and whatever-Macs/BeOS-use

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

Joe_Tennies · January 18, 2002, 5:21pm

This was going to be my other suggestion as many people seem to be knocking
down the idea of the SDLu.

Make something smaller than a tutorial. Basically take a question and show
several ways to implement it and show a person how they can go from a->b and
some special cases that may pop-up.> ----- Original Message -----

From: jason@cerebral-bicycle.co.uk (Jason Farmer)
To:
Sent: Friday, January 18, 2002 5:04 PM
Subject: Re: [SDL] EVERYONE READ PLEASE!

On Friday 18 January 2002 8:22 pm, you wrote:

On Friday 18 January 2002 19:33, Fro Joe wrote:

SDL is far from the easiest method to implement anything. It’s
actually quite low-level.

This is my 1st post, so go easy on me

IMHO, SDL is quite low level, but that’s where it’s power lies. Also,
because
it’s not bogged down with helper functions, it’s easier to learn. The term
Less is more actually applies here.

Maybe that’s exactly why it’s simple and straightforward to some
people -

like those of us who used to do everything in assembly language,
accessing the hardware directly…? Anything higher level than raw frame
buffers and audio streams is just added complexity!

I use SDL in Delphi and Kylix (object Pascal) and I was used to the
simplicity of the DelphiX components and was a little worried about coming
down from the comfy high level components to SDL. I can see why newbies
might
feel overwhelmed at first.

But after reading the documentation and playing with the examples, I found
it
just as easy to use… even easier in some cases because it wasn’t wrapped
up
in some obscure object structure that needed learning before you got
anything
done.

Also, SDL is much simpler to use than DirectX ever was.

SDL also has many things that can be figured out with only a couple
calls. This is what makes it so powerful, but not everyone realizes
some of these things at first glance.

Yeah. You have to know what you want to do, and how it’s actually done.

I reckon that if a developer wants to use helper functions, they’ll either
write their own or get them from elsewhere when they think they need them.

What might be better, instead of writing a large and complicated set of
helper functions and making them a part of SDL (SDL would then be known as
klunky and bloated and after a while, mostly redundant), How about a tips
and
tricks section or Knowledge base to the LibSDL website (or some other
site)
where techniques like Double clicking and getting the number of ticks
since
the game started or how to make OpenGL textures from SDL surfaces could be
explained. They could include basic code snippets to get the general idea
across and then leave it to the developer to find a better way on their
own.

I can’t even begin to count how often the question ‘How do I make a
OpenGL Texture from a SDL_Surface?’ has come up. Then there’s these
recent things. I think that a SDLu and SDLGLu that would be
distributed

with the SDL developement kit would help (or just making a seperate DL
on the same page).

Maybe… But judging by the lack of such libraries (despite many ideas,
and many started projects, it seems!), it’s hard to come up with
something that’s easier to learn than just writing the code yourself,
and

at the same time powerful enough to actually do something useful.

It’s mostly trivial code that can be found in countless versions in
different projects, so it can’t be the implementation part that’s
troublesome…

I agree.
Keep it small, Keep it simple and leave the code bloat to Other Libraries.

Jason Farmer
Cerebral Bicycle Company

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl