Has anyone already developed an SDL module
for reading file systems (reading directories,
file types, etc…)
If nobody has, I can do it for linux & windows.
Suggestions are welcome.
Thanks, bye, Enzo.
Doesn’t every platform support fopen()?On Mon, 28 Feb 2000, you wrote:
Has anyone already developed an SDL module
for reading file systems (reading directories,
file types, etc…)If nobody has, I can do it for linux & windows.
Suggestions are welcome.
Thanks, bye, Enzo.
–
-Garrett, WPI student majoring in Computer Science
"The fastest way to succeed is to look as if you’re playing by somebody
else’s rules, while quietly playing by your own." -Michael Konda
I think he’s concerned with having a standard method of accessing files,
this was discussed before with the generic config file stuff.
So you don’t have to worry about:
/home/username/gamename/settings.cfg --> Unix
c:\gamename\settings.cfg --> Windoze
gamename:settings.cfg --> Mac??? (never used mac)
[etc]
I currently do this in a config file:
GAME_LIB_DIR=c:\gamename
GAME_LIB_DIR=/home/username/gamename
But you still have the chicken/egg problem. You’ve gotta find the config
file to use it’s settings. It could be stored in the running directory of
the game, of course.
And there are still places in the game where I have to do a check for
platform to switch the directory seperator. Though this is because I
haven’t moved all directories to the config file.–
Brian
On Mon, 28 Feb 2000, Garrett wrote:
Doesn’t every platform support fopen()?
On Mon, 28 Feb 2000, you wrote:
Has anyone already developed an SDL module
for reading file systems (reading directories,
file types, etc…)If nobody has, I can do it for linux & windows.
Suggestions are welcome.
Thanks, bye, Enzo.
–
-Garrett, WPI student majoring in Computer Science
"The fastest way to succeed is to look as if you’re playing by somebody
else’s rules, while quietly playing by your own." -Michael Konda
Garrett wrote:
Doesn’t every platform support fopen()?
Has anyone already developed an SDL module
for reading file systems (reading directories,
file types, etc…)If nobody has, I can do it for linux & windows.
Suggestions are welcome.
Thanks, bye, Enzo.
–
yes, but with fopen() you cannot read directory lists:
under linux (#ifdef linux) I used this functions:
opendir
readdir
closedir
and under win32/mingw32 (#ifdef WIN32) I used:
_findfirst
_findnext
_findclose
Please correct me if I’m wrong.
Enzo.> On Mon, 28 Feb 2000, you wrote:
He’s probably thinking about cross-platform filename systems. I don’t
know of any that really work well that are hard enough to
implement. Ie, just pick ‘/’ as your divider and amend this to
whatever is correct on the system of your choice… of course, then
there are archaic issues like drive letters 
m.On Mon, Feb 28, 2000 at 10:43:03AM -0500, Garrett wrote:
Doesn’t every platform support fopen()?
–
Programmer "I wrote a song about dental floss,
Loki Entertainment Software but did anyone’s teeth get cleaner?"
http://lokigames.com/~briareos/ - Frank Zappa, re: the PMRC
Garrett wrote:
Doesn’t every platform support fopen()?
STANDARDS
The fopen and freopen functions conform to ANSI
C3.159-1989 (ANSI C''). The fdopen function conforms to IEEE Std1003.1-1988 (POSIX.1’’).–
Daniel Vogel My opinions may have changed,
666 @ http://grafzahl.de but not the fact that I am right
Doesn’t every platform support fopen()?
He’s probably thinking about cross-platform filename systems. I don’t
know of any that really work well that are hard enough to
implement. Ie, just pick ‘/’ as your divider and amend this to
whatever is correct on the system of your choice… of course, then
there are archaic issues like drive letters
We came up against this while working on Kosmos Online’s proof-of-concept
client. The code, originally designed for my Linux box, used /s as directory
dividers. When the Macintosh port came around, we had to fix it. A function was
quickly conjured up to reformat the directory structure.
All that you really need to do is to support the “current” directory structure
- most games won’t use it, and anything else that goes outside of it will most
likely as not be some sort of platform dependant mess. (by current directory
structure I mean “directory program executable is in, directory user is in when
he runs the program”). What this basically boils down to is swapping ":“s for
”/"s in the file system if you’re on a Macintosh, “” if you’re a Windowsian,
and I don’t know what you’d do for BeOS. It’d be simple enough.
m.
Nicho>On Mon, Feb 28, 2000 at 10:43:03AM -0500, Garrett wrote:
for my current project (a media library thingy) i have a seperate little
library that i use to get where the plugins and things are. i have it
setup to where i simply pass the function the name of the program (say
"bob") and it looks for it in places defined for that system, so for
linux it will look in /usr/local/bob and ~/.bob. currently i only have
this setup for linux and was wondering if there was a library out there
that could handle it for me. im not sure if this made much sense. but i
hope it was some help (and i would greatly apreciate a library that
could handle this stuff for me, if not ill probly end up making one
myself (wont be for awile though because i dont have time)
Enzo wrote:> Has anyone already developed an SDL module
for reading file systems (reading directories,
file types, etc…)If nobody has, I can do it for linux & windows.
Suggestions are welcome.
Thanks, bye, Enzo.
All that you really need to do is to support the “current” directory
structure
- most games won’t use it, and anything else that goes outside of it will
most
likely as not be some sort of platform dependant mess.
That’s OK in the single-user world of Windows and Mac, but UNIX philosophy
rightfully dictates that simply containing your actions within the
executable’s directory is not the best thing to do.
Aside from the executables/libs, there needs to be a separate place in the
filesystem for configuration information, since 1) configuration may vary
between different machines on a network, and 2) it must be possible to mount
the filesystem with executables/libs READ-ONLY, e.g. as in a diskless
terminal… And finally, each user must have his/her own configuration
files, which belong in home directories.
Obviously this whole setup is unnecessary for someone running games as root
on their local machine, but let’s not set our sights that low =).
Dan
Newsgroups: loki.open-source.sdl
All that you really need to do is to support the “current” directory
structure
- most games won’t use it, and anything else that goes outside of it will
most
likely as not be some sort of platform dependant mess.That’s OK in the single-user world of Windows and Mac, but UNIX philosophy
rightfully dictates that simply containing your actions within the
executable’s directory is not the best thing to do.Correct me if I’m wrong, but anything which would have to reach outside the
executable directory in a Linux system would probably be platform dependant,
ergo there’s no real problem with using a special case path surrounded by
platform control #ifdefs. You point out configuration files, but even with
that you could have one configuration file in the home directory of the
application for multiple flags as different users… hence you can allow
extra users on various machines with their own configuration files without
having to add extra crap in the filesystem for that one special case.Obviously this whole setup is unnecessary for someone running games as root
on their local machine, but let’s not set our sights that low =).I don’t think that would really amount to “that low”. The wide majority of
GLX implementations (Utah-GLX, the 3DFX GLX implementation unless you REALLY
want to mess around with /dev/3dfx which is completely fubared under
Slackware 7) require you to be running as superuser. One of the joys of this
is that it makes it VERY easy to bring your system down quickly while
working on unstable code. The program that I was working on before I passed
control to somebody else bought my system down thirty-seven times in a two
week period.Dan
Nicholas
Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert----- Original Message -----
From: dmaas@spamdcine.com (Dan Maas)
To: sdl at lokigames.com
Date: Monday, February 28, 2000 5:27 PM
Subject: [SDL] Re: Re: File system access
Enzo wrote:
Has anyone already developed an SDL module
for reading file systems (reading directories,
file types, etc…)If nobody has, I can do it for linux & windows.
Suggestions are welcome.
I’m currently working on a virtual filesystem (for my audio-player),
which should also support network access (http, etc.).
I didn’t plan to use it for SDL, but it wouldn’t ne a problem to
use it in SDL apps.
perhaps we could work together on it.
bye,
ew.>
Thanks, bye, Enzo.
–
crystal space has a very nice virtual file system
just grab it from there
crystal space has a very nice virtual file system
just grab it from there“I’m sorry Dave, I can’t allow you to do that.”
And you expect me to pass up the opportunity to crack a lame joke like
that?!Seriously, I think there’s enough … stuff … (I would say crap but any CS
developers would get offended, not that I mean it, it’s a nice engine) that
would cause meshing problems if you wanted to integrate it into SDL. Besides
which, you’d end up taking big chunks of Crystal Space code with it and it
ends up a nasty chunk of blergh. Something like a VFS is ridiculously
simple… I got my first one up and running in about three hours. (and that
was four years ago)Cheers,
Nicholas (fresh code or bust!)
Nicholas Vining “While you’re out there struggling
vining at pacificcoast.net with your computer, I’m naked,
icq: 20872003 clueless, and feeling good!”
- Ratbert----- Original Message -----
From: dpm@efn.org (Dave McClurg)
To: sdl at lokigames.com
Date: Saturday, March 25, 2000 11:45 PM
Subject: RE: [SDL] File system access