gamedevlists-general — List for discussing general game development issues

Re: XML was RE: [GD-General] RE: A portable preferences library

[Jorrit T. <Jor...@uz...>]

Jorrit Tyberghein wrote:

> It is a matter of priorities. We don't think load time is a priority. 
> We think runtime
> performance is much more important. We don't have that much time to 
> spend on our project.
> We like to spend that time on the things that are most important.

I like to clarify this a bit more. In case of CS making such a faster loader
really is a HUGE amount of work. We have LOTS of different data to save. By
using XML we can generalize the loader/saver a lot and this makes our 
project a lot
more maintainable. Making specific optimized binary loaders and savers 
for all
our different plugins is a huge undertaking and it also means a lot more 
code
to maintain.

Greetings,

Re: XML was RE: [GD-General] RE: A portable preferences library

[J C L. <cl...@ka...>]

On Tue, 16 Dec 2003 09:39:19 +0100 
Jorrit Tyberghein <Jor...@uz...> wrote:
> Pierre Terdiman wrote:

> 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.

Agreed, but it is also one of the disadvantages in that they are all new
tools and fundamentally different tools (eg not stream based) than the
text processing tools you are already familiar with.  You're not only
making an investment in a data format, but in a set of processing tools
to go along with it at the same time...

-- 
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.

Re: XML was RE: [GD-General] RE: A portable preferences library

[Jorrit T. <Jor...@uz...>]

Alen Ladavac wrote:

>>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.
>>    
>>
>
>There is a mistake in your reasoning, isn't it? You say that we shouldn't look
>at the size of the uncompressed XML data. Then you start profiling how many
>uncompressed MB/s can you load. 
>
Well the engine IS loading uncompressed MB's. The decompression happens 
by another part
of the loader so when I'm talking about load time performance I'm 
talking about the time to parse
the UNCOMPRESSED file.

>You should look at the number of compressed
>MB/s. If running from harddisk, you should be loading between 5-20MB/s
>(depending on speed of the drive). Anything less than 5MB, and you are very
>CPU limited. And you should _never_ be CPU limited while loading. Not even
>close. If you are CPU limited on a 2GHz CPU, think about all the poor 700MHz
>Celeron users trying to load your game. There is no excuse for loading data at
>less speed than the media can stream.
>
Yes they are. You have to process the data. You have to send textures to 
the hardware (which is
something that you cannot do in load time). Note that binary dump of a 
structure is not possible
in our situation since Crystal Space is portable and has to run on 
various operating systems and
CPU architectures. So we cannot depend on binary data being compatible. 
That means there is
always SOME processing.

Greetings,

> Think about whether your users like to
>wait 20 seconds to load a level. If it could be loaded in 5, or even less...
>
>Can you get some more accurate profile?
>
>Alen
>
>
>
>-------------------------------------------------------
>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
>
>
>  
>

RE: XML was RE: [GD-General] RE: A portable preferences library

[Richard S. <Ric...@ei...>]

<snippage>

> > not performance. As others have pointed out besides me, you should=20
> > convert to binary formats for runtime loading.
> Although it seems this is not agreed upon by all, which surprises me.

Because I think people are looking at what is meant by 'data' =
differently.

If data is, for exmaple, seed data for an emergent behaviour which is
user modifiable, then leaving it in XML text makes complete sense.

If it is scene information which is loaded and used inside the game =
cycle
then it would be a madness not to optimise it as much as possible.

Pretty much everything falls between the two extremes, so there will =
always
be cases for both.

Oddly enough, there is no single right or wrong way of looking at these=20
issues because there is no single right definition of game data.

Rich

Re: XML was RE: [GD-General] RE: A portable preferences library

[Jorrit T. <Jor...@uz...>]

Gareth Lewin wrote:

>
>So what ? You are still doing processes on the data that are not required.
>Come on this is typical programming logic here, you don't have every
>function in your code recompute all of it's data do you ? Its the same
>thing.
>  
>
It is a matter of priorities. We don't think load time is a priority. We 
think runtime
performance is much more important. We don't have that much time to 
spend on our project.
We like to spend that time on the things that are most important.

>Lets not ignore the fact that loading bits of the level is way easier with a
>binary specific format that can be dumped directly into data structures.
>  
>
Yes but that's not portable. CS has to run on all kinds of operating 
systems and cpu's. We can't
dump binary structures like that. The endianess wouldn't be correct and 
padding can differ
too.

Greetings,

Re: XML was RE: [GD-General] RE: A portable preferences library

[Alen L. <ale...@cr...>]

> 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.

There is a mistake in your reasoning, isn't it? You say that we shouldn't look
at the size of the uncompressed XML data. Then you start profiling how many
uncompressed MB/s can you load. You should look at the number of compressed
MB/s. If running from harddisk, you should be loading between 5-20MB/s
(depending on speed of the drive). Anything less than 5MB, and you are very
CPU limited. And you should _never_ be CPU limited while loading. Not even
close. If you are CPU limited on a 2GHz CPU, think about all the poor 700MHz
Celeron users trying to load your game. There is no excuse for loading data at
less speed than the media can stream. Think about whether your users like to
wait 20 seconds to load a level. If it could be loaded in 5, or even less...

Can you get some more accurate profile?

Alen

RE: XML was RE: [GD-General] RE: A portable preferences library

[Richard S. <Ric...@ei...>]

> > Currently no parsers implement the entire set of standards as=20
> > they are still being written.=20
> So ? msxml is pretty fully featured for what we were discussing.

The point only is that XML is still an evolving standard, which is
something to be aware of when choosing tools.

> > a much faster uptake time of standards additions. MS have a habit of
> > adding unecessary proprietry extensions to their implementations of
> > standards which locks you in to their implementation.
> How is that valid ? That's the same opengl/directx linux/windows type
> argument. In what way is it related or productive to the discussion ?

It was one of the reasons we chose not to use MSXML. Many people have
experienced long term problems using MS implementations of standards
with MS proprietry additions (cf HTML). In planning for the long
term, it is a consideration.

> I prefer msxml mainly because everyone with IE6 on their=20
> machine has it, less to download. And Xerces (admittedly I haven't=20
> tried it in 2 years) had an awful interface and terrible =
documentation.=20
> I prefer expat if you want open source.

XercesC did seem to do everything we wanted directly our of the box =
(well,
zip file anyway). The documentation was good enough for us to start =
using it
immediately. This may well have changed since 2 years ago. One important
factor was that it was one of very few parsers which could do full
validation using XMLSchema. ExPat does not currently support schemas,
MSXML 4.0 does.

> > The smallest I know is mine which is the release time parser (debug
> > parser is fully validating XercesC) and it's a single class and
> > fills maybe 2 code pages (not including documentation, 1280*1024
> > resolution, full size MSVC editor window). XML really is that easy
> > to write straight parsers for.
> Well as yours isn't downloadable and CMarkup is, I'll stick=20
> with CMarkup.

Aye, my point only was that off-the-shelf parsers and optimisations
aside, you can always write your own pretty damn quickly (XML being
designed to be easily machine parseable) and use your own optimisations
(especially using string pools or other string related efficiencies).

Rich

RE: XML was RE: [GD-General] RE: A portable preferences library

[Gareth L. <GL...@cl...>]

A bit of copy paste magic here :) ( Just reordering the stuff )

> From: Ivan-Assen Ivanov [mailto:as...@ha...]

> By the way, we use expat in some of our projects - 
> and we've never used it as anything as a black box.
> It works, and it works well. We never used its "open-sourceness". 
> We wrapped it with a thin layer to feel more natural to use 
> from our code
> (coding conventions, storage issues etc.)
> It could have been MSXML just as well. 

THANK YOU!

> > Saying that all open source implementations of an XML parser
> > are 'bloated messes' is highly prejorative and demonstrably wrong.
> 
> Not all; I was saying that Xerces, last time I checked it, 
> was a bloated mess.

I agree, we were of the same opinion, thus we picked expat. (MSXML wasn't an
option, we are a console game).

> The choice of XML is first and foremost based on convenience,
> not performance. As others have pointed out besides me, you should 
> convert to binary formats for runtime loading.

Although it seems this is not agreed upon by all, which surprises me.

_____________________________________________________
Programmer, Sudeki - http://www.xbox.com/en-US/Sudeki
Gareth Lewin       - http://www.garethlewin.com

"Try or Try not, there is no Do" 

RE: XML was RE: [GD-General] RE: A portable preferences library

[Ivan-Assen I. <as...@ha...>]

> It seemed to me that it provided a way to lay out a GUI to allow
> data input to static XML. One requirement we have is that on selecting
> a piece of data, the GUI changes to show a set of possible choices.
> Essneitally, we want the GUI to guide the designer into using the
> correct data structure.
> 
> Is this what InfoPath is supposed to do? Does it dynamically change
> the GUI depending on current choices? Or is it static forms of
> data which represent an instance of the data the XML represents?

It is very easy to do - you can hide/show or reformat (font/colors etc.) controls
or groups of controls based on the values of other controls.

It has the concept of repeatable sections, which can be displayed as
series of identical grouped controls, or tables, and the user can insert/delete
sections.

You can perform simple validation with GUI-edited rules, or more
complex validation and event processing with JScript.

Of course, it's not perfect - I'm waiting to see the fabled version 3.0 - but
it's a great step up from grid-based editors like XMLSpy.

RE: XML was RE: [GD-General] RE: A portable preferences library

[Gareth L. <GL...@cl...>]

> These are REALLY big levels we are talking about here. i.e. 100000 
> polygons (each
> with lightmap data) and then about 50000 triangle meshes 
> (seperate from 
> that). Most modern
> games that I know don't try to load that many game data at once (most 
> use dynamic
> loading to load what they need later).

So what ? You are still doing processes on the data that are not required.
Come on this is typical programming logic here, you don't have every
function in your code recompute all of it's data do you ? Its the same
thing.

Lets not ignore the fact that loading bits of the level is way easier with a
binary specific format that can be dumped directly into data structures.

RE: XML was RE: [GD-General] RE: A portable preferences library

[Gareth L. <GL...@cl...>]

> Gareth Lewin wrote:
> 
> >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.
> >  
> >
> This would be possible but it would severely compromize the object 
> oriented design
> of CS. Performance is more than adequate IMHO so why 
> compromize proper 
> design in order
> to get more?
> 
> Greetings,

Is this a commercial project ? because 16-20 second load times are not
'adequate'. Also I don't see how this has any affet whatsoever on the design
of your 3d engine, you have to do the exact same procedures. I'm just
proposing you do it once, as apposed to once every time the level is loaded.

Mine solution is O(1) yours is O(n)

RE: XML was RE: [GD-General] RE: A portable preferences library

[Gareth L. <GL...@cl...>]

> > The most fancy on the PC is msxml, it doesn't everything, 
> > .NET basically uses it.
> 
> Currently no parsers implement the entire set of standards as 
> they are still being written. 

So ? msxml is pretty fully featured for what we were discussing.

> However, I would recommend Apache's
> XercesC over msxml. Technical reasons include that Xerces properly
> implements the open standard in an opensource manner. Xerces has
> a much faster uptake time of standards additions. MS have a habit of
> adding unecessary proprietry extensions to their implementations of
> standards which locks you in to their implementation.

How is that valid ? That's the same opengl/directx linux/windows type
argument. In what way is it related or productive to the discussion ? I
prefer msxml mainly because everyone with IE6 on their machine has it, less
to download. And Xerces (admittedly I haven't tried it in 2 years) had an
awful interface and terrible documentation. I prefer expat if you want open
source.

> 
> > 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 :)
> 
> The smallest I know is mine which is the release time parser (debug
> parser is fully validating XercesC) and it's a single class and
> fills maybe 2 code pages (not including documentation, 1280*1024
> resolution, full size MSVC editor window). XML really is that easy
> to write straight parsers for.

Well as yours isn't downloadable and CMarkup is, I'll stick with CMarkup.

RE: XML was RE: [GD-General] RE: A portable preferences library

[Gareth L. <GL...@cl...>]

> Actually, I remember reading an article comparing the performance of
> MSXML (used via COM interop) with the .NET XML classes, so I 
> believe they
> are different. The .NET classes are written in C# (and are a 
> bit slower).
> 
> About vertex data: we have a dual-pass data processing scheme, where
> first a simple dumb Max plugin dumps all the data Max 
> provides into a verbose
> format. The second pass reads the raw vertex data, builds meshes, 
> optimizes, etc. and prepares single-seek binary files. It is 
> convenient to
> separate the flaky DLL-hell Max SDK part from the part the 
> does the real work.
> 
> In such a scenario, I believe it's OK to use XML for the first format.
> Maybe when the assets grow to be in the order of hundreds or thousands
> of meshes, it will show on the build time.
> 

I totally agree with you here. Intermeditry formats are very good. Not only
to get around the max DLL crap, but also so you can write exporters from
various tools to the same format, and write tools that load the xml up,
modify the data (stripify, build bsd trees, whatever) and write out the xml
again.

But single seek files, preferably ones that can be read directly into
memory, are (to me) a must for games.

RE: XML was RE: [GD-General] RE: A portable preferences library

[Richard S. <Ric...@ei...>]

> I'll repeat myself and say Infopath adds a whole new=20
> dimension of usefullness
> to XML. If you think IE showing XMLs color-coded and collapsible,
> or even with a custom stylesheet, is cool, imagine building a sensible
> user interface for editing complex structures, with=20
> validation, in hours not days.=20

I did go and take a look, but there was no downloadable trial, and I
don't want to wait for MS to post me a CD from the US. They did provide
an interactive demo, which was in fact just someone trying to tell
me how great it was without actually telling me what it did. Score
one for marketing, nill for development.

It seemed to me that it provided a way to lay out a GUI to allow
data input to static XML. One requirement we have is that on selecting
a piece of data, the GUI changes to show a set of possible choices.
Essneitally, we want the GUI to guide the designer into using the
correct data structure.

Is this what InfoPath is supposed to do? Does it dynamically change
the GUI depending on current choices? Or is it static forms of
data which represent an instance of the data the XML represents?

Alternatively, is there way of downloading the trial version?

Rich

RE: XML was RE: [GD-General] RE: A portable preferences library

[Ivan-Assen I. <as...@ha...>]

> Saying that all open source implementations of an XML parser
> are 'bloated messes' is highly prejorative and demonstrably wrong.

Not all; I was saying that Xerces, last time I checked it, was a bloated mess.

> I would suggest that an Apache implementation of an XML parser
> is more likely to be fast and effective than an MS one, because
> they have some thousands of developers looking over their shoulder.
> A benefit MS does not have.

To the contrary. MS does have thousands of developers in-house, a lot of them
depending on the quality of the XML parser. Microsoft has a very well developed
system for internal communications, so I wouldn't be suprised if developers
of core components like MSXML get the same, if not greater feedback than
open source projects.

> To include 'a couple of lines of COM calls' as a complete use of
> an XML parser fails to account for the unmeasurable costs of using
> a system which you cannot profile, let alone modify, which is designed
> to cover a multitude of sins as opposed to the relatively small number
> needed for a given application.

The choice of XML is first and foremost based on convenience,
not performance. As others have pointed out besides me, you should 
convert to binary formats for runtime loading.

> This is a matter of engineering. There are notable technical advantages
> of using an open source standardised solution over using a closed 
> proprietry one. 

Xerces isn't any more "standardised" than MSXML - both are implementations
of the XML standard, but there is no "standard implementation".
Both conform to the subset of the XML standards we need.

By the way, we use expat in some of our projects - 
and we've never used it as anything as a black box.
It works, and it works well. We never used its "open-sourceness". 
We wrapped it with a thin layer to feel more natural to use from our code
(coding conventions, storage issues etc.)
It could have been MSXML just as well. 

RE: XML was RE: [GD-General] RE: A portable preferences library

[Paul B. <pa...@mi...>]

The .NET System.Xml code is not based on the MSXML parser.
They are different codebases and handle different standards
differently.

> -----Original Message-----
> From: gam...@li...=20
> [mailto:gam...@li...] On=20
> Behalf Of Gareth Lewin
> Sent: Tuesday, December 16, 2003 6:40 AM
> To: gam...@li...
> Subject: RE: XML was RE: [GD-General] RE: A portable=20
> preferences library
>=20
> > > > 1. Because developers are already using XML and have=20
> 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?
> >=20
> > 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=20
> couple of=20
> > K.
>=20
> The most fancy on the PC is msxml, it doesn't everything,=20
> .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 :)
>=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_id=3D557
>=20
>=20

Re: XML was RE: [GD-General] RE: A portable preferences library

[Jorrit T. <Jor...@uz...>]

Ivan-Assen Ivanov wrote:

> I second Gareth here. 16-20 seconds is NOT adequate level load time on
>
>a reasonably modern PC. You shouldn't ever do load-time anything that 
>can do level-export-time. This doesn't contradict with nice OO design, and 
>if you feel like "duplicating" code if you shift parsing and preprocessing to the
>tools, maybe you should use the more politically correct word "reuse".
>
>  
>
There is also another issue why I don't do this. It takes a lot of time 
to make
this optimized loader (although possible). I think there are a lot more 
important
things to do. Optimzing speed at runtime for example. We have only so much
free time :-)

Greetings,

Re: XML was RE: [GD-General] RE: A portable preferences library

[Jorrit T. <Jor...@uz...>]

Ivan-Assen Ivanov wrote:

> I second Gareth here. 16-20 seconds is NOT adequate level load time on
>
>a reasonably modern PC. You shouldn't ever do load-time anything that 
>can do level-export-time. This doesn't contradict with nice OO design, and 
>if you feel like "duplicating" code if you shift parsing and preprocessing to the
>tools, maybe you should use the more politically correct word "reuse".
>  
>
These are REALLY big levels we are talking about here. i.e. 100000 
polygons (each
with lightmap data) and then about 50000 triangle meshes (seperate from 
that). Most modern
games that I know don't try to load that many game data at once (most 
use dynamic
loading to load what they need later).

Greetings,

RE: XML was RE: [GD-General] RE: A portable preferences library

[Richard S. <Ric...@ei...>]

> > Technical reasons include that Xerces properly
> > implements the open standard in an opensource manner.=20
> This is a political reason, not a technical reason. I=20
> wouldn't base the choice
> of including a bloated mess of dozens of source files over a=20
> couple of lines of COM calls,
> on what is a proper opensource manner, or what habits MS has.=20
> It's a matter of engineering, not Slashdot karma.

Using open standards and open source is a technical decision
as well as a political one. If you do not agree with the technical
benefits if such an approach, that's fine, but it does not
invalidate them.

Saying that all open source implementations of an XML parser
are 'bloated messes' is highly prejorative and demonstrably wrong.
I would suggest that an Apache implementation of an XML parser
is more likely to be fast and effective than an MS one, because
they have some thousands of developers looking over their shoulder.
A benefit MS does not have.

To include 'a couple of lines of COM calls' as a complete use of
an XML parser fails to account for the unmeasurable costs of using
a system which you cannot profile, let alone modify, which is designed
to cover a multitude of sins as opposed to the relatively small number
needed for a given application.

This is a matter of engineering. There are notable technical advantages
of using an open source standardised solution over using a closed=20
proprietry one. I'm not entirely sure how you can think otherwise.

Rich

Re: XML was RE: [GD-General] RE: A portable preferences library

[Noel L. <ll...@co...>]

On Tue, 16 Dec 2003 12:42:45 -0000
"Alen Ladavac" <ale...@cr...> wrote:

> 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. ;)

I think that looking at XML as the final format to load assets in the
game is missing the point.

XML is great for many of the things listed here, but sometimes (only
sometimes), it makes sense to use a different format to optimize
load/parse times.

For instance, we export all of our models, hierarchy, meshes, and
materials into an XML format. Artists can take those files and drop
them straight in the game and everything will work fine. However, our
resource build will convert all geometry into optimized, binary
formats that can be loaded with no overhead, because we profiled it
and determined it *did* make a difference (and working on console
games, it's one of those things that really matters).

There are some formats we haven't bothered changing from XML (hierarchy,
materials, etc) since the amount of time loading them and parsing them
is negligible compared to the rest of the load times.


--Noel

RE: XML was RE: [GD-General] RE: A portable preferences library

[Ivan-Assen I. <as...@ha...>]

> >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.
> >  
> >
> This would be possible but it would severely compromize the object oriented design
> of CS. Performance is more than adequate IMHO so why  compromize proper 
> design in order to get more?

I second Gareth here. 16-20 seconds is NOT adequate level load time on
a reasonably modern PC. You shouldn't ever do load-time anything that 
can do level-export-time. This doesn't contradict with nice OO design, and 
if you feel like "duplicating" code if you shift parsing and preprocessing to the
tools, maybe you should use the more politically correct word "reuse".

Re: XML was RE: [GD-General] RE: A portable preferences library

[Jorrit T. <Jor...@uz...>]

Gareth Lewin wrote:

>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.
>  
>
This would be possible but it would severely compromize the object 
oriented design
of CS. Performance is more than adequate IMHO so why compromize proper 
design in order
to get more?

Greetings,

RE: XML was RE: [GD-General] RE: A portable preferences library

[Ivan-Assen I. <as...@ha...>]

> Technical reasons include that Xerces properly
> implements the open standard in an opensource manner. 

This is a political reason, not a technical reason. I wouldn't base the choice
of including a bloated mess of dozens of source files over a couple of lines of COM calls,
on what is a proper opensource manner, or what habits MS has. 
It's a matter of engineering, not Slashdot karma.

RE: XML was RE: [GD-General] RE: A portable preferences library

[Ivan-Assen I. <as...@ha...>]

> The most fancy on the PC is msxml, it doesn't everything, .NET basically
> uses it.

Actually, I remember reading an article comparing the performance of
MSXML (used via COM interop) with the .NET XML classes, so I believe they
are different. The .NET classes are written in C# (and are a bit slower).

About vertex data: we have a dual-pass data processing scheme, where
first a simple dumb Max plugin dumps all the data Max provides into a verbose
format. The second pass reads the raw vertex data, builds meshes, 
optimizes, etc. and prepares single-seek binary files. It is convenient to
separate the flaky DLL-hell Max SDK part from the part the does the real work.

In such a scenario, I believe it's OK to use XML for the first format.
Maybe when the assets grow to be in the order of hundreds or thousands
of meshes, it will show on the build time.

I'll repeat myself and say Infopath adds a whole new dimension of usefullness
to XML. If you think IE showing XMLs color-coded and collapsible,
or even with a custom stylesheet, is cool, imagine building a sensible
user interface for editing complex structures, with validation, in hours
not days. 

RE: XML was RE: [GD-General] RE: A portable preferences library

[Richard S. <Ric...@ei...>]

> The most fancy on the PC is msxml, it doesn't everything,=20
> .NET basically uses it.

Currently no parsers implement the entire set of standards as=20
they are still being written. However, I would recommend Apache's
XercesC over msxml. Technical reasons include that Xerces properly
implements the open standard in an opensource manner. Xerces has
a much faster uptake time of standards additions. MS have a habit of
adding unecessary proprietry extensions to their implementations of
standards which locks you in to their implementation.

> 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 :)

The smallest I know is mine which is the release time parser (debug
parser is fully validating XercesC) and it's a single class and
fills maybe 2 code pages (not including documentation, 1280*1024
resolution, full size MSVC editor window). XML really is that easy
to write straight parsers for.

Rich