gamedevlists-general

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

> 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

[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

[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

[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

[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

[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

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

Sorry, but you are just wrong.

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

There is no reason whatsoever for final proccessed data to be portable. You
have your data in xml. You preprocess it into binary format for a specific
build/platform. And you use that. Your load times go from 16seconds to 2 or
3 seconds.

And the amount of effort required to implement binary saving off of
structures isn't anywhere near comparable with the effort required to tweak
the speed of a graphics engine. Not to mention that 16-20 second load times
would have me returning the game to the shop.

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

[brian s. <pud...@po...>]

Would you please give it a rest?  In case you haven't noticed there's 
no "shop" involved for you to return his game to, as he's giving his 
work away freely.  Jorrit is not doing this as a full-time job.  If 
load times are not his first priority I can hardly blame him, it's not 
exactly the "fun" part of the job.

Please visit http://crystal.sf.net to get clued in.

--brian

On Tuesday, December 16, 2003, at 07:59  AM, Gareth Lewin wrote:

> Sorry, but you are just wrong.
>
>>> 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.
>>
>
> There is no reason whatsoever for final proccessed data to be 
> portable. You
> have your data in xml. You preprocess it into binary format for a 
> specific
> build/platform. And you use that. Your load times go from 16seconds to 
> 2 or
> 3 seconds.
>
> And the amount of effort required to implement binary saving off of
> structures isn't anywhere near comparable with the effort required to 
> tweak
> the speed of a graphics engine. Not to mention that 16-20 second load 
> times
> would have me returning the game to the shop.
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for 
> IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys 
> admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> 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

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

Gareth and Jorrit are going each too far in their own direction. I believe
that the reality lies in between. Putting everything into platform-specific
down-to-the-bit-optimized binary data is killing a fly with a cannon, for most
purposes. The only place where the load peformance matters so much is if you
want to stream your data during gameplay, and if you need it quickly, so you
have very little CPU to spend. Other than that, the only thing that you should
care about is that you are limited by HDD throughput, not by CPU speed. As
long as your CPU is ahead of the HDD, you are fine.

What I do is to have a binary format that is universal and that can load any
kind of objects. It can swap the bytes for endianness, etc. but it knows in
advance what layout looks like (in endianness neutral format), and doesn't
have to parse ASCII, let alone generic XML syntax. This is not giving any
generality away, while still allowing you to keep you loading speed under
control. I don't know of any platform where the CPU is so slow that it cannot
perform endianness swapping and such small adjustments while loading. But
going towards XML might be just a bit of an overkill. I say _might_, not _is_.
... because I asked the original question about loading speed plainly because
I am interested in whether XML can be as efficient as a binary format. I
belive that it is not very likely, but not impossiible, and I will accept any
well profiled arguments. While this:

>In case of CS making such a faster loader
>really is a HUGE amount of work. We have LOTS of different data to save

is not something like that. I understand that CS team is not working on a
budget, and it is great that they do stuff for fun and for others (though back
when I was doing coding for my own fun, I wanted the results to be perfect as
well, but thats a different topic). But priorities of CS team _have nothing to
do_ with XML qualities. If I recall, it was the performance of XML parsers
that was discussed, not the idea of whether a loader should be fast or not. If
I say that my loader should be fast, then I guess it should. I was just hoping
that someone can show me some exact numbers.

On a side note, this comment that "it is a HUGE ammount of work", is based on
a wrong assumption. Their problem is that the design was wrong. If they went
for generic binary format from the start, the work would be near zero. But I
digress.

Can you Jorrit please get some more correct profiling data. It doesn't matter
that your app does preprocessing in-game, it is your choice. But how fast is
the parser itself?

Thanks,
Alen



----- Original Message -----
From: "brian sharon" <pud...@po...>
To: <gam...@li...>
Sent: Tuesday, December 16, 2003 16:16
Subject: Re: XML was RE: [GD-General] RE: A portable preferences library


> Would you please give it a rest?  In case you haven't noticed there's
> no "shop" involved for you to return his game to, as he's giving his
> work away freely.  Jorrit is not doing this as a full-time job.  If
> load times are not his first priority I can hardly blame him, it's not
> exactly the "fun" part of the job.
>
> Please visit http://crystal.sf.net to get clued in.
>
> --brian
>
> On Tuesday, December 16, 2003, at 07:59  AM, Gareth Lewin wrote:
>
> > Sorry, but you are just wrong.
> >
> >>> 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.
> >>
> >
> > There is no reason whatsoever for final proccessed data to be
> > portable. You
> > have your data in xml. You preprocess it into binary format for a
> > specific
> > build/platform. And you use that. Your load times go from 16seconds to
> > 2 or
> > 3 seconds.
> >
> > And the amount of effort required to implement binary saving off of
> > structures isn't anywhere near comparable with the effort required to
> > tweak
> > the speed of a graphics engine. Not to mention that 16-20 second load
> > times
> > would have me returning the game to the shop.
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for
> > IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys
> > admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> 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

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

On Tue, 16 Dec 2003 18:54:16 -0000 
Alen Ladavac <ale...@cr...> wrote:

> On a side note, this comment that "it is a HUGE ammount of work", is
> based on a wrong assumption. Their problem is that the design was
> wrong. If they went for generic binary format from the start, the work
> would be near zero. But I digress.

No, you missed the boat.

XML is an encoding format.  It says nothing about the data structures or
data representation beyond the encoding.  More simply, through use of
URI anchors and references there is little (nothing?) that can be
represented in a serialised binary format that can't also be represented
in XML.  

The discussion to date has on representing things like raw vertex data
in a highly abstracted XML form.  That has obvious and unpleasant
post-processing expenses.  If you don't want those costs, don't incur
them: encode your already post-processed system-optimised yada yada data
structures into XML.  There's nothing inherent to XML or binary data to
prevent that.  You don't need to design or write your encoding format.

XML is JUST an encoding format.  Well, it also happens to be a
standardised encoding format, but that's more of a toolchain and code
support issue.  At the end of the day where disk heads don't meet
platters the effective differentials are in the storage and parsing
overheads, not in the data structures.  The data that is represented is
arbitrary, and for systems which don't need random reads (XML indexes
badly) the performance differentials are invariably trivial.

This written by someone who doesn't /like/ XML...

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

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

Nope, you missed the boat. :) The idea is that XML is a generic format, 
freeing you from writing your parser. There is no much point storing plain 
blobs inside XML. Then, you can just dump it with fwrite() as well. But the 
question is: If you save your vertices in x="1" y="0"...etc format, can that 
still load as fast as if you just dump 3f8000000000000...etc? (Hex dump from 
head - might have some errors ;) ). People started to argue that the 
verboseness of the format doesn't hinder its performance. I say, ok, it 
might be possible, but show me the numbers. Didn't see any yet. :/ 

Alen 


J C Lawrence writes: 

> On Tue, 16 Dec 2003 18:54:16 -0000 
> Alen Ladavac <ale...@cr...> wrote: 
> 
>> On a side note, this comment that "it is a HUGE ammount of work", is
>> based on a wrong assumption. Their problem is that the design was
>> wrong. If they went for generic binary format from the start, the work
>> would be near zero. But I digress.
> 
> No, you missed the boat. 
> 
> XML is an encoding format.  It says nothing about the data structures or
> data representation beyond the encoding.  More simply, through use of
> URI anchors and references there is little (nothing?) that can be
> represented in a serialised binary format that can't also be represented
> in XML.   
> 
> The discussion to date has on representing things like raw vertex data
> in a highly abstracted XML form.  That has obvious and unpleasant
> post-processing expenses.  If you don't want those costs, don't incur
> them: encode your already post-processed system-optimised yada yada data
> structures into XML.  There's nothing inherent to XML or binary data to
> prevent that.  You don't need to design or write your encoding format. 
> 
> XML is JUST an encoding format.  Well, it also happens to be a
> standardised encoding format, but that's more of a toolchain and code
> support issue.  At the end of the day where disk heads don't meet
> platters the effective differentials are in the storage and parsing
> overheads, not in the data structures.  The data that is represented is
> arbitrary, and for systems which don't need random reads (XML indexes
> badly) the performance differentials are invariably trivial. 
> 
> This written by someone who doesn't /like/ XML... 
> 
> -- 
> 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. 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> 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

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

On Tue, 16 Dec 2003 21:53:36 +0100 
Alen Ladavac <ale...@cr...> wrote:

> Nope, you missed the boat. :) 

Damn, I'm gonna fire that ranging scout!

> The idea is that XML is a generic format, freeing you from writing
> your parser. 

Precisely.

> There is no much point storing plain blobs inside XML. Then, you can
> just dump it with fwrite() as well. 

Dumping a blob in XML really isn't that much more difficult.  You either
drop it inline as a base64 or as a MIME attachment in base64.  The data
size grows by 30% of course, but that's expected as a text
representation.

> But the question is: If you save your vertices in x="1" y="0"...etc
> format, can that still load as fast as if you just dump
> 3f8000000000000...etc? 

Of course not.  

  double foo[large_number];
  ...
  read (h, foo, sizeof (foo[0]) * large_number)

Is necessarily going to be cheaper than parsing an XML structure of
large_number doubles.  The only question is whether the added expense is
worth it on some level.  If you're shaving instructions...

> People started to argue that the verboseness of the format doesn't
> hinder its performance. I say, ok, it might be possible, but show me
> the numbers. Didn't see any yet. :/

Frankly and numbers you see need to be treated with a lot of salt, even
the ones I post.  It is a simple enough thing to test with whatever
parser you pick.  

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

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

> Damn, I'm gonna fire that ranging scout!
:) 

>   double foo[large_number];
>   ...
>   read (h, foo, sizeof (foo[0]) * large_number) 
> 
> Is necessarily going to be cheaper than parsing an XML structure of
> large_number doubles.  The only question is whether the added expense is
> worth it on some level.  If you're shaving instructions...

Look, remember one thing: when doing things like this, always think about 
the bottleneck. Here, media speed is your bottleneck. Whatever you do, you 
can never be faster than it. Now, if you pipeline it well, you are free to 
use as much CPU time as media needs to stream it from disk. So the XML 
parser might as well have exact same speed as binary solution! 

The question is: is there some XML parser that can be fast enough to pull 
that trick, when run on some current CPU (and which), reading from some 
current media (and which)? Is there? 

And remember that it would need to be put in chain with an unzipper, for a 
fair race against a binary reader with unzipper, both running against the 
same file. 

But for example purposes, I'll accept an unzipper+XMLparser pair getting 
near media streaming speed, as a proof that XML doesn't suck. ;) 

Alen 

>> People started to argue that the verboseness of the format doesn't
>> hinder its performance. I say, ok, it might be possible, but show me
>> the numbers. Didn't see any yet. :/
> 
> Frankly and numbers you see need to be treated with a lot of salt, even
> the ones I post.  It is a simple enough thing to test with whatever
> parser you pick.   
> 
> -- 
> 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. 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> 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

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

Gareth Lewin wrote:

>
>There is no reason whatsoever for final proccessed data to be portable. You
>have your data in xml. You preprocess it into binary format for a specific
>build/platform. And you use that. Your load times go from 16seconds to 2 or
>3 seconds.
>
>And the amount of effort required to implement binary saving off of
>structures isn't anywhere near comparable with the effort required to tweak
>the speed of a graphics engine. Not to mention that 16-20 second load times
>would have me returning the game to the shop.
>  
>
Really? I'm amazed. What does 16 seconds mean for a game you're supposed 
to play for hours
(i.e. it is an MMORPG). That is negligable. If you really return a game 
to the shop for something
like that then I think you have weird priorities. No offense meant.

Greetings,

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

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

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

There might be many right ways, but there are definitly some wrong ways.
Loading up vertex and face data, and then actually processing said data
(buidling kd-trees, bsd trees, light map calculatio, stripping etc) is just
wrong.

There might be some grey areas, but there is still a lot of stuff which is
obviously xml (config settings, keymaps etc) and some which is obviously
binary data.

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

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

Gareth Lewin wrote:

>>Oddly enough, there is no single right or wrong way of 
>>looking at these 
>>issues because there is no single right definition of game data.
>>    
>>
>
>There might be many right ways, but there are definitly some wrong ways.
>Loading up vertex and face data, and then actually processing said data
>(buidling kd-trees, bsd trees, light map calculatio, stripping etc) is just
>wrong.
>  
>
Note that the building of the kd-tree differs depending on conditions 
(i.e. depending on
hardware vs software rendering a different depth of tree may be build). 
So it is not
possible to precompute the kdtree as it is dynamic EVEN at the start. 
Note that building
the kdtree is extremely fast though.

Lightmap calculation is obviously precalculated as that takes hours on 
big maps.

Greetings,

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

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

I'm sorry Brian, but that is besides the point. We were discussing how best
to do something, and his argument wasn't just one of time, but that his idea
was better. 

But yeah, I guess we should concentrate on the fun and not discuss the right
way to do stuff. Since like no-one on this list makes commercial games.

> -----Original Message-----
> From: brian sharon [mailto:pud...@po...]
> Sent: 16 December 2003 16:16
> To: gam...@li...
> Subject: Re: XML was RE: [GD-General] RE: A portable 
> preferences library
> 
> 
> Would you please give it a rest?  In case you haven't noticed there's 
> no "shop" involved for you to return his game to, as he's giving his 
> work away freely.  Jorrit is not doing this as a full-time job.  If 
> load times are not his first priority I can hardly blame him, 
> it's not 
> exactly the "fun" part of the job.
> 
> Please visit http://crystal.sf.net to get clued in.
> 
> --brian
> 
> On Tuesday, December 16, 2003, at 07:59  AM, Gareth Lewin wrote:
> 
> > Sorry, but you are just wrong.
> >
> >>> 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.
> >>
> >
> > There is no reason whatsoever for final proccessed data to be 
> > portable. You
> > have your data in xml. You preprocess it into binary format for a 
> > specific
> > build/platform. And you use that. Your load times go from 
> 16seconds to 
> > 2 or
> > 3 seconds.
> >
> > And the amount of effort required to implement binary saving off of
> > structures isn't anywhere near comparable with the effort 
> required to 
> > tweak
> > the speed of a graphics engine. Not to mention that 16-20 
> second load 
> > times
> > would have me returning the game to the shop.
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for 
> > IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys 
> > admin.
> > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> > _______________________________________________
> > Gamedevlists-general mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=557
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign 
> up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell 
> to sys admin.
> Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
> _______________________________________________
> 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

[brian s. <pud...@po...>]

Well for the record I make commercial games, and our engine does 
extensive platform-based preprocessing so that level loads are a single 
read into memory, and yes, it's the "right" way, and oh by the way 
we've drifted far, far away from portable preferences libraries.

My point was merely that load times might not be the #1 priority for 
someone who is doing this in his spare time, and it's probably more 
productive to note that and move on.

--brian

On Tuesday, December 16, 2003, at 09:31  AM, Gareth Lewin wrote:

> I'm sorry Brian, but that is besides the point. We were discussing how 
> best
> to do something, and his argument wasn't just one of time, but that 
> his idea
> was better.
>
> But yeah, I guess we should concentrate on the fun and not discuss the 
> right
> way to do stuff. Since like no-one on this list makes commercial games.
>
>> -----Original Message-----
>> From: brian sharon [mailto:pud...@po...]
>> Sent: 16 December 2003 16:16
>> To: gam...@li...
>> Subject: Re: XML was RE: [GD-General] RE: A portable
>> preferences library
>>
>>
>> Would you please give it a rest?  In case you haven't noticed there's
>> no "shop" involved for you to return his game to, as he's giving his
>> work away freely.  Jorrit is not doing this as a full-time job.  If
>> load times are not his first priority I can hardly blame him,
>> it's not
>> exactly the "fun" part of the job.
>>
>> Please visit http://crystal.sf.net to get clued in.
>>
>> --brian
>>
>> On Tuesday, December 16, 2003, at 07:59  AM, Gareth Lewin wrote:
>>
>>> Sorry, but you are just wrong.
>>>
>>>>> 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.
>>>>
>>>
>>> There is no reason whatsoever for final proccessed data to be
>>> portable. You
>>> have your data in xml. You preprocess it into binary format for a
>>> specific
>>> build/platform. And you use that. Your load times go from
>> 16seconds to
>>> 2 or
>>> 3 seconds.
>>>
>>> And the amount of effort required to implement binary saving off of
>>> structures isn't anywhere near comparable with the effort
>> required to
>>> tweak
>>> the speed of a graphics engine. Not to mention that 16-20
>> second load
>>> times
>>> would have me returning the game to the shop.

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

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

Gareth Lewin wrote:

>I'm sorry Brian, but that is besides the point. We were discussing how best
>to do something, and his argument wasn't just one of time, but that his idea
>was better. 
>  
>
Where did I said that my idea was better? I never said that. I only say 
that's how we do it
in CS and for CS I still think that the XML way is the good way.

Greetings,

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

[Mat N. \(BUNGIE\) <mat...@mi...>]

That's a pretty arrogant way to look at this discussion. Small load
times improve every aspect of a project, commercial or not. It's faster
to debug, faster to load, faster to play, and in general creates the
impression of a much more efficient product.

MSN

-----Original Message-----
From: gam...@li...
[mailto:gam...@li...] On Behalf Of
Gareth Lewin
Sent: Tuesday, December 16, 2003 9:32 AM
To: gam...@li...
Subject: RE: XML was RE: [GD-General] RE: A portable preferences library

I'm sorry Brian, but that is besides the point. We were discussing how
best
to do something, and his argument wasn't just one of time, but that his
idea
was better.=20

But yeah, I guess we should concentrate on the fun and not discuss the
right
way to do stuff. Since like no-one on this list makes commercial games.

> -----Original Message-----
> From: brian sharon [mailto:pud...@po...]
> Sent: 16 December 2003 16:16
> To: gam...@li...
> Subject: Re: XML was RE: [GD-General] RE: A portable=20
> preferences library
>=20
>=20
> Would you please give it a rest?  In case you haven't noticed there's=20
> no "shop" involved for you to return his game to, as he's giving his=20
> work away freely.  Jorrit is not doing this as a full-time job.  If=20
> load times are not his first priority I can hardly blame him,=20
> it's not=20
> exactly the "fun" part of the job.
>=20
> Please visit http://crystal.sf.net to get clued in.
>=20
> --brian
>=20
> On Tuesday, December 16, 2003, at 07:59  AM, Gareth Lewin wrote:
>=20
> > Sorry, but you are just wrong.
> >
> >>> 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=20
> operating
> >> systems and cpu's. We can't
> >> dump binary structures like that. The endianess wouldn't be
> >> correct and
> >> padding can differ
> >> too.
> >>
> >
> > There is no reason whatsoever for final proccessed data to be=20
> > portable. You
> > have your data in xml. You preprocess it into binary format for a=20
> > specific
> > build/platform. And you use that. Your load times go from=20
> 16seconds to=20
> > 2 or
> > 3 seconds.
> >
> > And the amount of effort required to implement binary saving off of
> > structures isn't anywhere near comparable with the effort=20
> required to=20
> > tweak
> > the speed of a graphics engine. Not to mention that 16-20=20
> second load=20
> > times
> > would have me returning the game to the shop.
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: IBM Linux Tutorials.
> > Become an expert in LINUX or just sharpen your skills.  Sign up for=20
> > IBM's
> > Free Linux Tutorials.  Learn everything from the bash shell to sys=20
> > admin.
> > Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> > _______________________________________________
> > 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
>=20
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign=20
> up for IBM's
> Free Linux Tutorials.  Learn everything from the bash shell=20
> to sys admin.
> Click now! =
http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
> _______________________________________________
> 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


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=3D1278&alloc_id=3D3371&op=3Dclick
_______________________________________________
Gamedevlists-general mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=3D557

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

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

Without replying specifically to any point on this thread:

  http://www.faqs.org/docs/artu/ch05s01.html

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