SDL todo list

My immediate SDL TODO list:

  • Boolean type (desperately needed)
  • DMA audio driver under Linux
  • A general cvar-like system (name=value pairs)

The biggest piece left to do before releasing SDL 1.1.0 is the config
variables (cvars).

I’m missing something, but I forget what.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

My immediate SDL TODO list:

  • Boolean type (desperately needed)

What do you mean, boolean type? Just

#ifndef FALSE
#define FALSE 0
#define TRUE !FALSE
#endif

and defining a type bool as an unsigned character?

-Sam Lantinga (slouken at devolution.com)

Nicholas (writing while being late for chemistry! )

The biggest piece left to do before releasing SDL 1.1.0 is the config
variables (cvars).

Integration of this with a console (isn’t there one out there?) would be
quite nice.

Bret

Nice, I was just about to ask you if you could “bless” a release of 1.1
so that I coul “legally” build RPMs for Mandrake. It’s a minor detail, but
could you remember to call the archive SDL-1.1.0.tar.gz instead of
SDL-1.1.tar.gz as it is called now?

Regards,
	HakanOn Thu, 03 Feb 2000, you wrote:

The biggest piece left to do before releasing SDL 1.1.0 is the config


Hakan Tandogan hakan at iconsult.com

Sam Lantinga wrote:

The biggest piece left to do before releasing SDL 1.1.0 is the config
variables (cvars).

Can you give a quick explanation of what the cvars would do and
what they would be used for?

Cheers,
Nat.–
±-----------------------------------------±--------------------+
| Name: Nat Pryce MEng ACGI | Dept. of Computing, |
| Email: np2 at doc.ic.ac.uk | Imperial College, |
| Tel: +44 (0)171 594 8394 | 180 Queen’s Gate, |
| Fax: +44 (0)171 581 8024 | London SW7 2BZ, |
| WWW: http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom |
±-----------------------------------------±--------------------+

Of course. SDL-1.1.tar.gz is just the CVS snapshot name.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software> On Thu, 03 Feb 2000, you wrote:

The biggest piece left to do before releasing SDL 1.1.0 is the config

Nice, I was just about to ask you if you could “bless” a release of 1.1
so that I coul “legally” build RPMs for Mandrake. It’s a minor detail, but
could you remember to call the archive SDL-1.1.0.tar.gz instead of
SDL-1.1.tar.gz as it is called now?


“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

They are just like ini files in windows… it so you can easily store
settings in your game…

i have already started writing on… it uses binary though so you can put
more than just ascii in the field… it’s not finished. i would say its
about 90% finished… i don’t have anymore time to work on it at the
moment… anyone want to finish it?On Thu, 3 Feb 2000, Nat Pryce wrote:

Sam Lantinga wrote:

The biggest piece left to do before releasing SDL 1.1.0 is the config
variables (cvars).

Can you give a quick explanation of what the cvars would do and
what they would be used for?

Cheers,
Nat.

Oh! SDL_CreateGame(int type)

e.g. SDL_CreateGame(SDL_MADKILLERQUAKECLONE);
SDL_SellUnits(1000000);

Long live the confused,
Akawaka.–
Bother! said Pooh as Christopher Robin pleaded to be spanked again.

On Thu, 3 Feb 2000, Sam Lantinga wrote:

My immediate SDL TODO list:

  • Boolean type (desperately needed)
  • DMA audio driver under Linux
  • A general cvar-like system (name=value pairs)

The biggest piece left to do before releasing SDL 1.1.0 is the config
variables (cvars).

I’m missing something, but I forget what.

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software

“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

“Sam” == Sam Lantinga writes:

Sam> My immediate SDL TODO list:

Sam> * Boolean type (desperately needed)

I’d also suggest that in any case where you return zero for success
and some sort of non-zero for an error code that you always use some
sort of type in that case and not use int.

That way int can be used only for “signed integral quantity that is
fast for the underlying archtecture” and you’ll have other types to
meet your integral needs including specific bit sizes in signed and
unsigned amounts, your boolean type and the error type as your most
common types. Yay!

Sam> The biggest piece left to do before releasing SDL 1.1.0 is the
Sam> config variables (cvars).

Sam> I’m missing something, but I forget what.

SDL 1.0.4. It would be really nice to have one tonight that we can
ship that has just the audio changes that you, Markus and I have been
testing over the last few nights (including the SDL_AUDIODRIVER
environment fix).

–Cliff
@Clifford_T_Matthews

Oh! SDL_CreateGame(int type)

e.g. SDL_CreateGame(SDL_MADKILLERQUAKECLONE);
SDL_SellUnits(1000000);

Long live the confused,
Akawaka.

Bother! said Pooh as Christopher Robin pleaded to be spanked again.

laugh

Coming right up! :slight_smile:

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Oh! SDL_CreateGame(int type)

e.g. SDL_CreateGame(SDL_MADKILLERQUAKECLONE);
SDL_SellUnits(1000000);

Long live the confused,
Akawaka.

ohh please add SDL_CreateGame(SDL_MADKILLERNFS4CLONE)

Alain "burn rubber 'till you see god,brake,turn,yank the handbrake !!"
Toussaint

Sam Lantinga schrieb am 03 Feb 2000:

My immediate SDL TODO list:

  • A general cvar-like system (name=value pairs)

libPropList and libxml come to mind…

but then, something internal (not an external library) is nice too.
(I already see me removing 200 lines of code from glTron :slight_smile:

e.g. SDL_CreateGame(SDL_MADKILLERQUAKECLONE);
SDL_SellUnits(1000000);

Nah. Now if I could do, say:

SDL_CreateGame(SDL_3D | SDL_REALTIMESTRATEGY | SDL_SPACE_COMBAT_SIM);

Then the rest would take care of itself. :slight_smile:

-KW

What’s wrong with ‘int’?On Thu, Feb 03, 2000 at 09:04:42AM -0800, Sam Lantinga wrote:

My immediate SDL TODO list:

  • Boolean type (desperately needed)


– Michael Samuel <@Michael_Samuel>

Ryan wrote:

They are just like ini files in windows… it so you can easily store
settings in your game…

i have already started writing on… it uses binary though so you can put
more than just ascii in the field… it’s not finished. i would say its
about 90% finished… i don’t have anymore time to work on it at the
moment… anyone want to finish it?

I don’t think that should be in the core SDL libraries. There
are loads of parser libraries that can be used to do that.
I use XML for all the data files of my game (highscore table,
sprite sheets, level files, user settings, etc.), so that I have
only have to link to a single parser library.

Cheers,
Nat.–
±-----------------------------------------±--------------------+
| Name: Nat Pryce MEng ACGI | Dept. of Computing, |
| Email: np2 at doc.ic.ac.uk | Imperial College, |
| Tel: +44 (0)171 594 8394 | 180 Queen’s Gate, |
| Fax: +44 (0)171 581 8024 | London SW7 2BZ, |
| WWW: http://www-dse.doc.ic.ac.uk/~np2 | United Kingdom |
±-----------------------------------------±--------------------+

int do_something(void)
{
if ( error ) {
return(-1);
}
return(0);
}

int available(void)
{
return(1);
}

if ( available() == 0 ) {
do_something();
}

Doh!

If I had made the prototype for available() return a boolean value,
I would never have made that mistake.

There are essentially two classes of functions in SDL - those that
return 0 on success and -1 on error, and those that return true or
false. Currently they both return an int.

-Sam Lantinga				(slouken at devolution.com)

Lead Programmer, Loki Entertainment Software> On Thu, Feb 03, 2000 at 09:04:42AM -0800, Sam Lantinga wrote:

My immediate SDL TODO list:

  • Boolean type (desperately needed)

What’s wrong with ‘int’?


“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec

Ryan wrote:

They are just like ini files in windows… it so you can easily store
settings in your game…

i have already started writing on… it uses binary though so you can put
more than just ascii in the field… it’s not finished. i would say its
about 90% finished… i don’t have anymore time to work on it at the
moment… anyone want to finish it?

I don’t think that should be in the core SDL libraries. There
are loads of parser libraries that can be used to do that.
I use XML for all the data files of my game (highscore table,
sprite sheets, level files, user settings, etc.), so that I have
only have to link to a single parser library.

SDL has gotten complex enough that there are run-time options that the app
may want to turn on and off, driver parameters for example, that a general
purpose key/value hashtable would be very useful. Essentially everything
that SDL currently uses the environment variables for falls in this
category. The nice thing is that the code would be small, and the memory
penalty would be very low if it isn’t used, and it would be VERY helpful
to pretty much any game.

See ya!
-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:

SDL has gotten complex enough …

Maybe a name change to CDL? :-)–
Marc A. Lepage
Software Developer
Molecular Mining Corporation
http://www.molecularmining.com/

Sam Lantinga wrote:

I don’t think that should be in the core SDL libraries. There
are loads of parser libraries that can be used to do that.
I use XML for all the data files of my game (highscore table,
sprite sheets, level files, user settings, etc.), so that I have
only have to link to a single parser library.

SDL has gotten complex enough that there are run-time options that the app
may want to turn on and off, driver parameters for example, that a general
purpose key/value hashtable would be very useful. Essentially everything
that SDL currently uses the environment variables for falls in this
category. The nice thing is that the code would be small, and the memory
penalty would be very low if it isn’t used, and it would be VERY helpful
to pretty much any game.

Maybe that SDL shouldn’t provide persistence of those parameters, but
just an interface for the programs to change them. For example, an
SDL_GetParam()/SDL_SetParam() pair of functions. A companion application
could be made to read a file and translate it into a bunch of
SDL_SetParam()s and to write a file using a bunch of SDL_GetParam()s,
you see what I mean?

An application would be free then to integrate this configuration with
its own configuration files, get the information from command-line
parameters, environment variables or whatever. But it would be “heavily
recommended” to use the “SDL_config” library to handle command-line
parameters, environment and set defaults from an /etc/sdl.conf file for
example.

I know that what I would like to see at least. :-)–
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/

Maybe that SDL shouldn’t provide persistence of those parameters, but
just an interface for the programs to change them. For example, an
SDL_GetParam()/SDL_SetParam() pair of functions. A companion application
could be made to read a file and translate it into a bunch of
SDL_SetParam()s and to write a file using a bunch of SDL_GetParam()s,
you see what I mean?

An application would be free then to integrate this configuration with
its own configuration files, get the information from command-line
parameters, environment variables or whatever. But it would be “heavily
recommended” to use the “SDL_config” library to handle command-line
parameters, environment and set defaults from an /etc/sdl.conf file for
example.

Absolutely. That was the plan. :slight_smile:

Of course there would be an add-on library that would provide a
cross-platform way of doing that, much like SDL_image and so forth,
but I wouldn’t have to write that. :slight_smile:

BTW, for those thinking about writing such a beast, using the Windows
registry is probably a good idea, as well as something like /etc/sdl.conf
on Unices and possibly BeOS.

The rough API idea is:

/* Set name/value config pair */
int SDL_SetConfig(const char *name, const char *value);

/* Get name/value config pair */
const char *SDL_GetConfig(const char *name);

/* Interpret a value string as a boolean, int, float, etc. */
int SDL_GetConfigBool(const char *name);
int SDL_GetConfigInt(const char *name);
float SDL_GetConfigFloat(const char *name);

/* Set flags for a variable (read-only, etc.) */
SDL_SetConfigFlags(const char *name, Uint32 flags);

/* Set a callback that is run when a variable is set */
SDL_SetConfigCallback(const char *name, void (*callback)(const char *name, const char *value));

/* Get the first variable in the hashtable
   These pointers can be saved to an array and be sorted.
 */
const char *SDL_FirstConfig(void);
/* Get subsequent variables in the hashtable */
const char *SDL_NextConfig(void);

/* Clear all values from the config hashtable */
void SDL_ClearConfig(void);

See ya!
-Sam Lantinga (slouken at devolution.com)

Lead Programmer, Loki Entertainment Software–
“Any sufficiently advanced bug is indistinguishable from a feature”
– Rich Kulawiec