New Project: SDLArchive

Hello everyone! I’d just like to announce that I’ve begun a new project
for SDL called SDLArchive. Its purpose is to provide an interface to
manipulate packfiles that have SDL-type structs in them. I haven’t done
that much coding on it yet, but I do have a few features right now:

  • The only thing the packfiles can store currently is a raw image. It uses
    SDL_image to convert any type of image it supports to the raw format. I
    also tend to do something like this with the sound, palettes, and true-type
    fonts. Also I will include a couple of fundamental things, like a binary
    type which you can use for your own purposes, and a text type (with a text
    type, you could even make language packfiles).
  • A console tool that can show (this needs cleaning up), create, and making
    a header file for a packfile. The header file is useful because you do not
    have to remember which number it was in the list when coding. It just
    #defines them. Another idea would be to use an enum, which would be useful
    for C++ and namespaces.

Features to come (hopefully):

  • Deleting items, adding items, and whatever else.
  • A C++ wrapper interface.
  • An SDL graphical program to make things easier on the programmer.
  • A dynamic plugin-style interface, where users can add their own types for
    the packfiles.
  • Suggestions are welcome.
  • GZipping/GUnzipping support.

A lot of my ideas come from the Allegro dat/grabber utilities. ClanLib has
a resource manager too. It seems that SDL is the only one missing this
sort of addon package. However, it isn’t very far along, and I haven’t
even released the 0.1 yet. Right now the only interested people would be
ones willing to submit patches and ideas. With the gz support, you can
compress all the cluttered images your game uses into one convenient file
that you load at startup. This simplifies in programming, and you only
have to worry about locating the packfile instead of a million different
pcx’s. :slight_smile: If you like the idea and are willing to help, please contact me
or simply submit a patch. I’ve started a Sourceforge page:

https://sourceforge.net/projects/sdlarchive/

The CVS is working, and I’ve started a mailing list. I am also looking for
other admins, because in a few months I might be extremely busy and I’d
like the project to go on without me. :slight_smile: That’s a bit ahead of the
project now. I’ll be happy if I can get v0.1 out the door. Any
encouragement e-mail is welcome too. Thanks for your time, and I
anticipate your feedback of the project general!–
Benjamin Joel Stover
~StoverTech~

Hi

I have been thinking of a way of doing exactly the same thing, but I’m stuck
on how to use SDL_Image to read a image from memory, instead of a file.

From a quick look, it seems that a fundamental change to the SDL source code
is required.

At the moment I am using the excellant WINRar library -
http://www.mountpoint.ch/unique/project/urarfilelib/index.html

It takes a file out of the arhive and decompresses it to memory. At the
moment, I am storing sounds and level data in there (FMOD can load a sound
sample from memory as well as disk).

Can you give me any clue as to how you intend to use SDL_Image to load a
file from an archive?

If anything I have done so far would be useful, please let me know.

Thanks
David> ----- Original Message -----

From: Benjamin Joel Stover [mailto:stovertech@intellisys.net]
Sent: Monday, July 09, 2001 4:20 AM
To: sdl at lokigames.com
Subject: [SDL] New Project: SDLArchive

Hello everyone! I’d just like to announce that I’ve begun a new project
for SDL called SDLArchive. Its purpose is to provide an interface to
manipulate packfiles that have SDL-type structs in them. I haven’t done
that much coding on it yet, but I do have a few features right now:

  • The only thing the packfiles can store currently is a raw image. It uses
    SDL_image to convert any type of image it supports to the raw format. I
    also tend to do something like this with the sound, palettes, and true-type
    fonts. Also I will include a couple of fundamental things, like a binary
    type which you can use for your own purposes, and a text type (with a text
    type, you could even make language packfiles).
  • A console tool that can show (this needs cleaning up), create, and making
    a header file for a packfile. The header file is useful because you do not
    have to remember which number it was in the list when coding. It just
    #defines them. Another idea would be to use an enum, which would be useful
    for C++ and namespaces.

Features to come (hopefully):

  • Deleting items, adding items, and whatever else.
  • A C++ wrapper interface.
  • An SDL graphical program to make things easier on the programmer.
  • A dynamic plugin-style interface, where users can add their own types for
    the packfiles.
  • Suggestions are welcome.
  • GZipping/GUnzipping support.

A lot of my ideas come from the Allegro dat/grabber utilities. ClanLib has
a resource manager too. It seems that SDL is the only one missing this
sort of addon package. However, it isn’t very far along, and I haven’t
even released the 0.1 yet. Right now the only interested people would be
ones willing to submit patches and ideas. With the gz support, you can
compress all the cluttered images your game uses into one convenient file
that you load at startup. This simplifies in programming, and you only
have to worry about locating the packfile instead of a million different
pcx’s. :slight_smile: If you like the idea and are willing to help, please contact me
or simply submit a patch. I’ve started a Sourceforge page:

https://sourceforge.net/projects/sdlarchive/

The CVS is working, and I’ve started a mailing list. I am also looking for
other admins, because in a few months I might be extremely busy and I’d
like the project to go on without me. :slight_smile: That’s a bit ahead of the
project now. I’ll be happy if I can get v0.1 out the door. Any
encouragement e-mail is welcome too. Thanks for your time, and I
anticipate your feedback of the project general!


Benjamin Joel Stover
~StoverTech~

I have been thinking of a way of doing exactly the same thing, but I’m stuck
on how to use SDL_Image to read a image from memory, instead of a file.
From a quick look, it seems that a fundamental change to the SDL source code
is required.

SDL_RWops *rw = SDL_RWFromMem(ptr_to_image_data, size_of_mem_block_in_bytes);
SDL_Surface *img = IMG_Load_RW(rw, 1);
free(ptr_to_image_data);

–ryan.

Aarrggghh !!!

No way !!! :slight_smile:

Plugged that code into the spot reserved for it in the resource loading
routine, and Bang - all the graphics files loaded from the archive instead
of the file system !!!

Thanks a million - your a champion !!

Cheers
David.> ----- Original Message -----

From: Ryan C. Gordon [mailto:icculus@linuxgames.com]
Sent: Monday, July 09, 2001 2:27 PM
To: 'sdl at lokigames.com
Subject: RE: [SDL] New Project: SDLArchive

I have been thinking of a way of doing exactly the same thing, but I’m
stuck
on how to use SDL_Image to read a image from memory, instead of a file.
From a quick look, it seems that a fundamental change to the SDL source
code
is required.

SDL_RWops *rw = SDL_RWFromMem(ptr_to_image_data,
size_of_mem_block_in_bytes);
SDL_Surface *img = IMG_Load_RW(rw, 1);
free(ptr_to_image_data);

–ryan.

Benjamin Joel Stover wrote:
With the gz support, you can

compress all the cluttered images your game uses into one convenient file
that you load at startup. This simplifies in programming, and you only
have to worry about locating the packfile instead of a million different
pcx’s. :slight_smile:
Is there much a difference with transparent zip-support? Instead of
unfolding a tree with images/sound/otherstaticdata one can directly access
these data in a zip-file - the data-management would just use standard zip
tools and filepaths for the programm-interface. The zziplib API has been
used successfully in quite some games including those based one SDL. In
any case, the LGPL’ sources of zziplib may give you some hints for your
own project sources:
http://zziplib.sf.net
cheers,
– guido GCS/E/S/P C++$++++ ULHS L++w- N++@ d(±) s+a- y++ 5++X-

SDL_RWops *rw = SDL_RWFromMem(ptr_to_image_data,
size_of_mem_block_in_bytes);
SDL_Surface *img = IMG_Load_RW(rw, 1);
free(ptr_to_image_data);

–ryan.

Well I suppose I can delete the project now. There goes my effort into
the project. Oh well, at least I now understand CVS better… Next
time I’m gonna ask if there’s a way to do it. sigh

~ST~

Not at all !!

Take a look as this page -
http://www.mountpoint.ch/unique/project/urarfilelib/index.html

It’s a cross-platform archiving library (rar format) with source code.

I’d sure love to see some SDL functions like:

SDL_Surface = SDL_Archive_SDL_Image (char *fileName, char *dataFile);
SDL_Sound = SDL_Archive_SDL_LoadSound (char *fileName, char *dataFile);
SDL_Archive_SaveFile (char *fileName, char *dataFile, int memoryLocation,
int sizeOfFile);

It could just be a simple wrapper around a Rar or Zip archive.

David.> ----- Original Message -----

From: Benjamin Joel Stover [mailto:stovertech@intellisys.net]
Sent: Monday, July 09, 2001 12:45 PM
To: sdl at lokigames.com
Subject: RE: [SDL] New Project: SDLArchive

SDL_RWops *rw = SDL_RWFromMem(ptr_to_image_data,
size_of_mem_block_in_bytes);
SDL_Surface *img = IMG_Load_RW(rw, 1);
free(ptr_to_image_data);

–ryan.

Well I suppose I can delete the project now. There goes my effort into
the project. Oh well, at least I now understand CVS better… Next
time I’m gonna ask if there’s a way to do it. sigh

~ST~

Well I suppose I can delete the project now. There goes my effort into
the project. Oh well, at least I now understand CVS better… Next
time I’m gonna ask if there’s a way to do it. sigh

Personally, I think something as nice as Allegro’s data files (and their
data file management application) would be a very valuable addition to the
SDL suite of libraries. I hope you were joking about deleting the project.
All I showed was how to get SDL_image to load from memory. What’s needed
is a) a nice way to manage your game resources and b) a way to get them
into memory in the first place. :slight_smile:

–ryan.

Personally, I think something as nice as Allegro’s data files (and their
data file management application) would be a very valuable addition to the
SDL suite of libraries.

just to remind people: If you start write a library without actually
having a direct need in a concrete project, it will most likely end up
being useless for you and anyone else. There are tons of more-or-less
abandoned “library” projects for exactly this reason — neither the
design nor the implementation of a library will be right unless the
people are using it themselves

never trust a library written for “the public good” by people who are not
actively using it (and for the record, yes, I use SDL myself and I’ve
heard Sam does as well :slight_smile:

I would just like to put in my $0.02…

urarfilelib does look like a nice lib, but it’s License requires that you
distribute your final programs for free. That isn’t a problem for those who are
writing open source projects (such as myself), but it is a big problem for those
who aren’t.

zlib may be more difficult to use, but it works, it has a friendly license, and all
the available zip/winzip tools work just as well (if not better) than the rar
tools, though the compression may not be quite so good.

In my opinion, it would be worth the extra effort to do this using zlib. I have
been contemplating such a project myself and have considered the various options,
but I always end up coming back to zlib, I just haven’t had the time to do it
myself yet since my application has other more pertinent needs.

Bryan

ps. Here is the urarlib license for those who are curious:

License for UniquE RAR File Library
Copyright © 2000-2001 by Christian Scheurer (www.ChristianScheurer.ch)
UNIX port by Johannes Winkelmann (jw at tks6.net)

You have the permission to use, copy, modify, and distribute the
UniquE RAR File Library (URARFileLib) and its documentation for
any purpose except for re-creating the RAR compression algorithm,
which is proprietary. URARFileLib may not be used to develop a
RAR (WinRAR) compatible archiver.
If you use URARFileLib, or parts of URARFileLib in your program,
you must give the program away for free.
The above copyright notice must bs shipped with all copies.
No representations are made about the suitability of the URARFileLib
for any purpose. It is provided “as is” without expressed or implied warranty.

Christian Scheurer (unique at vantage.ch)
06. December 2000>Berry, David wrote:

Not at all !!

Take a look as this page -
http://www.mountpoint.ch/unique/project/urarfilelib/index.html

It’s a cross-platform archiving library (rar format) with source code.

I’d sure love to see some SDL functions like:

SDL_Surface = SDL_Archive_SDL_Image (char *fileName, char *dataFile);
SDL_Sound = SDL_Archive_SDL_LoadSound (char *fileName, char *dataFile);
SDL_Archive_SaveFile (char *fileName, char *dataFile, int memoryLocation,
int sizeOfFile);

It could just be a simple wrapper around a Rar or Zip archive.

David.

Personally, I think something as nice as Allegro’s data files (and their
data file management application) would be a very valuable addition to the
SDL suite of libraries.

Hmm… I figured I’d just use a combination of that RAR link posted:

http://www.mountpoint.ch/unique/project/urarfilelib/index.html

And then just use his technique. However, there was one more useful aspect
of what I had done: you could create headers that #defined the name of each
file in the packfile and then the number in it. You could easily access it
that way (list.data[BLAH_GIF]). I have some ideas to emulate that for the
RAR archive though. You’d simply put a resource file with all the names of
the files you want in like the resource directory in the archive. Your
program would just read through the names in the file and load them as it
went into a list. And you could just make a small utility to take these
resource files and output it in header form (take off the directory and
extension stuff of course).

Or instead of all that you could do something similar to an Allegro datafile.
You just go through each and every file in the RAR and add it to a list of
images (if that is what the file is).

just to remind people: If you start write a library without actually
having a direct need in a concrete project, it will most likely end up
being useless for you and anyone else. There are tons of more-or-less
abandoned “library” projects for exactly this reason — neither the
design nor the implementation of a library will be right unless the
people are using it themselves

never trust a library written for “the public good” by people who are not
actively using it (and for the record, yes, I use SDL myself and I’ve
heard Sam does as well :slight_smile:

I did have a good purpose for it. I was converting a game I was working on
in Allegro over to SDL, and then I didn’t know what to do about some form of
a DATAFILE, so I figured I’d take a leap and make my first SourceForge
project. Perhaps a useful package to the community would be one to convert
DATAFILEs into a RAR archive and then in the README give a tutorial on how to
use them (and include that ~46k of RAR archive library code in the package
:)).

But I doubt I’ll be doing any of that soon, because now I have all the tools
I need. With that snipplet of code, and the RAR archives, I’m ready to do
it. Does the SDL_ttf library have any similar way to load files from memory?–
~StoverTech~
Benjamin Joel Stover

Personally, I think something as nice as Allegro’s data files (and their
data file management application) would be a very valuable addition to the
SDL suite of libraries.

Another remind is that I recently looked into Mingw sources (trying
to figure out how to make bash happy about /tmp when I couldn’t use
C:\ as / – failed) and the runtime library contains the standard
opendir, readdir, closedir etc. functions, thus they might make sense
for crossplatform directory scanning base code, if someone is working
on such thing…

(No, bash (or whatever the mingw sh is) didn’t react to TMP, TEMP nor
TEMPDIR environment variables… )

– Timo Suoranta – @Timo_K_Suoranta

just to remind people: If you start write a library without actually
having a direct need in a concrete project, it will most likely end up
being useless for you and anyone else. There are tons of more-or-less
abandoned “library” projects for exactly this reason — neither the
design nor the implementation of a library will be right unless the
people are using it themselves

I won’t name names, but I can think of at least one major corporation that
is still using Allegro instead of SDL SPECIFICALLY because one’s got
very nice packfile support, and the other doesn’t.

(shrug)

–ryan.

In my opinion, it would be worth the extra effort to do this using zlib. I
have been contemplating such a project myself and have considered the
various options, but I always end up coming back to zlib, I just haven’t
had the time to do it myself yet since my application has other more
pertinent needs.

Hmm, maybe what I’ve written can still go on! I had a lot updated that
wasn’t on CVS, and I might continue to work on it. I was just giving
functionality for things like adding and deleting. Here’s how I was doing it:

It was very close to Allegro’s way. I have a struct with a pointer to
Archive items and then an integer for how many it has. It uses a
driver-style interface. The drivers are the things that allow support for
things such as images and sounds and such (currently only the image is
written). For instance, the load function gets the name and type, and then
calls the driver based on that. The only driver currently is the raw image.
When saving, it just takes the stuff in SDL_Surface and saves it in its own,
raw format. When loading it, it just takes the parameters, creates the
surface, and then gets the pixels. So, while you might have imported a GIF,
it is considered a raw image type. JPEG, whatever.

The advantage to my way is:

  • We can have whatever license we want. Currently it is GPL, but we could
    make it LGPL.
  • You can have all different sorts of types in one file. Images, sounds,
    whatever. You just have to look at the type to know.
  • The console tool already allows you to output a header file, so you don’t
    have to know what is what (like I said in the other post). Just something
    like list.data[GFX1].item and cast it to an SDL_Surface.
  • People can contribute and make it better and better, until we have
    something just as simple as Allegro’s grabber. We can make C++ API, have a
    graphical tool, and even make a GTK+ one.
  • It is very simple. You’d just install the package and you’re ready to use
    it.

I could even add or change the raw image driver to use RWops. However, with
the raw image, an image is an image, no matter where it came from. With the
RWops, you could take advantage of JPEG compression or anything else.

But here’s the deal: I’m only willing to go further if people actually want
this. The RAR method or something similar might work fine for me, or I just
might use what I’ve already made (now that I think about it). If there is
still good enough purpose to continue, I will. And anyone willing to submit
patches and the like would be a definite plus. If you don’t want to clutter
up the SDL list, just send me (@Benjamin_Joel_Stover) an e-mail showing
interest. It’s a good feeling to know that this project might still be
useful enough.–
~StoverTech~
Benjamin Joel Stover

Bryan Murphy wrote:

urarfilelib does look like a nice lib, but it’s License requires that you
distribute your final programs for free. That isn’t a problem for those who > are writing open source projects (such as myself), but it is a big problem
for those who aren’t.

This is so off topic, I feel guilty writting it already … But this
does in fact stop a lot of open source projects (depending on license
used). They mean “free” as in money, and the (L)GPL explicitly ALLOWS
distribution for money AS WELL AS distribution for “free”. A licensing
conflict …

-- David Snopek

/-- libksd –
| The C++ Cross-Platform Game Framework
| Only want to write it once??
| http://libksd.sourceforge.net
------------

Benjamin Joel Stover wrote:

Hello everyone! I’d just like to announce that I’ve begun a new project
for SDL called SDLArchive. Its purpose is to provide an interface to
manipulate packfiles that have SDL-type structs in them. I haven’t done
that much coding on it yet, but I do have a few features right now:

those stuff belongs into an virtual filesystem.

i’m working on an platform independent stream/VFS API for a while:

http://sourceforge.net/projects/deimos.

archives are currently not supported yet, but quite easy to implement.

~-n–


Enrico Weigelt
meTUX IT Services

www: www.metux.de
email: @Enrico_Weigelt
phone: +49 36207 51833
cellphone: +49 174 7066481