SDL 2.0 : File and internationalisation

SDL Development
1

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I’ve taken a look at SDL 2.0 draft API, and it seems promising to me.
We are developing a free software RTS game, and we have gone through most of
theses problems.

So, I’ve some proposal for modules :
File :
There should be a virtual filesystem. More directory should be added to it,
for instance /usr/share/GAME_NAME and ~/.GAME_NAME and it has to provide a
directory listing operator. In addition, it would be nice to be able to load
archives from the this virtual filesystem into it, so that game development
as well as release can be done in an easy and clean way. This problem is not
trivial, and should be further discussed. We have a C++ working version that
could be translated into C.

Settings :
Should it be in the core of SDL ? There seems to be dependancies from video to
settings. Anyway, it’s a good idea.

New module : internationalisation (perhaps not usefull in core)
It would be nice if all SDL applications could use the same system for string
translation. It should depends on filesystem and being extensible, so when
someone write a RTS map with script and messages, thoses messages could be
translated. imho, in a portable way, UTF8 should be used. We also have a C++
version, which could be usefull as a basis.

So, this is just my ideas. I wish good luck to SDL 2.0 :slight_smile:

Steph

Quand les riches se font la guerre, ce sont les pauvres qui meurent.
Jean-Paul Sartre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+cu0QkK/9a4l97XQRAhLHAJ97Rvs3oSTS/tTshVyvgR2zucvc0gCcD1/H
BjC9/WKJvTyGn1Yfq9A13LU=
=6Q4+
-----END PGP SIGNATURE-----

2

I agree about the virtual filesystem, I’m working on implementing one at the
moment, is it possible to use you code as a basis to work from ?

“Stephane Magnenat” wrote in message
news:200303151006.25378.nct at ysagoon.com…
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I’ve taken a look at SDL 2.0 draft API, and it seems promising to me.
We are developing a free software RTS game, and we have gone through most of
theses problems.

So, I’ve some proposal for modules :
File :
There should be a virtual filesystem. More directory should be added to it,
for instance /usr/share/GAME_NAME and ~/.GAME_NAME and it has to provide a
directory listing operator. In addition, it would be nice to be able to load
archives from the this virtual filesystem into it, so that game development
as well as release can be done in an easy and clean way. This problem is not
trivial, and should be further discussed. We have a C++ working version that
could be translated into C.

Settings :
Should it be in the core of SDL ? There seems to be dependancies from video
to
settings. Anyway, it’s a good idea.

New module : internationalisation (perhaps not usefull in core)
It would be nice if all SDL applications could use the same system for
string
translation. It should depends on filesystem and being extensible, so when
someone write a RTS map with script and messages, thoses messages could be
translated. imho, in a portable way, UTF8 should be used. We also have a C++
version, which could be usefull as a basis.

So, this is just my ideas. I wish good luck to SDL 2.0 :slight_smile:

Steph

Quand les riches se font la guerre, ce sont les pauvres qui meurent.
Jean-Paul Sartre
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+cu0QkK/9a4l97XQRAhLHAJ97Rvs3oSTS/tTshVyvgR2zucvc0gCcD1/H
BjC9/WKJvTyGn1Yfq9A13LU=
=6Q4+
-----END PGP SIGNATURE-----

3

I’ve taken a look at SDL 2.0 draft API, and it seems promising to me.
We are developing a free software RTS game, and we have gone through most
of
theses problems.

So, I’ve some proposal for modules :
File :
There should be a virtual filesystem. More directory should be added to it,
for instance /usr/share/GAME_NAME and ~/.GAME_NAME and it has to provide a
directory listing operator. In addition, it would be nice to be able to
load
archives from the this virtual filesystem into it, so that game development
as well as release can be done in an easy and clean way. This problem is
not
trivial, and should be further discussed. We have a C++ working version
that
could be translated into C.

Hi,

I’m working in such a VFS (in pascal though) and my experience about this is
that for a game you seek speed so the FS should be read-only, an optional
output module for saved games and the like it’s ok but not mixed with the
VFS.
Apart from that I heavily suggest to don’t include the filenames in the
internal directory tree (it’s a waste of memory). With just a simple hash
table (CRC32 works wonders for this) and single linked lists there is a very
noticeable speed improvement over a list of strings (even when using a
string cache).
Plugable simple encryption and decryption is easy to implement (maybe using
predefined algorithms).

Anyway I’m not sure if implementing a full featured VFS into SDL is a good
idea, I’d preffer just a framework (handling of the archive/directory memory
structures, etc) in SDL and then the final developer can plug-in his/her
own archive code. Something similar to the RWops of SDL 1.x but for
archives.

ciao,
ivan

4

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1On Saturday 15 March 2003 13:58, SofT wrote:

I agree about the virtual filesystem, I’m working on implementing one at
the moment, is it possible to use you code as a basis to work from ?

You can check out our code at :
http://savannah.nongnu.org/projects/glob2

It’s in the libgag directory, it’s the FileManager files.

Steph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+cydIkK/9a4l97XQRAovKAJwKhoRGFlVSW+y4OVlbUclWr+zHsgCeMwLZ
UT4XU6OftTQ7XOOX44X/05k=
=OaqC
-----END PGP SIGNATURE-----

5

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I’m working in such a VFS (in pascal though) and my experience about this
is that for a game you seek speed so the FS should be read-only, an
optional output module for saved games and the like it’s ok but not mixed
with the VFS.

In our implementation, the user directory ~/.GAME_NAME is added first. So the
user’s gfx and data, as well as user’s savegames are loaded first. The VFS
support write, and as user normally have acces to their home dir, it works
fine. In addition, on win9x system, it is possible to save either system wide
or in user’s home (but this require accessing the registry. On NT there is an
environment var which define user’s home).

But I agree SDL should provide a clean framework, and not include all game
specific features.

Anyway I’m not sure if implementing a full featured VFS into SDL is a good
idea, I’d preffer just a framework (handling of the archive/directory
memory structures, etc) in SDL and then the final developer can plug-in
his/her own archive code. Something similar to the RWops of SDL 1.x but for
archives.

I totally agree. SDL should provide sort of object oriented (like RWops, in C)
mechanism to dynamically plug-in archive filters.

Steph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+cyiBkK/9a4l97XQRAjehAJ0VW/nVfQu0A2xfYYfaLpHszgDBVQCbBpRy
OTzKJWW4wU4eK9lPHu7kv8k=
=p2Fn
-----END PGP SIGNATURE-----

6

i have spend a great deal of effort to develop my own VFS as have many who
are making a 3D engine. Bogging down the SDL engine with a VFS is a bad
idea,… unless offcourse it can be done in such a way that it does not have
any performance cost when choosing not to include the VFS in the SDL build.
Because i would offcourse remove the VFS & archive system since i have my
own ontop of which all my loaders are build.
So my 5 cents basicly is : make sure these things are optional and have no
run-time cost when you choose not to use them.
One thing i would like to see in SDL itself is offourse some basic I/O like
deleteing a file/dir making a dir ect. and something to itterate trough the
dir/file tree like findfirst/findnext under WIN32.

7

Hi,

I’ve taken a look at SDL 2.0 draft API, and it seems promising to me.

Could you direct me to this draft URL please?

Cheers

JG

8

Hello,

Yes, I would like to read the draft too. Where is the url ?
Cheers

Jan> Hi,

I’ve taken a look at SDL 2.0 draft API, and it seems promising to me.

Could you direct me to this draft URL please?

Cheers

JG

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

9

You could also use PhysicsFS: http://icculus.org/physfs/

-Ga?tan.On Sat, 2003-03-15 at 13:58, SofT wrote:

I agree about the virtual filesystem, I’m working on implementing one at the
moment, is it possible to use you code as a basis to work from ?

10

I’ve taken a look at SDL 2.0 draft API, and it seems promising to me.

Could you direct me to this draft URL please?

I guess he’s talking about the stuff on CVS (there is a new module
called SDL20)… You can access it via the web interface at:
http://www.libsdl.org/cgi/cvsweb.cgi/SDL20/

-Ga?tan.On Sat, 2003-03-15 at 15:11, J. Grant wrote:

11

I’m working in such a VFS (in pascal though) and my experience about this
is that for a game you seek speed so the FS should be read-only, an
optional output module for saved games and the like it’s ok but not mixed
with the VFS.

In our implementation, the user directory ~/.GAME_NAME is added first. So
the
user’s gfx and data, as well as user’s savegames are loaded first. The VFS
support write, and as user normally have acces to their home dir, it works
fine. In addition, on win9x system, it is possible to save either system
wide
or in user’s home (but this require accessing the registry. On NT there is
an
environment var which define user’s home).

Hi and sorry if this is becoming a bit too much “off-topic” :slight_smile:

SDL is an abstraction library, for file I/O the common denominator is “to
read”. To implement a write mechanism in an archive is difficult and slow!
unless we are using a block-based FS (FAT, NTFS, EXT2…) with ZIPs and the
likes, changing its contents usually means a rebuild of the archive.
Under my point of view an SDL VFS should include a clean framework to load
and read archives and a set of functions to make easier the development of
portable “user-made” archive loaders (buffered read, directory parsing…)

Making a VFS yourself is easy but from what I’ve seen so far many people
make the same mistakes, that’s how they handle the directory structure in
memory. The easiest way is to use a list of strings, this method is flexible
and powerful but when the amount of entries increases it becomes slow and
memory hungry (specially for consoles and other low memory systems).
SDL could enforce an effective method to handle that part and then it’s to
the individual programmer to make an “archiver” to his/her own needs.

ciao,
IvanFrom: nct@ysagoon.com (Stephane Magnenat)

12

I’ve found that the GNU internationalization has worked well so far.
(e.g., gettext() and friends)

My SDL application ‘Tux Paint’ runs on Mac OS X, Linux, NetBSD, Windows
and BeOS, and runs in over 2 dozen languages, including Japanese, Chinese,
Korean, Lithuanian, and Greek.

-bill!On Sat, Mar 15, 2003 at 10:06:17AM +0100, Stephane Magnenat wrote:

New module : internationalisation (perhaps not usefull in core)
It would be nice if all SDL applications could use the same system for string
translation. It should depends on filesystem and being extensible, so when
someone write a RTS map with script and messages, thoses messages could be
translated. imho, in a portable way, UTF8 should be used. We also have a C++
version, which could be usefull as a basis.

–
bill at newbreedsoftware.com Hire me!
http://newbreedsoftware.com/bill/ http://newbreedsoftware.com/bill/resume/

13

I agree. Expand the RWops enough to remove the problematic limitations
and let archiving be done externally–after all, the actual code to
handle archives can be platform-independent, so there’s little reason to
bloat SDL with it.

I also agree with Bill on i18n. We already have a wheel: gettext.On Sat, Mar 15, 2003 at 02:04:44PM +0100, Ivan Montes wrote:

Anyway I’m not sure if implementing a full featured VFS into SDL is a good
idea, I’d preffer just a framework (handling of the archive/directory memory
structures, etc) in SDL and then the final developer can plug-in his/her
own archive code. Something similar to the RWops of SDL 1.x but for
archives.

–
Glenn Maynard

14

I’ll need to take a look at it.

One thing I’ve always wanted, even as an add-on library (not even necessarily
an SDL_* one), is a way to platform-independently manage configuration
files.

E.g., on Windows, it would read/manipulate “.INI” files in the appropriate
place. (The “Registry”?)

On Linux and Unix, it would access “.*rc” files.

On Mac OS X, it would work with files under that “Preferences” folder.

et cetera.

What I’m doing right now is a bunch of #ifdef’s, and rolling my own.

-bill!On Sat, Mar 15, 2003 at 10:06:17AM +0100, Stephane Magnenat wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

I’ve taken a look at SDL 2.0 draft API, and it seems promising to me.
–
bill at newbreedsoftware.com Hire me!
http://newbreedsoftware.com/bill/ http://newbreedsoftware.com/bill/resume/

15

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One thing i would like to see in SDL itself is offourse some basic I/O like
deleteing a file/dir making a dir ect. and something to itterate trough the
dir/file tree like findfirst/findnext under WIN32.

Having an abstraction for stuff like findfirst/findnext is the core need.
I agree that the archive part could be put into a standard_but_not_core
library, like SDL_Net.
Anyway, as SDL 2.0 should be much more modular, I see no problem having
Archive in a Module. The question wether or not the module should be included
in the core seems premature to me, as we don’t know any module packagind
policy.

Steph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+c6g3kK/9a4l97XQRAvCKAKCGqrmMM0jQcusTA9XXlrxJYIpnnACfdu8N
pE/Rs88QmieGxR0yATT8lPY=
=SVAg
-----END PGP SIGNATURE-----

16

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I’ve found that the GNU internationalization has worked well so far.
(e.g., gettext() and friends)

I do not really like gettext for multiplateforme game code, because it’s heavy
and depends on locale. But I agree, internationalisation doesn’t need to be
in the core of SDL, so we can forget this issue for now.

Steph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+c6m/kK/9a4l97XQRAmXLAJwLtz04WM8zyvpWIF3+c8h5E/rVlwCfcDxl
6pqrnbhLwvcBznT5DvpGP6I=
=88Zz
-----END PGP SIGNATURE-----

17

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I guess he’s talking about the stuff on CVS (there is a new module
called SDL20)…

Yes I do.

Steph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+c6oWkK/9a4l97XQRAip/AJ0ZWfXk0kle5VKL2I64eoMWgrfziACff3xT
tZhPl/iaPFgQ7wiKRo3FzY0=
=l2sL
-----END PGP SIGNATURE-----

18

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

One thing I’ve always wanted, even as an add-on library (not even
necessarily an SDL_* one), is a way to platform-independently manage
configuration files.

E.g., on Windows, it would read/manipulate “.INI” files in the appropriate
place. (The “Registry”?)

On Linux and Unix, it would access “.*rc” files.

On Mac OS X, it would work with files under that “Preferences” folder.

et cetera.

What I’m doing right now is a bunch of #ifdef’s, and rolling my own.

Agreed, we need good conf/settings support. Perhaps we could do it in an SDL
add-on library for now, and put it into an SDL 2.0 module later ?
The draft version include in the 2.0 CVS is a basis.
Here is an idea : SDL_GetSetting(), which will return a const char* with the
draft API, could have pre-defined effect for some values, for instance,
SDL_GetSetting(“homedir”) could return home directory. So if the program
wants to write data into the user’s home directory, it will know where to
write.
Another thing about draft API : There should be possible to set the program’s
name for settings (perhaps it can be taken from window class name, but imho
it’s not clean).

Steph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+c6xNkK/9a4l97XQRAvs2AJ4hwHJ7Af+ycTC/U6p/WGd5cQJqawCfYmdH
7hn8ks5+ujfify+myb5rh2A=
=hJ3h
-----END PGP SIGNATURE-----

19

One thing i would like to see in SDL itself is offourse some basic I/O like
deleteing a file/dir making a dir ect. and something to itterate trough the
dir/file tree like findfirst/findnext under WIN32.

It would be nice if there was something to emulate either the POSIX directory functionality under MS Windows, or the MS Windows under… well, pretty much every other SDL platform (are there any without scandir, etc. apart from MS Windows?) There’s a lot of POSIX already available on MS Windows (at least with mingw) in dir.h, you’d just need to do #define chdir _chdir, etc.

As for findfirst/findnext vs. opendir, scandir, etc. - I’m really not bothered. findfirst and findnext would be easier to implement (on top of the POSIX functions, even), but it’d be pretty slow (when you use it, you’d have to keep chdir’ing). The POSIX system mighty take a lot more work to implement (you’d have to have fnmatch, alphasort and whatever to be really useful), but on the plus side, there’s probably some open source code you could just grab and recompile.

-samOn Sat, 15 Mar 2003 23:24:48 +0100 Stephane Magnenat wrote:

20

It would be nice if there was something to emulate either the POSIX
directory functionality under MS Windows

have you ever heard of msys? it isnt exactly what your asking for but it
might do.

it is basicly a bash prompt for windows that has its own /usr/ /local/ /bin/
directories etc. It does make, configure, it has libtool and all sorts of
other nifty handy dandy stuff. Of course it would only give you COMPILE
TIME posix directory support which sucks, but maybe this will be able to
help you in some way.

check it out if ya want:
http://www.mingw.org/download.shtml> ----- Original Message -----

From: sam.thursfield@btinternet.com (Sam Thursfield)
To:
Sent: Saturday, March 15, 2003 5:23 PM
Subject: Re: [SDL] Re: SDL 2.0 : File and internationalisation

On Sat, 15 Mar 2003 23:24:48 +0100 Stephane Magnenat wrote:

One thing i would like to see in SDL itself is offourse some basic I/O
like

deleteing a file/dir making a dir ect. and something to itterate trough
the

dir/file tree like findfirst/findnext under WIN32.

It would be nice if there was something to emulate either the POSIX
directory functionality under MS Windows, or the MS Windows under… well,
pretty much every other SDL platform (are there any without scandir, etc.
apart from MS Windows?) There’s a lot of POSIX already available on MS
Windows (at least with mingw) in dir.h, you’d just need to do #define chdir
_chdir, etc.

As for findfirst/findnext vs. opendir, scandir, etc. - I’m really not
bothered. findfirst and findnext would be easier to implement (on top of the
POSIX functions, even), but it’d be pretty slow (when you use it, you’d have
to keep chdir’ing). The POSIX system mighty take a lot more work to
implement (you’d have to have fnmatch, alphasort and whatever to be really
useful), but on the plus side, there’s probably some open source code you
could just grab and recompile.

-sam

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