Feedback?

Hrm…sounds like the definition is overriding the prototype.

No, what it is is that the SDL_WriteLE32 (And the Write32 it’s based
on) from the 0.7 release returned void, but the ones from CVS was
changed to return int. I need to install the latest CVS code and then
it’ll work right.

Oooh. Someone who actually got GNOME experience. That abad, eh?

yes. Both GNOME and KDE RPMs I’ve found are only made to
work on RedHat 5.1 and GCC 2.8. They require libstdc++ 2.8, which you
have to install but that conflicts with libstdc++ from GCC 2.7.3. It
looks like I have to upgrade since most RPMs coming out lately require
GCC 2.8 and compiling from tarballs can be even MORE of a headache.

GIF has been kinda killed in some circles because of prorietary issues
and legalities. Its unfortunate that most PC programmers use bitmaps
because they are inefficient and klunky…but amongst them it is
standard. JPEGS require a bit of overhead…it depends on your
app. There is also the PNG file format which people are trying to
use as a replacement, but I’ve seen no real practical instances
thus far on them that prove better professor.

Unfortunately that and the fact that GIF only supports 256 colors.
JPEG only have the load-time, and the game I’m working on loads
everything at startup, so gameplay wouldn’t be affected. I’ve heard
and seen a little about PNG, but I haven’t played around with it enough
to be able to comment. I’ve got some PNG files, but the only program
I’ve got that can read 'em is xv.

Good idea.

I thought so. That’s why I mentioned it.

I wish I could be of more help, but I’ve been insanely busy…if I
have a few hours this weekend I might try to krank out a demo
for inclusion.

Well, unfortunately, I’ve not been able to contribute any code yet,
just suggestions. Sam’s doing all the real work that I’ve seen thus
far.On 30 Jul, David Sowsy wrote:


| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

That’s just the timing of the game itself. You can adjust that by using
the #define’s in aliens.c

Well, if it were more than just a demo, I might. It even runs fast on
my (slow as molasses) P120 laptop.

That’s correct. You can use the CVS code. I usually don’t put out CVS
snapshots on my webpage until something that I’ve been working on is stable
and tested on at least one of the supported platforms (Usually Linux)
So, if you check back to develop.html and either grab the new archive
or perform a CVS update whenever that snapshot date changes, you should
be alright. If anything major changes, I’ll announce it on the list.

Okay. I’ll update my headerfiles and shared libraries then. I asked
because I grabbed the source directly from CVS and like I said, I’ve
heard horror stories about CVS code. But as long as it works on Linux,
that’s all I’m worried about now. Once I get the game done, I’ll be
working on porting it to Windows for all my unenlightened friends. :slight_smile:

No worries, SDL isn’t nearly as octopussian a project. :slight_smile:

I have one ting to say to that: Thank God!

(Is that a word? :slight_smile:

It is now. :slight_smile:

Yep. Just as long as you follow the copyrights associated with the
files, you can use any of the example code in your own projects.
The code I write is under GPL, and the code from other people that
I’ve included has either been freeware or GPL as well.

Well right now, I’m mostly working on this game to get experience with
game programming. Like I said, this is my first forray into game
programming. I’m planning on releasing it under the GPL so copyrights
on other software shouldn’t be too hairy.

It looks like PenguinPlay, a Linux game library project, may start
using SDL as one of the low-level targets it suppors. They are doing
quite a bit of work on file loading and wad-type archive support.
As far as I can tell from the mailing list, the project is big and
slowly developing.

Yeah, PenguinPlay has a lot of potential, but I’ve not seen anything
out of them that’s really usable yet. And I check back every few weeks
or months to see if anything new shows up. Same thing with GGI. Last I
checked none of my video cards (Cirrus Logic 5430, 7548, Trident TGUI
9680, and ATI Mach64) are fully supported yet. I could be wrong on
both accounts, but that’s from my experience.

Right now, for the wad-type archive support, what I’m doing is just
using a .tar.gz file, and having my program spawn “tar zxf
datafile.tar.gz” and then read from the info it produces (Something I
learned from Enlightenment).

I have no problem including a general archive loader and general
image/sound/music loading library with the SDL demo code, in fact,
I think it’s a really good idea. I have too many other things
going on to write it however, so it would be up to you folks. :slight_smile:

I know how it is. I’ve got like four projects I’m juggling
concurrently and about six more once these ones get done.

Thank you very much. You guys have really made this worthwhile for
me… it’s been a nice big pleasure working on the SDL project with
you all. :slight_smile:

Just wait till SDL REALLY takes off… You can kiss your inbox
goodbye. :)On 30 Jul, Sam Lantinga wrote:


| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

But seriously, we might consider an SDL-specific graphics format, so that
all SDL apps are standardized, and you can convert ANY graphics type to an
SDL pixel map. (That’s annoying, because you can’t load these files in
your favorite graphics program, without using file-converters.) But
that’s the technique I’m using for the program I’m developing now, and it
works fairly well. Just develop all your graphics using the
aforementioned favorite editor, save BMPs, and convert them to the
custom format for the program. (And they’re nice & compact and shoved
into a convenient resource file…)

I don’t know. I’m not sure if I’d want to create a new file type that
only SDL could read natively. I’ve never been a fan of creating any
weird filetype with only one specific use. It probably does work well,
I’m just a little concerned. Now if you could develop a GIMP plugin to
save/load this type of image, it might not be so bad, as GIMP is the
program I’m using to make my graphics.

The nice thing about having a custom graphics format is you can guarantee
it has all the features you want. Color modes supported? 16-bit RGB565,
32-bit RGBA8888, palettized 8-bit, palettized 4-bit. 1-bit. You could do
anything.

Well, nothing I’m working on requires these features. But if you want
to write demo code that uses this format, send it to Sam and we’ll see
how well it works.

I have a Huffman/RLE-style compression I’ve developed and would be willing
to donate to such a cause. It works pretty well, and has a FAST
decompression time. But then again figuring out how to use gzip
would work much better, anyway. (Is there a gzip in library form we could
use? Store some sort of gzipped data on disk, and uncompress to RAM on
load?)

Well, there’s always zlib. I believe that’s gzip-compatable. And from
what I’ve seen, it’s fairly standard accross distributions.On 30 Jul, Chuck Homic wrote:


| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

Absolutely not. I’m going to be very conservative about what I include
in the SDL core library – i.e. no more file formats, etc, but I am
very happy to add to the growing collection of demo libraries and programs.
I am willing to give CVS write access to anyone actively working on a
demo or library. All I ask is that it’s coded with extensibility
and ease of use in mind. Discussing it here on the list is a good way
to get feedback. (Also, for the lazy minded out there like me, do a
good web search to see if what you are trying to do has already been
done and released for free.)

I agree. I don’t think everything needs to be integrated into the
heart of SDL. That’s entirely too … Microsoftean (Is that a word?)
for me. But if we were to do something like make an libSDLsuplement.a
or something with all these extra routines, it would work just as well.

I don’t see a need for integration – just use them both in your game. :slight_smile:

Agreed. I know enough about low-level BSD-style sockets (which Linux
uses) to be able to implement a network interface. The only problems I
see is porting that to Windows and re-writing everything into Winsock
(I’ve never used it and know nothing about it).On 30 Jul, Sam Lantinga wrote:


| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

Because SDL is supposed to be platform-neutral. Imlib is (as far as I
know) UNIX only. Besides, Imlib is a moving target (Raster keeps
breaking it adding new features). There’s no way we’d be able to get
commercial software developers onboard if they had to keep changing
their code.On 31 Jul, Nathan Hurst wrote:

I’m surprised that Sam hasn’t just used imlib - that would be the elegant
way to do things?


| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

Agreed. I know enough about low-level BSD-style sockets (which Linux
uses) to be able to implement a network interface. The only problems I
see is porting that to Windows and re-writing everything into Winsock
(I’ve never used it and know nothing about it).

Berkeley sockets is portable to Winsock and BeOS with very few changes
(mostly you need to start up winsock on Windows.)

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

That’s a relief. Is there any sample code (Nothing fancy) that I could
have a look at?On 30 Jul, Sam Lantinga wrote:

Berkeley sockets is portable to Winsock and BeOS with very few changes
(mostly you need to start up winsock on Windows.)


| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

I’d like some feedback on the splitting of the demos from the source archive.
Is it a good layout? Nice demos? Is it clear how to make them?

GIF loading is something I’ve been hoping for. BMP files are HUGE, and
I’d rather have an industry standard filetype like GIF or JPEG (For
high-color graphics).

Well, GIF loading has it’s problems - It uses a patented compression algorithm.

This only affects those of you unlucky enough to be in the US. (Oh, and the FSF
make a big deal about it on their web site)

JPEG files may be small, but they aren’t exactly CPU friendly…

Also, is there any way to (or any plans to) load SDL
graphics/sounds/music/etc. from one single file (similar to wad files
for DOOM).

Why is this necessary? I don’t really think that FS code belongs in SDL.
(Although, it isn’t really my decision)On Thu, Jul 30, 1998 at 09:00:34AM -0600, kwalker at aros.net wrote:

On 30 Jul, Sam Lantinga wrote:


– Michael Samuel

Don’t trust anything I say, just give it consideration.

I have a Huffman/RLE-style compression I’ve developed and would be willing
to donate to such a cause. It works pretty well, and has a FAST
decompression time. But then again figuring out how to use gzip
would work much better, anyway. (Is there a gzip in library form we could
use? Store some sort of gzipped data on disk, and uncompress to RAM on
load?)

I may be wrong, but zlib might be what you are looking for.On Thu, Jul 30, 1998 at 03:46:28PM +0000, Chuck Homic wrote:


– Michael Samuel

Don’t trust anything I say, just give it consideration.

Well, GIF loading has it’s problems - It uses a patented compression algorithm.

I agree, but as Sam pointed out, only GIF compressors require roylty.
For decompression, it isn’t so restrictive, and we already have code to
load GIF files.

This only affects those of you unlucky enough to be in the US. (Oh, and the FSF
make a big deal about it on their web site)

Not quite. International treaties and such, you know…

JPEG files may be small, but they aren’t exactly CPU friendly…

This is true, but if the programmer uses JPEG loading intelligently,
its CPU overhead can be kept to a minimum.

Why is this necessary? I don’t really think that FS code belongs in SDL.
(Although, it isn’t really my decision)

Because a lot of the games have a lot of sprites or other things that
(If kept as separate files each) could consume ENORMOUS ammounts of
disk space and have thousands of files. I’m not sure if it belongs in
the libSDLx11.so file itself, but I would like some kind of
(psudo)standard method for loading game data from a single file.On 31 Jul, Michael Samuel wrote:


| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

Berkeley sockets is portable to Winsock and BeOS with very few changes
(mostly you need to start up winsock on Windows.)

That’s a relief. Is there any sample code (Nothing fancy) that I could
have a look at?

Not at the moment… I’ll probably have some in a couple of weeks.

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

Because a lot of the games have a lot of sprites or other things that
(If kept as separate files each) could consume ENORMOUS ammounts of
disk space and have thousands of files. I’m not sure if it belongs in
the libSDLx11.so file itself, but I would like some kind of
(psudo)standard method for loading game data from a single file.

Why not have a library that understands ZIP files? This is very common
in software like Netscape and so on.

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

Thanks Sam.On 31 Jul, Sam Lantinga wrote:

Not at the moment… I’ll probably have some in a couple of weeks.


| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

That would be very useful since it handles file compression as well as
multiple files in one archive. (But then again, I’ve liked ZIP since
v1.0). Any idea where I could find such a library?On 31 Jul, Sam Lantinga wrote:

Why not have a library that understands ZIP files? This is very common
in software like Netscape and so on.


| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

Why not have a library that understands ZIP files? This is very common
in software like Netscape and so on.

Gzip and PkZIP use the same compression algorithm. The differences are only
minimal. (eg. a Pkzip archive includes a tar-like archive in the compression,
while gzip is more of a compression stream kinda thing)On Fri, Jul 31, 1998 at 12:36:04AM -0700, Sam Lantinga wrote:


– Michael Samuel

Don’t trust anything I say, just give it consideration.

Now force feedback… That SUCKS.

Actually, all force feedback systems I’ve seen PULL… :slight_smile:

njh

With all the suggestions flying around lately (And some of the ones
I’ve made) I would really like to know what exactly SDL is supposed to
do. What exactly it is supposed to encompass and what should be left
out.

-KW–


| |/ | | | _ | | | mailto:@Knight_Walker |
| / | / / | | http://www.aros.net/~kwalker |
| \ | ___ | | |
| |\ | | / \ | | The Kobran Imperium (801)265-1299 |
|| || || || _____________________________________/

With all the suggestions flying around lately (And some of the ones
I’ve made) I would really like to know what exactly SDL is supposed to
do. What exactly it is supposed to encompass and what should be left
out.

Not a problem:

The Simple DirectMedia Layer is a low level interface abstraction layer
for multimedia programs. As such, it provides the basic portable API
required for building full-screen multimedia applications.

The services it provides include:

Video surface access (2D)
Audio stream access
General event queue

In addition, to allow interesting, portable applications:

API for creation of threads
Basic semaphore mechanism
Simple timer services
Windows DIB bitmap file loading
Microsoft WAVE file loading
Endian-independent value manipulation

These last items aren’t really the focus of SDL, but either arose out
of a need to make the basic library immediately useful, or as a natural
consequence of the cross-platform implementation.

That’s it: Simple – DirectMedia – Layer – KISS

Now, to make this interesting to the average developer, it really helps
to have examples and cool demos to show off what SDL can do, and give the
developer some documentation and useful libraries. That’s the purpose of
the SDL-demos archive.

Medium-core game developers and porters of existing applications will just
want the raw interface with no cruft. That’s the basic SDL library.
Others, especially freeware developers, will appreciate useful file loaders,
prewritten mixers, effect libraries, etc.

I’m interested in providing the basic layer, and allowing others to create
nice libraries and applications that sit on top of SDL.

That’s the Simple DirectMedia Layer in a nutshell. :slight_smile:

For the record, the reason I’ve done so many of the examples is because
it’s exciting to take the library and make something visually and aurally
appealing.

See ya! :slight_smile:
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/

Sam Lantinga writes:

Medium-core game developers and porters of existing applications will just
want the raw interface with no cruft. That’s the basic SDL library.
Others, especially freeware developers, will appreciate useful file loaders,
prewritten mixers, effect libraries, etc.

I’m interested in providing the basic layer, and allowing others to create
nice libraries and applications that sit on top of SDL.

That’s the Simple DirectMedia Layer in a nutshell. :slight_smile:

im curious why you say medium-core game developers? :> just ask
because i prefer raw interface myself, (although I must admit we do
have in house libraries we have developed). I have been a
professional game developer for a quite visible game company for about
3 years now, so i consider myself quite hard-core, and for home
projects (and even work) i still prefer raw interface with no crud :slight_smile:

just a point

j

im curious why you say medium-core game developers? :> just ask
because i prefer raw interface myself, (although I must admit we do
have in house libraries we have developed). I have been a
professional game developer for a quite visible game company for about
3 years now, so i consider myself quite hard-core, and for home
projects (and even work) i still prefer raw interface with no crud :slight_smile:

Sorry, I was differentiating between Medium-core game programmers who
use things like libraries, and Hard-core game programmers who love to
write hardware registers and self-modifying code. :slight_smile:
Of course the distinction is a fuzzy one. :slight_smile:

I’ve worked hard to make SDL proper as crudfree as possible.
In your opinion, have I succeeded?
(We can take this off the mailing list if you like)

See ya!
-Sam Lantinga (slouken at devolution.com)–
Author of Simple DirectMedia Layer -
http://www.devolution.com/~slouken/SDL/