Thread: RE: [GD-General] A portable preferences library (Page 2)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Andrew G. <ag...@cl...> - 2003-12-04 22:17:49
|
I haven't been to the last few, but some of the presentations at Meltdown were always pretty good sources of "do's & don'ts" to ensure your application would play nicely with current and upcoming versions of Windows. Most of them are avaiable on the web, for example here's one I remember containing some information about things your game shouldn't do if you want it to play nicely with the Fast User Switching which would be introduced in (the then upcoming) XP. http://www.microsoft.com/mscorp/corpevents/meltdown2001/ppt/GamingWinXP.ppt > -----Original Message----- > From: Andrew Grant [mailto:ag...@cl...] > Sent: 04 December 2003 22:10 > To: 'gam...@li...' > Subject: RE: [GD-General] A portable preferences library > > > The accepted wisdom for the past few years has been for > applications to use SHGet*FolderLocation(), it's certainly > something that Microsoft have been advocating since Win2K > started to become mass market and now with every new consumer > system shipping with a varient of XP it's even more important. > > GetWindows/System directory are definitely things an > application shouldn't be writing to in the normal course of > its operation... The common paths exposed via environment > variables (some of them at least!) are useful for batch files > & scripts. > > > _____________________________________ > andrew grant | programmer | climax brighton > ag...@cl... - www.climax.co.uk > > > |
|
From: Andrew G. <ag...@cl...> - 2003-12-04 23:13:07
|
Indeed, having all important data in once place really is nice. Now if only all user preferences in applications was as easy to backup or transfer between PCs :) AFAIK under Win98/ME most of the CSIDL stuff still works but goes to either "\Windows\My Documents" or "Windows\profiles\user\My Documents" if you have profiles setup. It's something like that but it does work. The other benefit is that if one day the location of user data should change (as was the case between NT4->Win2K) then providing your app uses these functions then things will automagically work. I do actually remember that game thing you're talking about. From what I recall a percentage of your drive could be allocated for use with games and their gamedata/persistent storage. Data from less played games would be evicted as necessary thus if you didn't play "Super FPS 7" for a few months then the next time you came to play it then you'd be prompted for the install disks so it could restore it's data. HD space is dirt cheap these days though so perhaps it was shelved. Sounds vaguely like what's offered by the xbox though. A. > -----Original Message----- > From: Tom Spilman [mailto:to...@pi...] > Sent: 04 December 2003 22:59 > To: gam...@li... > Subject: RE: [GD-General] A portable preferences library > > > > -----Original Message----- > > Behalf Of Andrew Grant > > > The accepted wisdom for the past few years has been for > > applications to use SHGet*FolderLocation(), it's certainly > > something that Microsoft have been advocating since Win2K > > started to become mass market and now with every new consumer > > system shipping with a varient of XP it's even more important. > > For example some slightly popular games GTA3 and GTA3: > Vice City place save games into a directory in the current > users My Documents folder. So does the latest Deus Ex 2 > demo. And even though I've uninstalled all three I still > have my save games in a place where I can find them and > decide to keep or delete them. Also knowing that I can just > backup my documents and just re-install my games Is really > nice. Better than each end user becoming an expert in > different games particular standard for keeping their data. > > About three years ago I remember speaking to some DX > guy about a standard they were working on for PC game > installs. Something about using a fixed percentage of the > drive for game installs and it automatically managing it. > Anyone remember anything about that or was that a crunch mode > delusion? > > Also where does SHGetSpecialFolderPath( CSIDL_PERSONAL > ) ( My Documents ) go on Win98/ME systems? > > Tom > > |
|
From: Andrew G. <ag...@cl...> - 2003-12-04 23:15:28
|
Yipes, sorry I was thinking of hardware rasterisers. How time flies :) > -----Original Message----- > From: Brian Hook [mailto:ho...@py...] > Sent: 04 December 2003 23:10 > To: gam...@li... > Subject: RE: [GD-General] A portable preferences library > > > > To all intents and purposes, it required hardware T&L support. > > This is unequivocally false. Quake 3 ran very well on > vanilla TNT and > TNT2 systems. > > Brian > > |
|
From: Jeff L. <je...@SP...> - 2003-12-04 23:19:37
|
> I'm also aghast at the sheer # of files that most applications and
> games require for installation into /windows/system32 and /windows,
> including game specific DLLs. I have NO idea why developers insist on
> putting game specific DLLs in global locations.
Because when push comes to shove, Windows is *still* just DOS - it still
requires a PATH environment variable of ";" seperated directory names to
search - in fact, with the latest versions of Windows, Microsoft is
disparaging the idea of putting your DLL's into the system directory, but
they don't give adequate documentation or support of the API's required to
insert directories into the search path.
Putting DLL's next to the application that Joe User has to "click to start"
makes them a candidate for Joe Jr to trash them (actually, its more likely
the reverse).
There *are* registry tricks you can do to auto-force directories into the
search path, but then there are known bugs where if the path gets too long,
it all goes *poof*.
I believe that Application Manifests give you scope to have explicit path
specs, but that means you need to *write* those at install time and that
precludes moving things around.
> > [a] One can have many independent instances of the application on a
> > single machine, each with different preferences;
>
> That's great, except in many cases most users don't like/want/know
> about that.
Actually you *can't* have many independent instances of an application if
you are going to respond to double-clicks on a document. This is the part
that I feel hasn't been picked up on by developers, and I think its probably
because no-one wants to admit that Apple's *LISA* did these things better
than anyone else. Documents, and Document Templates are whats important,
not applications.
Why not have your preferences as the main *ICON* (ie, file) you click to to
enter your game? Feel free to stick it where you like, copy it around if
you like, but understand that its your config.
For a better user experience, you should do the same with Save Games, and
they should have a soft-pointer internally to the preferences document so
that you can restore the users state when they click on this DOCUMENT.
Of course, on Windows, this means needing unique file types (since thats how
the registry maps files to apps), but on MacOS it works beautifully.
The truly innovative could, however, write a tiny app that functioned as a
LAUNCHER, that stored the preferences back into itself as resources, and
passed values on perhaps through environment variables, a command-line
option or a temporary file.
Sure, you can't read them with a text editor, but its meets the
zero-registry-config requirement, its not unreasonable to assume that the
"prefs file be writable", etc...
(But, of course, it makes Brian's life a helluva lot harder to write a
generic prefs class ;-)
Jeff Laing <je...@sp...>
----------------------------------------------------------------------------
--
A complex system designed from scratch never works and cannot be patched up
to
make it work. You have to start over, beginning with a working simple
system.
-- J Gall. "Systemantics: How systems work and how they
fail"
|
|
From: Dan T. <da...@ar...> - 2003-12-04 23:38:33
|
> Because when push comes to shove, Windows is *still* just DOS - it still > requires a PATH environment variable of ";" seperated directory names to > search - in fact, with the latest versions of Windows, Microsoft is > disparaging the idea of putting your DLL's into the system directory, but > they don't give adequate documentation or support of the API's required to > insert directories into the search path. Hmm.. Sooo.. you can't do something like LoadLibrary(MyExeLocation + \\MyLibrary.dll); ?? > Putting DLL's next to the application that Joe User has to "click to start" > makes them a candidate for Joe Jr to trash them (actually, its more likely > the reverse). Only if he's an admin(which is the root of so many problems..), and if he is, he can screw up many more things. > There *are* registry tricks you can do to auto-force directories into the > search path, but then there are known bugs where if the path gets too long, > it all goes *poof*. > > I believe that Application Manifests give you scope to have explicit path > specs, but that means you need to *write* those at install time and that > precludes moving things around. Maybe its my primarily windows upbringing, but I still don't see how that affects anything when your library is in your executable path. > Actually you *can't* have many independent instances of an application if > you are going to respond to double-clicks on a document. This is the part > that I feel hasn't been picked up on by developers, and I think its probably > because no-one wants to admit that Apple's *LISA* did these things better > than anyone else. Documents, and Document Templates are whats important, > not applications. > > Why not have your preferences as the main *ICON* (ie, file) you click to to > enter your game? Feel free to stick it where you like, copy it around if > you like, but understand that its your config. That's a fun idea, there. For the adventurous type, you could use the hash that email uses for binary attachments and shove it all into a human readable xml file. Could get big, though...(MD5, I think?). Might be fun to try out in someone's small puzzle type game. oo, oo... if you wanted real fun you could Zip the xml, so humans who wanted to read it would just WinZip it and life would be good. Hmmmm.. > For a better user experience, you should do the same with Save Games, and > they should have a soft-pointer internally to the preferences document so > that you can restore the users state when they click on this DOCUMENT. That, or shove it into the XML file as above. > Of course, on Windows, this means needing unique file types (since thats how > the registry maps files to apps), but on MacOS it works beautifully. Better go look up how MacOS works... > The truly innovative could, however, write a tiny app that functioned as a > LAUNCHER, that stored the preferences back into itself as resources, and > passed values on perhaps through environment variables, a command-line > option or a temporary file. That'd be a fun SourceForge project I bet. > (But, of course, it makes Brian's life a helluva lot harder to write a > generic prefs class ;-) Poor Brian. He raises the Noble Cause of a generic preferences class, and we go off on all sorts of random stuff. -Dan |
|
From: Andras B. <bn...@ma...> - 2003-12-05 18:02:46
|
How about using delayed dll loading together with SetDllDirectory?? andras Friday, December 5, 2003, 12:19:08 AM, Jeff Laing wrote: > Because when push comes to shove, Windows is *still* just DOS - it still > requires a PATH environment variable of ";" seperated directory names to > search - in fact, with the latest versions of Windows, Microsoft is > disparaging the idea of putting your DLL's into the system directory, but > they don't give adequate documentation or support of the API's required to > insert directories into the search path. |
|
From: Jeff L. <je...@SP...> - 2003-12-05 05:28:06
|
> I agree with Brian; I want to be able to delete an application > directory (or perhaps one day it will be an archive object) and > have it gone -- without the operating system being involved in > anything other than a file deletion operation. whereas I want to be able to delete the application (the hundreds of MB) but keep my save games and keystroke preferences so that in six months time when I load the game back (as I did recently with Quake), its all still there. You are *not* going to keep everyone happy in this space. > On the subject of multiple instances of an application versus the > ability to double-click to open documents... Okay, this feature > would require a list of file extensions and paths to associated > applications, which I assume is currently found in the Registry. > [snip] > Microsoft may have used something called a Registry file for > this purpose I have to admit, this sounded spookily like you don't know how Windows works at all, which sort of skews the value of some of the opinions being offered. (End of unintended offense) > As far as I'm concerned, this is not compromising my philosophy. > The window system is an application with its own "preferences", > such as what application to use to open a given file extension. Actually, its the Explorer or more correctly the "Windows Shell" that has this preference, but other applications can and do look into that space, a big advantage to having a semi-wellknown globally readable repository/format for your preferences. (Again, in our non-game application we do exactly this - sometimes we need to mess with another app, and we don't really want to know where its been installed, we just ask Windows "who would open this document type if we double-clicked on it" and it gives us back the full pathname to the appropriate app. We don't launch it, we just exploit the fact that we found it without having to deal with searching file systems for filenames that are different depending on native language, etc) > Microsoft may have used something called a Registry file for > this purpose -- but I don't see why all other applications on > the computer should be considered subordinate (in the sense of > "being part of") to the Microsoft window system application. Not subordinate. Consistent with. Consistency is a good thing when you are trying to work out whats gone wrong with someone elses app. If they do the same thing as everyone else, they are a lot easier to debug. > Somehow I doubt there are many fathers who are running serious system-level > multi-user setups at home. More likely everyone just uses the same login > and shares the same clutter. Sure, it's still multi-user, as in "used by > multiple people", but not at the registry level. Hmmm, I'd invite you to my place, or my brothers, but we're probably a bit far away. I definitely have multi-user setups which are intended precisely to stop the 5 year olds from messing stuff up. In my brothers case, its our mother the 65 year old that he protects the system from. Now, we happen to be the computer literate ones in the family - there is absolutely no reason why you can't swap father/child in any of this discussion, as is the case with my brother. He does the admin, and the parents use a "nice safe, difficult to break" system. > In fact, I bet that going forward that higher security privileges and > multiuser configurations will become more important. One of the most > common sources of spyware/virii are random things that kids download > off the internet -- I'm amazed how many people will "click here" just > because something says "CLICK HERE!" Ask a security zealot what they think of MacOSX these days - just about anything downloaded from the net says "ok, authorise me as root" without giving users a clue about what they are actually allowing. > Originally I was thinking it would be a binary file format, strictly > because I wanted the ability to serialize raw binary data "just in > case". Now you could make a valid argument that you could always > convert to text, i.e. 3.14 becomes "3.14", but maybe you don't want to > suffer a data conversion loss or something, I dunno. > > Point being that I'd rather not dictate policy if I don't have to. You need to make your mind up on whether you think prefs files are movable across architecture or not? If they are, then float-format will kill you, as will endianness in integers. Personally, I think that floating point *prefs* are going to be pretty damn weird to start with, and you need to keep in mind that that information is entered either as text (ie, in an EDIT control), or by tweaking a scrollbar. In either case, the user can't really complain about that last bit that might go wrong in the ASCII->FLOAT conversion. 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. |
|
From: Brian H. <ho...@py...> - 2003-12-05 05:48:40
|
> You need to make your mind up on whether you think prefs files are > movable across architecture or not? Oh, they definitely are. Sharing prefs is something I would hate to rule out. > If they are, then float-format > will kill you, as will endianness in integers. IEEE-754 floats are pretty standard, and my lib handles all the endianess stuff just fine. Of course, for raw binary export, it's up to the application to make sure that it does the right thing if serializing structs (which it shouldn't be doing, but hey, I can't control the app). > Personally, I think that floating point *prefs* are going to be > pretty damn weird to start with, and you need to keep in mind that > that information is entered either as text (ie, in an EDIT > control), or by tweaking a scrollbar. In either case, the user > can't really complain about that last bit that might go wrong in > the ASCII->FLOAT conversion. Agreed, that just happened to be the first example I could think of. > 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. Sure, it's not that bad, but it's also a lot of overhead for not much in return. Nothing beats Windows-style INI files for parsing simplicity goodness. =3D) Brian |
|
From: Tom S. <to...@pi...> - 2003-12-05 06:47:47
|
> -----Original Message----- > 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. ...and that would most likely be followed by use Lua. =) Tom |
|
From: Brian H. <ho...@py...> - 2003-12-16 04:00:05
|
Please ignore. |
|
From: Brian H. <ho...@py...> - 2003-12-16 04:14: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 |
|
From: J C L. <cl...@ka...> - 2003-11-19 13:57:15
|
On Wed, 19 Nov 2003 06:43:25 -0500 Brian Hook <ho...@py...> wrote: > For example, on the Cray T8, ALL types are 64-bits except for char I > believe. The Crays have several optional compilation environments. In one of them sizeof(char)==sizeof(short)==sizeof(int)==sizeof(long)==1. The other compilation environments use more typical 64bit type size distributions. -- 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. |
|
From: J C L. <cl...@ka...> - 2003-11-19 14:05:56
|
On Tue, 18 Nov 2003 13:07:29 -0500 Brian Hook <ho...@py...> wrote: > I've been working on a portable open source "harness", a header file > that (ideally) handles a lot of configuration crap for most people. > You know what I mean, the standard stuff like defining the proper DLL > export signature, sized types, etc. I'm still dismayed every time I > see some open source library doing: > #if WHATEVER typedef unsigned int my_u32_t; typedef long long > my_i64_t; #endif You are familiar with glibC's inttypes.h and stdint.h? They would seem to cover this space moderately well. -- 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. |
|
From: Brian H. <ho...@py...> - 2003-11-19 16:49:21
|
On Wed, 19 Nov 2003 09:05:54 -0500, J C Lawrence wrote: > You are familiar with glibC's inttypes.h and stdint.h? They would > seem to cover this space moderately well. Yes, unfortunately they are not universally available. If you're using strictly GCC then that would work, but then again, you wouldn't need POSH either -- a lot of POSH's implicit goal is to make stuff portable cleanly to older versions of CodeWarrior and MSVC++. Brian |
|
From: J C L. <cl...@ka...> - 2003-11-20 04:19:10
|
On Wed, 19 Nov 2003 11:49:22 -0500 Brian Hook <ho...@py...> wrote: > On Wed, 19 Nov 2003 09:05:54 -0500, J C Lawrence wrote: >> You are familiar with glibC's inttypes.h and stdint.h? They would >> seem to cover this space moderately well. > Yes, unfortunately they are not universally available. True. However they address and solve most of the basic space in a well defined and thoroughly implication-understood way. If you're license is LGPL friendly it would seem to make sense to take that as a starting point. -- 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. |
|
From: J C L. <cl...@ka...> - 2003-12-02 16:43:01
|
On Tue, 2 Dec 2003 01:59:30 -0500 Brian Hook <ho...@py...> wrote: > Everyone seems like they have to write their own portable > preferences/registry wrapper. I've got one that I hacked up, and I'm > currently in the process of refactoring it and will make it open > source. I did a little STL-based thang which reads and writes a map of "<StanzaName>:Token" -> <value> to and from a text file where the value is a multi-value which transparently handles strings, floating point, integers etc in the same type. Very nice, simple, and easy to use. Load populates the map and everything else is an STL map reference. -- 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. |
|
From: Brian H. <ho...@py...> - 2003-12-02 17:05:59
|
On Tue, 02 Dec 2003 11:42:59 -0500, J C Lawrence wrote: > On Tue, 2 Dec 2003 01:59:30 -0500 > I did a little STL-based thang which reads and writes a map of > "<StanzaName>:Token" -> <value> to and from a text file where the > value is a multi-value which transparently handles strings, > floating point, integers etc in the same type. Very nice, simple, > and easy to use. Load populates the map and everything else is an > STL map reference. Except it uses STL =3D) (M-x skip-C++-and-STL-argument-mode) I'm using ANSI C since it is, by far, the most plug-and-play language for cross-platform work. Brian |
|
From: J C L. <cl...@ka...> - 2003-12-02 17:41:36
|
On Tue, 2 Dec 2003 12:05:59 -0500 Brian Hook <ho...@py...> wrote: > On Tue, 02 Dec 2003 11:42:59 -0500, J C Lawrence wrote: >> I did a little STL-based thang which reads and writes a map of >> "<StanzaName>:Token" -> <value> to and from a text file where the >> value is a multi-value which transparently handles strings, floating >> point, integers etc in the same type. Very nice, simple, and easy to >> use. Load populates the map and everything else is an STL map >> reference. > Except it uses STL =3D) True, except that it would be easy enough to move to any of the associative array implementations. There's nothing marrying it to STL. > I'm using ANSI C since it is, by far, the most plug-and-play language > for cross-platform work. I also greatly prefer C, but that was not the political choice at that time. Were I do go the C route I'd likely end up with something very similar but based on *dbm and one of the varray implementations. -- 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. |
|
From: J C L. <cl...@ka...> - 2003-12-05 15:15:21
|
On Thu, 4 Dec 2003 22:47:06 -0500
Brian Hook <ho...@py...> wrote:
> Originally I was thinking it would be a binary file format, strictly
> because I wanted the ability to serialize raw binary data "just in
> case". Now you could make a valid argument that you could always
> convert to text, i.e. 3.14 becomes "3.14", but maybe you don't want to
> suffer a data conversion loss or something, I dunno.
I wouldn't use a configuration system that didn't use flat text files,
but then I'm religious in that regard.
> foo=3D129ABC55
I ended up electing to use a leading typing string that identified the
encoding of the rest of the value. As such I had decimal, hex, a
variety of true/false forms, quoted strings, and ${value} substitution.
With the exception of the latter, which I did for pure geek value, they
all turned out to be absurdly useful.
--
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.
|
|
From: Brett B. <res...@ga...> - 2003-12-16 04:22:44
|
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 |
|
From: Brian H. <ho...@py...> - 2003-12-16 04:29:17
|
> 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 |
|
From: Dan T. <da...@ar...> - 2003-12-16 04:45:44
|
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 |
|
From: Alen L. <ale...@cr...> - 2003-12-16 08:21:44
|
> 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 |
|
From: Jorrit T. <Jor...@uz...> - 2003-12-16 08:38:40
|
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, |
|
From: Alen L. <ale...@cr...> - 2003-12-16 11:42:06
|
> 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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X