gamedevlists-general Mailing List for gamedev (Page 32)

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

> The most fancy on the PC is msxml, it doesn't everything, 

of course I mean 'it does everything'

> > > 1. Because developers are already using XML and have since thrown
> > > away, forgotten or don't want to write a parser.
> > Just curious, what is the footprint of the XML parser you are 
> > using? I know
> > some that are like >3MB of binary code. That stuff gives me 
> > the creeps. Perhaps you have some lightweight one?
> 
> There are parsers to suit all needs. The largest fully validation
> parsers with spoinks and added wurlitsers are in the couple of meg 
> area. Micro parsers with no valdation can be as small as a couple of 
> K.

The most fancy on the PC is msxml, it doesn't everything, .NET basically
uses it.
The smallest I know is CMarkup (search for it on Codeproject). it's
literally a single class of C++ code, it's smaller than a few k :)

Gareth Lewin wrote:

>>We have no performance problems at all related to XML. The 
>>XML parsing 
>>is only a fraction
>>of the total cost.
>>
>>    
>>
>
>The total cost of what ?
>
Of game loading. i.e. XML parsing is negligable compared to all the rest 
that has
to be done.

> Game data files should be stored (in the final
>form) in a form that requires as little parsing as possible. This makes
>level loading significatly faster, reduces memory overhead (you have to
>start pre-caching earlier) etc etc.
>  
>
Well that means we have to duplicate all loader code which is something 
we are
not going to do. This approach is much nicer.

However, CS does support binary XML though. This doesn't appear to give 
a lot
of benefit so we don't use it by default.

Greetings,

> > 1. Because developers are already using XML and have since thrown
> > away, forgotten or don't want to write a parser.
> Just curious, what is the footprint of the XML parser you are=20
> using? I know
> some that are like >3MB of binary code. That stuff gives me=20
> the creeps. Perhaps you have some lightweight one?

There are parsers to suit all needs. The largest fully validation
parsers with spoinks and added wurlitsers are in the couple of meg=20
area. Micro parsers with no valdation can be as small as a couple of=20
K.

A quick google showed a large number of XML parsers which claimed
to be small and fast. Several were open source. I'm pretty sure
it would be easy to find one that suits.

> Also, what kind of info are you people storing in XML files?=20
> I often hear
> comments about how XML is so great that we should store=20
> everything in it.

Ah, no :*) People who say that tend to be application programmers
or web monkeys, where size of data or speed of parsing tends to
be less important. XML shouod be used to store data where the=20
format gives it lots of added value.

Broadly speaking (very broadly) XML is going to be of much more
use to AI programmers, gameplay programmers and designers. I'm
not a graphics programmer, but I can't really see a case where=20
it would be any good for holding data about vertices, or any
other graphics data, as someone asked elsewhere in the thread.

However, for holding game object initialisation data for a component
based system, it is a godsend. For representing game rules or formulae,
it is extremely effective. Entire game AI can be represented, whether
it be a state based system, a rules based system, goal orientated
or emergent. The entire system can be expressed in validated XML
allowing designers to modify any element to their hearts content.
It ensure syntax safety so they can't break anything. You can also
use it to enforce symantic safety though generally I'd prefer to do
that in code.

XML is there to provide us the mechanism for giving them this data=20
driven architecture they keep saying they want. It's certainly not
there to give us a better way of representing our graphics data.

> Alen

Rich

Ok, I missed the following bit from your first email

-------------
The PlaneShift game (made with CS) has about 25 megabytes (uncompressed) 
of XML files (aggregated
in four big files) of level data. On my Linux system at home (an Athlon 
XP2000) the levels load
in about 16-20 seconds. That includes the following operations:
    - Extracting the XML data from the ZIP.
    - Parsing of XML.
    - Creation of all objects.
    - Loading of all textures used in the levels and preparing them for 
use with OpenGL.
    - Creation of the kdtree for the visibility culler.
    - Loading of the lightmap data for the 100000 polygons that are in 
those levels.
    - Creation of oriented bounding boxes for collision detection (this 
is the most
-------------

You write that as if it's a positive. Surely if the data was binary packed,
with the textures prepared for your renderer, the kdtree preproccesed, the
lightmap data stored with the polygons and the oriented bounding boxes
precalculated you could just do

----------
    - Extracting the data from the ZIP.
    - Loading of all textures used in the levels 
----------

None of those steps change without the level changing, so why waste all that
time. 16-20 seconds is a hell of a long for a level to load when you could
do 16(guestimate) of those seconds offline.

> -----Original Message-----
> From: Jorrit Tyberghein [mailto:Jor...@uz...]
> Sent: 16 December 2003 12:29
> To: gam...@li...
> Subject: Re: XML was RE: [GD-General] RE: A portable 
> preferences library
> 
> 
> Gareth Lewin wrote:
> 
> >Hopefully you aren't building a mesh from that at run time ? 
> >
> >XML is good, XML is great. But please tell me that you 
> aren't considering
> >having mullion polygon meshes in text format ready to be 
> parsed at runtime ?
> >  
> >
> Well they are parsed at load time. But it all goes very fast 
> (as my mail 
> below shows).
> We have no performance problems at all related to XML. The 
> XML parsing 
> is only a fraction
> of the total cost.
> 
> Greetings,
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

> We have no performance problems at all related to XML. The 
> XML parsing 
> is only a fraction
> of the total cost.
> 

The total cost of what ? Game data files should be stored (in the final
form) in a form that requires as little parsing as possible. This makes
level loading significatly faster, reduces memory overhead (you have to
start pre-caching earlier) etc etc.

Gareth Lewin wrote:

>Hopefully you aren't building a mesh from that at run time ? 
>
>XML is good, XML is great. But please tell me that you aren't considering
>having mullion polygon meshes in text format ready to be parsed at runtime ?
>  
>
Well they are parsed at load time. But it all goes very fast (as my mail 
below shows).
We have no performance problems at all related to XML. The XML parsing 
is only a fraction
of the total cost.

Greetings,

Hopefully you aren't building a mesh from that at run time ? 

XML is good, XML is great. But please tell me that you aren't considering
having mullion polygon meshes in text format ready to be parsed at runtime ?

On a side note, those of you with the 'luck' to work on pc games, you can
just use the msxml parser, which is pretty fully featured.

> -----Original Message-----
> From: Jorrit Tyberghein [mailto:Jor...@uz...]
> Sent: 16 December 2003 12:14
> To: gam...@li...
> Subject: Re: XML was RE: [GD-General] RE: A portable 
> preferences library
> 
> 
> Alen Ladavac wrote:
> 
> >>We use XML a lot in Crystal Space (http://crystal.sf.net). 
> It does tend
> >>to give very
> >>big files but we also found that it doesn't matter.
> >>    
> >>
> >
> >Just how big that is? Can you please compare size of a mesh 
> in XML format to
> >the same mesh in, say, .3ds or .lwo?
> >  
> >
> I didn't make the map files so I don't have any of the model 
> files that
> were used but I can show you an example of a simple mesh in CS:
> 
>     <meshobj name="cube">
>        <plugin>thing</plugin>
>        <params>
>           <v x="-1" y="0" z="1" />
>           <v x="0" y="0" z="1" />
>           ... (more vertices follow)
>           <material>brick</material>
>           <p> <v>0</v> <v>1</v> <v>2</v> </p>
>           <p> <v>3</v> <v>2</v> <v>4</v> <v>5</v> </p>
>           ... (more polygons follow)
>        </params>
>     </meshobj>
> 
> So this is indeed pretty verbose.
> 
> >  
> >
> >>CS supports reading
> >>from ZIP files
> >>so map files are usually placed in compressed archives. XML 
> compresses very
> >>well (due to the high redundancy) so the size disadvantage 
> nearly completely
> >>disappears in that case.
> >>    
> >>
> >
> >Can you also please compare size of a zipped XML mesh and a 
> zipped .3ds, or
> >.lwo or similar format of the same mesh?
> >  
> >
> Sorry. Don't have the needed models to do that.
> 
> >Also, in case that zipping really does remove the redundancy 
> well enough to
> >allow us to ignore the size difference, did you check your 
> effective loading
> >throughput? Meaning how much MB/sec can you read from the 
> disk. To make sure
> >that the parser is not slowing your loading. Ideally, you 
> should be limited by
> >the transfer rate of the disk, not by the CPU.
> >  
> >
> The PlaneShift game (made with CS) has about 25 megabytes 
> (uncompressed) 
> of XML files (aggregated
> in four big files) of level data. On my Linux system at home 
> (an Athlon 
> XP2000) the levels load
> in about 16-20 seconds. That includes the following operations:
>     - Extracting the XML data from the ZIP.
>     - Parsing of XML.
>     - Creation of all objects.
>     - Loading of all textures used in the levels and 
> preparing them for 
> use with OpenGL.
>     - Creation of the kdtree for the visibility culler.
>     - Loading of the lightmap data for the 100000 polygons 
> that are in 
> those levels.
>     - Creation of oriented bounding boxes for collision 
> detection (this 
> is the most
>       time consuming operation of all things mentioned here).
> 
> I don't have seperate numbers for XML parsing but it is a relatively 
> small part
> of the entire thing. Of course this is done using a hand-made 
> XML parser 
> which
> is very lean and mean and is optimized specifically towards reading.
> 
> Greetings,
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=557
> 

Alen Ladavac wrote:

>>We use XML a lot in Crystal Space (http://crystal.sf.net). It does tend
>>to give very
>>big files but we also found that it doesn't matter.
>>    
>>
>
>Just how big that is? Can you please compare size of a mesh in XML format to
>the same mesh in, say, .3ds or .lwo?
>  
>
I didn't make the map files so I don't have any of the model files that
were used but I can show you an example of a simple mesh in CS:

    <meshobj name="cube">
       <plugin>thing</plugin>
       <params>
          <v x="-1" y="0" z="1" />
          <v x="0" y="0" z="1" />
          ... (more vertices follow)
          <material>brick</material>
          <p> <v>0</v> <v>1</v> <v>2</v> </p>
          <p> <v>3</v> <v>2</v> <v>4</v> <v>5</v> </p>
          ... (more polygons follow)
       </params>
    </meshobj>

So this is indeed pretty verbose.

>  
>
>>CS supports reading
>>from ZIP files
>>so map files are usually placed in compressed archives. XML compresses very
>>well (due to the high redundancy) so the size disadvantage nearly completely
>>disappears in that case.
>>    
>>
>
>Can you also please compare size of a zipped XML mesh and a zipped .3ds, or
>.lwo or similar format of the same mesh?
>  
>
Sorry. Don't have the needed models to do that.

>Also, in case that zipping really does remove the redundancy well enough to
>allow us to ignore the size difference, did you check your effective loading
>throughput? Meaning how much MB/sec can you read from the disk. To make sure
>that the parser is not slowing your loading. Ideally, you should be limited by
>the transfer rate of the disk, not by the CPU.
>  
>
The PlaneShift game (made with CS) has about 25 megabytes (uncompressed) 
of XML files (aggregated
in four big files) of level data. On my Linux system at home (an Athlon 
XP2000) the levels load
in about 16-20 seconds. That includes the following operations:
    - Extracting the XML data from the ZIP.
    - Parsing of XML.
    - Creation of all objects.
    - Loading of all textures used in the levels and preparing them for 
use with OpenGL.
    - Creation of the kdtree for the visibility culler.
    - Loading of the lightmap data for the 100000 polygons that are in 
those levels.
    - Creation of oriented bounding boxes for collision detection (this 
is the most
      time consuming operation of all things mentioned here).

I don't have seperate numbers for XML parsing but it is a relatively 
small part
of the entire thing. Of course this is done using a hand-made XML parser 
which
is very lean and mean and is optimized specifically towards reading.

Greetings,

> We use XML a lot in Crystal Space (http://crystal.sf.net). It does tend
> to give very
> big files but we also found that it doesn't matter.

Just how big that is? Can you please compare size of a mesh in XML format to
the same mesh in, say, .3ds or .lwo?

> CS supports reading
> from ZIP files
> so map files are usually placed in compressed archives. XML compresses very
> well (due to the high redundancy) so the size disadvantage nearly completely
> disappears in that case.

Can you also please compare size of a zipped XML mesh and a zipped .3ds, or
.lwo or similar format of the same mesh?

Also, in case that zipping really does remove the redundancy well enough to
allow us to ignore the size difference, did you check your effective loading
throughput? Meaning how much MB/sec can you read from the disk. To make sure
that the parser is not slowing your loading. Ideally, you should be limited by
the transfer rate of the disk, not by the CPU.

Please bear with me here... I have no problems with converting, but I must
make sure that it is _the_ true religion. ;)

Thanks,
Alen

Pierre Terdiman wrote:

>It's kinda interesting to read in the same thread:
>
>"What I like about XML is that it is an easy to read [snip]"
>
>and then
>
>"It also has the variously massive disadvantages of not being particularly
>human readable [snip]"
>
>...
>  
>
Actually in a sense both comments are true :-)

If you read XML in a text editor that doesn't have any specific XML features
then it is not THAT easy to read. However, there are lots of tools in 
existance
that can browse XML files in a more structured way. And in that sense
it becomes very easy to read. This is also one of the advantages of XML. 
There
are so many tools available.

Greetings,

Alen Ladavac wrote:

>
>Also, what kind of info are you people storing in XML files? I often hear
>comments about how XML is so great that we should store everything in it.
>Erm... well... I know I'm not an XML expert, but I've never seen an XML file
>that was not too bloated. Can any one show me an example XML format for e.g. a
>mesh, that would be reasonable in size? Don't get me wrong, a little bloating
>is ok for small data, like prefs, if it gives you flexibility, etc., but this
>thing with "large data blobs" sounds scary.
>
>I'll be glad if you can prove me wrong. :)
>
>  
>
We use XML a lot in Crystal Space (http://crystal.sf.net). It does tend 
to give very
big files but we also found that it doesn't matter. CS supports reading 
from ZIP files
so map files are usually placed in compressed archives. XML compresses very
well (due to the high redundancy) so the size disadvantage nearly completely
disappears in that case.

So you shouldn't really look at the size of the XML file. It doesn't 
matter in most
cases.

Greetings,

It's kinda interesting to read in the same thread:

"What I like about XML is that it is an easy to read [snip]"

and then

"It also has the variously massive disadvantages of not being particularly
human readable [snip]"

...

> 1. Because developers are already using XML and have since thrown
> away, forgotten or don't want to write a parser.

Just curious, what is the footprint of the XML parser you are using? I know
some that are like >3MB of binary code. That stuff gives me the creeps.
Perhaps you have some lightweight one?

> -- Able to standardly represent simple/small and large/complex types (eg
> basic types and large data blobs).

Also, what kind of info are you people storing in XML files? I often hear
comments about how XML is so great that we should store everything in it.
Erm... well... I know I'm not an XML expert, but I've never seen an XML file
that was not too bloated. Can any one show me an example XML format for e.g. a
mesh, that would be reasonable in size? Don't get me wrong, a little bloating
is ok for small data, like prefs, if it gives you flexibility, etc., but this
thing with "large data blobs" sounds scary.

I'll be glad if you can prove me wrong. :)

--
Alen

On Mon, 15 Dec 2003 23:14:17 -0500 
Brian Hook <ho...@py...> wrote:

> So here's a question -- I know that whenever a discussion about text
> file formats comes up there is often a "use XML" grenade tossed into
> it.  Now, I can think of a lot of reasons NOT to use XML (i.e. it's
> overkill, for one), but I'm curious what real, tangible reasons for
> using XML exist, as opposed to a simple application specific structure
> (like INI files).

-- Generic off-the-shelf known-working/correct parser.

-- Generic off-the-shelf correctness/validity known working/correct
checking (mostly, modulo DTD details etc).

-- Able to represent complex nested/recursive structures.

-- Able to standardly represent simple/small and large/complex types (eg
basic types and large data blobs).

-- Relatively easily processed and viewed/edited by other tools.

-- Can safely/accurately refer to data objects stored externally to the
dataset (eg MIME objects in-file or fully external).

-- Relatively mature toolchain.

-- Relatively familiar to potential employees and their preferred
toolchains.

It is however a very large hammer for what is usually a very small nut.
It also has the variously massive disadvantages of not being
particularly human readable and of working poorly with standard text
processing tools (eg grep/sed/perl/cut/etc).

-- 
J C Lawrence
---------(*)                Satan, oscillate my metallic sonatas.
cl...@ka...               He lived as a devil, eh?
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

Overkill - agreed :).

However, one thing I think it has over basic text files is it has an
inherent ability to represent trees of data, whereas its more difficult (but
not impossible) to put that into a basic var=data; type ini file.

-Dan

----- Original Message ----- 
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Monday, December 15, 2003 8:29 PM
Subject: [email] Re: XML was RE: [GD-General] RE: A portable preferences
library

> 1. Because developers are already using XML and have since thrown
> away, forgotten or don't want to write a parser.

This presumes that the developer is going to use some third party XML
parser, right?

> 3. People (or users) could theoretically seek help from the myriad
> of books available in how to cusotmize their preferences.

Hmmm, pretty iffy, that.

> 4. Very extensible.

..which is of questionable practical value if all you need is a
simple text format.

Not trying to be antagonistic, just trying to understand the issues =)

Brian

-------------------------------------------------------
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive?  Does it
help you create better code?  SHARE THE LOVE, and help us help
YOU!  Click Here: http://sourceforge.net/donate/
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7

What I like about XML is that it is an easy to read, easy to edit, and
object oriented (depending on how you use it, of course).  People are
familiar with it, it's very extensible and can be used on a number of
completely unrelated game systems, and there are 3rd party tools/api's =
if
you don't want to roll your own parser.

As a more practical example, I'm planning on re-writing a piece of code =
to
use XML.  Currently we have files which artists create using a tool =
which
describes animations, models, special effects, etc for a "character" in =
our
game.  These files are saved as binary files, and are added to version
control.  I think you can see where I'm going with this - too often =
artist X
got confused and checked in very old versions of these files.  Because =
they
were binary, doing diffs and such was next to impossible.  It'd be nice =
to
see that artist Y added this particle system to the character and that's =
why
our frame rate is plummeting.

Obviously any text file format would do the trick here, but since we =
have a
working XML system, and it's "object oriented", it's pretty easy to do.  =
End
result is a new file format that's easy to read and edit, in code or by
hand.

I'm not saying XML is the end all be all of text file formats, but it =
sure
makes sense if you've got it working.  Oh, and if you view XML files in =
IE
they are color coded and you can expand/collapse the tags!!! w00t. =3D)

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...] On Behalf Of
> Brian Hook
> Sent: Monday, December 15, 2003 11:14 PM
> To: gam...@li...
> Subject: [gamedevlist] XML was RE: [GD-General] RE: A portable =
preferences
> library
>=20
> This list server is getting more and more flakey...anyway, this is a
> repost since my prior one evidently went into the great void..
>=20
> > Behalf Of Jeff Laing
> > I'm surprised that no-one has said "use XML format please" - its
> > not that painful, given that you'll have a fairly limited schema
> > to implement.
>=20
> So here's a question -- I know that whenever a discussion about text
> file formats comes up there is often a "use XML" grenade tossed into
> it.  Now, I can think of a lot of reasons NOT to use XML (i.e. it's
> overkill, for one), but I'm curious what real, tangible reasons for
> using XML exist, as opposed to a simple application specific structure
> (like INI files).
>=20
> Brian
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7

One of the problems typically encountered when trying to design a 
portable library's API is dealing with platform specific 
flags/parameters.

Examples:

- specifying choice of DX or OpenGL under Windows (moot under Linux 
and OS X)

- choice of OpenGL32.DLL

- specifying preference for DD 5.1 vs. stereo sound

- selecting IRDA vs. TCP/IP for sockets on a PocketPC

There are at least two standard ways of handling this that I'm aware 
of.  The first is to simply have a ton of flags that are known to be 
system specific, e.g. you have a PREFER_OPENGL flag which is ignored 
on everything but Windows:

MyLib_init( ..., SOME_FLAGS | PREFER_OPENGL );

The second way is to have "backdoor" functions that are only available 
on a specific platform, so possibly requiring an #ifdef:

#ifdef _WIN32
MyLib_setOpenGLLibrary( "opengl32.dll" );
#endif

I've never liked these, because they pollute all namespaces for the 
sake of a hack on a small subset of platforms.

Then I remembered the cvar system in the Quakes.  I always thought of 
them as borderline hackery, but in hindsight they're actually elegant 
in their ability to broadcast huge amounts of information, dynamically 
(editable at console) but in a fashion that only the interested 
subsystems will care about.

You can set "gl_finish 1" and it has no effect, unless you're running 
the GL renderer.

So instead of polluting/hacking an API in order to deal with each 
platform's little quirks, it seems that it would be better to use a 
cvar system to broadcast all non-portable or dynamic information.

What I've done is made a simple properties system, which I'm sure 
everyone else has done as well.  Then for a particular API, you simply 
pass it the property system and it uses that for any private crap it 
needs.

property_system *ps;

PropLib_createPropertySystem( &ps );
PropLib_setPropertyString( ps, "opengl DLL", "opengl32.dll" );
.
.
.
MyLib_initOpenGL( ... /* misc stuff */, ps );

You can then dump all your

This does introduce a dependency on a new library, the property_system 
stuff, but it seems to have a lot of other benefits going for it if 
you're developing a lot of portable libs.

This ties into the PrefLib as well, since I was having a hard time 
reconciling PrefLib's persistency vs. performance expectations (i.e. 
does it cache then write on flush, or does it always write-on-modify, 
etc.).

So now PrefLib is WAY smaller, because it doesn't have its own 
property system.  Instead, you simply create your properties using 
PropLib, then you can serialize however/whenever you want:

PrefLib_createPreferences( &pf, "com.pyrogon.mynewgame" );
PrefLib_writeProperties( pf, ps );

The PrefLib ONLY takes care of reading/writing to the platform 
specific preferences facilities (although at this point I'm just 
preferring file system preferences and only going to the registry when 
requested), and it doesn't handle property management at all.

It's a clean break between the two, which is probably what I should 
have done originally.  And more importantly, I've solved a problem for 
my other to-be-open-sourced stuff with how they deal with platform 
configuration options.

Does this all sound sane?

Brian

> 1. Because developers are already using XML and have since thrown
> away, forgotten or don't want to write a parser.

This presumes that the developer is going to use some third party XML 
parser, right? 

> 3. People (or users) could theoretically seek help from the myriad
> of books available in how to cusotmize their preferences.

Hmmm, pretty iffy, that.

> 4. Very extensible.

..which is of questionable practical value if all you need is a 
simple text format.

Not trying to be antagonistic, just trying to understand the issues =3D)

Brian

Overkill agreed, but you asked for tangible reasons:

1. Because developers are already using XML and have since thrown away, =
forgotten or don't want to write a parser.
2. Related to #1, stopped using lex/yacc so it can actually take more =
time to implement a simple text parser than support another xml file.
3. People (or users) could theoretically seek help from the myriad of =
books available in how to cusotmize their preferences.
4. Very extensible.

Brett

----- Original Message -----=20
From: "Brian Hook" <ho...@py...>
To: <gam...@li...>
Sent: Tuesday, December 16, 2003 12:14 PM
Subject: XML was RE: [GD-General] RE: A portable preferences library

> This list server is getting more and more flakey...anyway, this is a=20
> repost since my prior one evidently went into the great void..
>=20
> > Behalf Of Jeff Laing
> > I'm surprised that no-one has said "use XML format please" - its
> > not that painful, given that you'll have a fairly limited schema
> > to implement.
>=20
> So here's a question -- I know that whenever a discussion about text=20
> file formats comes up there is often a "use XML" grenade tossed into=20
> it.  Now, I can think of a lot of reasons NOT to use XML (i.e. it's=20
> overkill, for one), but I'm curious what real, tangible reasons for=20
> using XML exist, as opposed to a simple application specific structure =

> (like INI files).
>=20
> Brian
>=20
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive?  Does it
> help you create better code?  SHARE THE LOVE, and help us help
> YOU!  Click Here: http://sourceforge.net/donate/
> _______________________________________________
> Gamedevlists-general mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU7

We ended up using a ton of Xpath query expressions in a number
of places throughout development.  We had a simple commandline
tool called 'xq' that allowed our designers to run xpath queries
against data.

We also used a number of languages (Perl, Python, .net stuff,
etc...) for our tools.  Sure, you can parse INI files in all
of those languages but we didn't have to write any code as
it was.

Finally, we used XML Schema for external data validation.  While
it didn't do semantic validation, things like Schematron might
have been interesting there.

There were other advantages but interop (in lots of forms) was
the most useful.
=20

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Brian Hook
> Sent: Monday, December 15, 2003 10:14 PM
> To: gam...@li...
> Subject: XML was RE: [GD-General] RE: A portable preferences library
>=20
> This list server is getting more and more flakey...anyway,=20
> this is a repost since my prior one evidently went into the=20
> great void..
>=20
> > Behalf Of Jeff Laing
> > I'm surprised that no-one has said "use XML format please"=20
> - its not=20
> > that painful, given that you'll have a fairly limited schema to=20
> > implement.
>=20
> So here's a question -- I know that whenever a discussion=20
> about text file formats comes up there is often a "use XML"=20
> grenade tossed into it.  Now, I can think of a lot of reasons=20
> NOT to use XML (i.e. it's overkill, for one), but I'm curious=20
> what real, tangible reasons for using XML exist, as opposed=20
> to a simple application specific structure (like INI files).
>=20
> Brian
>=20

This list server is getting more and more flakey...anyway, this is a 
repost since my prior one evidently went into the great void..

> Behalf Of Jeff Laing
> I'm surprised that no-one has said "use XML format please" - its
> not that painful, given that you'll have a fairly limited schema
> to implement.

So here's a question -- I know that whenever a discussion about text 
file formats comes up there is often a "use XML" grenade tossed into 
it.  Now, I can think of a lot of reasons NOT to use XML (i.e. it's 
overkill, for one), but I'm curious what real, tangible reasons for 
using XML exist, as opposed to a simple application specific structure 
(like INI files).

Brian

Please ignore.

> significant number of sales for that to be worth while).  I don't
> know what Brian intends for his "general library" but I'm betting
> that supporting "just the latest variant of Windows" may not be his
> aim.

Well, my original goals were quite simple, but then after this 
discussion, they've become muddied =3D)

I've since changed it to prefer using a file system.  It simply stores 
into INI-style preference files that are ASCII.  Binary data is 
converted (inefficiently) to ASCII data (i.e. 0xBC =3D> "BC").

Preferences can be saved as user local, system wide or application 
common.  

The default implementation is mostly done, and it's extremely slow, 
but it's readable, which is what's important for a project like this.  
I'm going to finish it up and put it up on CVS when I get a chance.  
The biggest problem will be suitable testing.

And yes, I could have used Lua, but that would have been drastic 
overkill for something like this, especially since the availability of 
OS-specific preferences is still something I'd like to support (Win32 
registry and OS X Preferences).  I'm in the camp that a file is better 
than some registry setting, but I'd rather not dictate policy, just 
provide an abstraction that lets others make that choice as they see 
fit.

It's all endian safe (in theory, testing will bear this out one way or 
another).  I've actually been bitten by the situation where a 
preference file is shared on the same file system by two different 
implementations.  NingPo Mah Jong would do an endian-unsafe fwrite of 
its high scores structure, but I didn't care about the endianess since 
I didn't conceive of a situation where you would write it out one way 
and then need to read it back another.

Of course, as with so many assumptions, I was wrong =3D)  In this 
particular case, there was a filesystem shared between Linux/x86 and 
Sparc Solaris, and so the prefs were written out in Linux, then read 
back when someone was using the Sparc implementation and...ka-boom.

Brian

> Date: Fri, 5 Dec 2003 13:12:48 +0100
> From: Andras Balogh <bn...@ma...>
> To: gam...@li...
> Subject: Re: [GD-General] RE: A portable preferences library
> Reply-To: gam...@li...
> 
> How about using delayed dll loading together with SetDllDirectory??

Woh, a new API, thanks for the pointer - checks MSDN - ok, that only works
if you constrain yourself to running XP SP1.

Sadly, my app still needs to run back to NT4 (and yes, we get a significant
number of sales for that to be worth while).  I don't know what Brian
intends for his "general library" but I'm betting that supporting "just the
latest variant of Windows" may not be his aim.

However, your point is noted and I will adjust my responses to future
discussion of this topic.

2001	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep (3)	Oct (28)	Nov (13)	Dec (168)
2002	Jan (51)	Feb (16)	Mar (29)	Apr (3)	May (24)	Jun (25)	Jul (43)	Aug (18)	Sep (41)	Oct (16)	Nov (37)	Dec (208)
2003	Jan (82)	Feb (89)	Mar (54)	Apr (75)	May (78)	Jun (141)	Jul (47)	Aug (7)	Sep (3)	Oct (16)	Nov (50)	Dec (213)
2004	Jan (76)	Feb (76)	Mar (23)	Apr (30)	May (14)	Jun (37)	Jul (64)	Aug (29)	Sep (25)	Oct (26)	Nov (1)	Dec (10)
2005	Jan (9)	Feb (3)	Mar	Apr	May (11)	Jun	Jul (39)	Aug (1)	Sep (1)	Oct (4)	Nov	Dec
2006	Jan (24)	Feb (18)	Mar (9)	Apr	May	Jun	Jul (14)	Aug (29)	Sep (2)	Oct (5)	Nov (4)	Dec
2007	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (11)	Sep (9)	Oct (5)	Nov (4)	Dec
2008	Jan	Feb	Mar	Apr (1)	May (34)	Jun	Jul (9)	Aug	Sep	Oct	Nov	Dec (4)
2016	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug (1)	Sep	Oct	Nov	Dec

gamedevlists-general Mailing List for gamedev (Page 32)

gamedevlists-general — List for discussing general game development issues