gamedevlists-general

Re: [GD-General] serial numbers

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

On Wed, 28 May 2003 18:11:08 -0400 
Brian Hook <ho...@py...> wrote:

>> If you're generating keys over the net, then you're likely going
>> to have their email address, so use that instead of their name. 
>> It's guaranteed to be unique.

> It's also guaranteed to change.

And in the case of a role address is not guaranteed to be unique.

-- 
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: [GD-General] A portable preferences library

[Pablo <pe...@te...>]

=2D----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

=46rom: Brian Hook <ho...@py...>
> Preference objects can be opened either system-wide (corresponding to
> HKEY_LOCAL_MACHINE on Windows, "/Library" on OS X, "/usr/local/share"
> on Linux) or locally (corresponding to HKEY_CURRENT_USER on Windows,
> "~/Library" on OS X, and "~" on Linux).

	I wonder if /var/lib isn't a better place to store such a data, since many=
=20
people mount their /usr filesystems in read-only mode.
	A clear example for this can be seen in the Mozilla package for Debian. Th=
e=20
original version of Mozilla stores everything in /usr/local/mozilla, while=
=20
the Debian package puts global configuration files in /var/lib/mozilla and=
=20
creates the appropiate symlinks so the application can find its files.

	Greetings.
=2D --=20
Pablo Brasero
http://www.pablobm.com
mailto:pab...@hi...
jabber:otn...@ja...
Usuario registrado de Linux n=FAmero 286.361
=2D----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/zna5J8SVBd7KWfwRAhD+AKDFjnbaru6Lj/zP1Qhco7IufOFEtQCdHAoH
ikAeE+HbcuAbZoPW+yCWZTs=3D
=3DVaKt
=2D----END PGP SIGNATURE-----

RE: [GD-General] A portable preferences library

[Andrew G. <ag...@cl...>]

>> I think multi-user systems is an antiquated concept. 

You're joking right?

Also your scheme falls down the minute somebody without write access to the
games folder attempts to play it. Something that's pretty common these days
where Dad has to install the games little Johnny wants to play on the family
PC. I'd be surprised if your approach makes it through QA of any publisher
worth their salt.

I agree the registry isn't the place to store the data, but neither is the
game install folder. Anything you need to save from your game and that
doesn't ask the user for a path should go into the whatever's returned by
SHGetFolderLocation(.., CSIDL_APPDATA, ..);


_____________________________________
andrew grant | programmer | climax brighton
ag...@cl... - www.climax.co.uk






> -----Original Message-----
> From: Colin Fahey [mailto:cp...@ea...] 
> Sent: 04 December 2003 20:42
> To: gam...@li...
> Subject: Re: [GD-General] A portable preferences library
> 
> 
> 2003 December 4th
> Thursday
> 
> I have used the following scheme for storing user preferences 
> for an application:
> 
> [1] A plain text file in the same directory as the executable,
>        with the extension *.txt rather than something else (like
>        *.ini);
> 
> [2] The application, when launched, can determine the path of its
>       executable file, and thus the location of the corresponding
>       user preferences text file;
> 
> [3] All aspects of reading the user preferences text file are 
>       fault-tolerant; re-ordering, adding, removing fields will
>       have the least possible effect -- and field values are 
>       similarly checked and clipped to sane limits.
> 
> Security of the preferences is not an issue for my use of this scheme.
> 
> Benefits of this scheme:
> 
>   [a] One can have many independent instances of the application
>         on a single machine, each with different preferences;
> 
>   [b] The user can edit preferences if the application malfunctions,
>         which is impossible in a scheme where the application itself
>         is the only entity that can manipulate the preferences file;
> 
>   [c] Users can send or receive preferences files, or disucss
>         specific named settings, via e-mail or web pages;
> 
>   [d] Settings in the preferences file can correspond to an
>         application's scripting system -- so that the preferences
>         file is nothing more than a batch of scripting commands
>         that can otherwise be entered at run-time in the 
>         application itself (as in a console window for a video
>         game);
> 
>   [e] Settings persist after clean install of operating system;
> 
>   [f] Application and settings can be stored on a CD-ROM or
>         portable disk or flash-memory device, and one can 
>         take it to someone else's computer and operate the 
>         application without doing an "installation" or 
>         polluting their computer with any files whatsoever;
>         (I bring my prototype applications to a friend's house
>         for demonstration on my keychain USB memory device,
>         and execute directly from the keychain!)
> 
> Basically, I'm a strong believer of the settings following 
> the application around.  I think the old MacIntosh operating 
> system hid a kind of directory system behind the application 
> icon -- with the "resource fork" and "data fork", which was a 
> pretty good idea because it allowed data associated with a 
> program to be bound to the program.  Thus, moving or copying 
> the icon would assure that all settings and data moved with 
> it. It was a nice abstraction that simplified the notion of 
> "application" and reduced confusion when moving it around.
> 
> Maybe I'm hard-core, but I think everything an application 
> needs to operate, short of the absolutely guaranteed 
> resources of the operating system, should be packaged with 
> the application -- and totally portable.  I should be able to 
> run any application on anyone's computer from my keychain 
> memory device, without adding any files to their computer!
> 
> I think multi-user systems is an antiquated concept.  But if
> I must support multiple users of a single application (as 
> opposed to each user installing his or her own copy of the 
> application), then individual preferences files can be stored 
> with the application. "preferences_bob.txt", 
> "preferences_joe.txt", etc.  Putting these preferences 
> anywhere else but with the application leads to 
> potential pollution that might never go away.  Lots of 
> irresponsible developers don't do a good job of 
> un-installation -- or somehow the application disappears from 
> the computer without un-install ever happening, leaving tons 
> of scattered junk behind.
> 
> I always thought the Windows registry was a disaster; it 
> encouraged people to centralize critical information, and it 
> has been a source of confusion and annoyance for users.  
> Protecting the integrity of this single trash heap is silly.
> 
> Okay, I sympathize with the idea that putting everything in 
> one place somehow seems more organized.  I dislike the idea 
> of things being scattered around.  But I think it's perfectly 
> good to put things in self-contained bundles that do not rely 
> on any centralized thing or on scattered things.  It's very clean.
> 
> I think rather than pushing itself upon one's computer (like 
> a formal installation procedure), applications should be 
> passive and the 
> operating system should instead scan for applications upon 
> boot-up. Thus, the "Start" menu is populated at boot time and 
> is 100% in sync with available applications.  Applications 
> can contain 
> preferences about placement in the "Start" menu hierarchy, 
> much like an application can propose its own icon.  The key 
> is to eliminate the idea of "installation".
> 
> Okay, some of these ideas are radical, but I just wanted to 
> share my own thoughts about preferences files.
> 
> --- Colin
> 
> cp...@ea...
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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: [GD-General] A portable preferences library

[Crosbie F. <cr...@cy...>]

> From: Andrew Grant
> Also your scheme falls down the minute somebody without write
> access to the
> games folder attempts to play it. Something that's pretty
> common these days
> where Dad has to install the games little Johnny wants to
> play on the family
> PC. I'd be surprised if your approach makes it through QA of
> any publisher worth their salt.

You could compare it with Blizzard's requirement for Warcraft III players to
be administrators (on W2K, etc.).

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

[Dan T. <da...@ar...>]

I'd say it stumbles, but doesn't *quite* fall down. Since with Colin's
scheme you can move games/apps around as entities freely, you could (in
theory), just move the whole thing somewhere where little johhny *does* have
access. Actually the windows LUA compatibility stuff under XP does this
exact thing in the registry to anyone who tries to write to HKLM - just
copies it to HKCU and lets them do whatever they want to it.

-Dan

----- Original Message ----- 
From: "Andrew Grant" <ag...@cl...>
To: <gam...@li...>
Sent: Thursday, December 04, 2003 1:14 PM
Subject: [email] RE: [GD-General] A portable preferences library


> >> I think multi-user systems is an antiquated concept.
>
> You're joking right?
>
> Also your scheme falls down the minute somebody without write access to
the
> games folder attempts to play it. Something that's pretty common these
days
> where Dad has to install the games little Johnny wants to play on the
family
> PC. I'd be surprised if your approach makes it through QA of any publisher
> worth their salt.
>
> I agree the registry isn't the place to store the data, but neither is the
> game install folder. Anything you need to save from your game and that
> doesn't ask the user for a path should go into the whatever's returned by
> SHGetFolderLocation(.., CSIDL_APPDATA, ..);
>
>
> _____________________________________
> andrew grant | programmer | climax brighton
> ag...@cl... - www.climax.co.uk
>
>
>
>
>
>
> > -----Original Message-----
> > From: Colin Fahey [mailto:cp...@ea...]
> > Sent: 04 December 2003 20:42
> > To: gam...@li...
> > Subject: Re: [GD-General] A portable preferences library
> >
> >
> > 2003 December 4th
> > Thursday
> >
> > I have used the following scheme for storing user preferences
> > for an application:
> >
> > [1] A plain text file in the same directory as the executable,
> >        with the extension *.txt rather than something else (like
> >        *.ini);
> >
> > [2] The application, when launched, can determine the path of its
> >       executable file, and thus the location of the corresponding
> >       user preferences text file;
> >
> > [3] All aspects of reading the user preferences text file are
> >       fault-tolerant; re-ordering, adding, removing fields will
> >       have the least possible effect -- and field values are
> >       similarly checked and clipped to sane limits.
> >
> > Security of the preferences is not an issue for my use of this scheme.
> >
> > Benefits of this scheme:
> >
> >   [a] One can have many independent instances of the application
> >         on a single machine, each with different preferences;
> >
> >   [b] The user can edit preferences if the application malfunctions,
> >         which is impossible in a scheme where the application itself
> >         is the only entity that can manipulate the preferences file;
> >
> >   [c] Users can send or receive preferences files, or disucss
> >         specific named settings, via e-mail or web pages;
> >
> >   [d] Settings in the preferences file can correspond to an
> >         application's scripting system -- so that the preferences
> >         file is nothing more than a batch of scripting commands
> >         that can otherwise be entered at run-time in the
> >         application itself (as in a console window for a video
> >         game);
> >
> >   [e] Settings persist after clean install of operating system;
> >
> >   [f] Application and settings can be stored on a CD-ROM or
> >         portable disk or flash-memory device, and one can
> >         take it to someone else's computer and operate the
> >         application without doing an "installation" or
> >         polluting their computer with any files whatsoever;
> >         (I bring my prototype applications to a friend's house
> >         for demonstration on my keychain USB memory device,
> >         and execute directly from the keychain!)
> >
> > Basically, I'm a strong believer of the settings following
> > the application around.  I think the old MacIntosh operating
> > system hid a kind of directory system behind the application
> > icon -- with the "resource fork" and "data fork", which was a
> > pretty good idea because it allowed data associated with a
> > program to be bound to the program.  Thus, moving or copying
> > the icon would assure that all settings and data moved with
> > it. It was a nice abstraction that simplified the notion of
> > "application" and reduced confusion when moving it around.
> >
> > Maybe I'm hard-core, but I think everything an application
> > needs to operate, short of the absolutely guaranteed
> > resources of the operating system, should be packaged with
> > the application -- and totally portable.  I should be able to
> > run any application on anyone's computer from my keychain
> > memory device, without adding any files to their computer!
> >
> > I think multi-user systems is an antiquated concept.  But if
> > I must support multiple users of a single application (as
> > opposed to each user installing his or her own copy of the
> > application), then individual preferences files can be stored
> > with the application. "preferences_bob.txt",
> > "preferences_joe.txt", etc.  Putting these preferences
> > anywhere else but with the application leads to
> > potential pollution that might never go away.  Lots of
> > irresponsible developers don't do a good job of
> > un-installation -- or somehow the application disappears from
> > the computer without un-install ever happening, leaving tons
> > of scattered junk behind.
> >
> > I always thought the Windows registry was a disaster; it
> > encouraged people to centralize critical information, and it
> > has been a source of confusion and annoyance for users.
> > Protecting the integrity of this single trash heap is silly.
> >
> > Okay, I sympathize with the idea that putting everything in
> > one place somehow seems more organized.  I dislike the idea
> > of things being scattered around.  But I think it's perfectly
> > good to put things in self-contained bundles that do not rely
> > on any centralized thing or on scattered things.  It's very clean.
> >
> > I think rather than pushing itself upon one's computer (like
> > a formal installation procedure), applications should be
> > passive and the
> > operating system should instead scan for applications upon
> > boot-up. Thus, the "Start" menu is populated at boot time and
> > is 100% in sync with available applications.  Applications
> > can contain
> > preferences about placement in the "Start" menu hierarchy,
> > much like an application can propose its own icon.  The key
> > is to eliminate the idea of "installation".
> >
> > Okay, some of these ideas are radical, but I just wanted to
> > share my own thoughts about preferences files.
> >
> > --- Colin
> >
> > cp...@ea...
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
> >
>
>
> -------------------------------------------------------
> 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: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

> I agree the registry isn't the place to store the data, but neither
> is the game install folder. Anything you need to save from your
> game and that doesn't ask the user for a path should go into the
> whatever's returned by SHGetFolderLocation(.., CSIDL_APPDATA, ..);

So what's the accepted wisdom now on use SHGetSpecialFolderLocation() 
vs. GetWindowsDirectory(), GetSystemDirectory() and getenv( "HOMEPATH" 
)?

Brian

Re: [GD-General] A portable preferences library

[Brett B. <res...@ga...>]

Brian,
Are you thinking the preferences library will be portable enough to work
for consoles too? Specifically I'm thinking how I could interface this
to the memory card sub-systems on GameCube and PS2. We already have a
preferences implementation for consoles we built by implementing an ANSI
file system compatible interface over the memory card sub-system and it
works pretty well, and the idea we could just have one preferences
library is compelling :-)

Also, I assume most people don't read/write preferences often, but I was
wondering if your library would have the concept of loading all the
prefs in the beginning, then reading/writing them in memory, then
finally flushing them back to non-volatile storage when done?  The
reason for this is that memory cards have a limited lifespan and are
slow to access anyway, so being able to read/write to storage only once
is a good thing.

Brett

Re: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

> Are you thinking the preferences library will be portable enough to
> work for consoles too?

No reason for it not to.  

The general architecture is that you open and close prefs, and when 
you open you can specify if you want them user-level, system-level, 
and whether you prefer a filesystem implementation instead of a 
"native" (Win32 registry and OS X Preferences) implementation.

Obviously, I'm not going to write a PS2 or GC implementation, but the 
API is so simple that layering it should be trivial.

You query a value using an API like PrefLib_GetFloat( "name", &f ), 
etc.  These then dispatch into a portable thunker that converts to a 
canonical little-endian format, and then call the system dependent 
PrefLib_WriteBinary() implementation.

My Win32 implementation is complete, and I'm about 50% complete with 
the filesystem implementation which, in theory, should just work on 
Linux.

To make this manageable, I'm not going to support things like nested 
keys or arbitrarily large data chunks (i.e. movie files, screenshots) 
although I won't prevent people from doing the latter.

> Also, I assume most people don't read/write preferences often, but
> I was wondering if your library would have the concept of loading
> all the prefs in the beginning, then reading/writing them in
> memory, then finally flushing them back to non-volatile storage
> when done?  The reason for this is that memory cards have a limited
> lifespan and are slow to access anyway, so being able to read/write
> to storage only once is a good thing.

Interesting that you should bring this up, because I had to deal with 
this last night.

There's a bit more bookkeeping to doing a purely in-memory system, but 
there are also a couple ugly pitfalls:

1.  Multiple processes accessing the same pref file can clobber each 
other.

2.  The need to flush periodically so that if the app terminates 
unexpectedly, any preferences are not lost due to the crash.

For these reasons, the file system implementation I'm doing is 
actually slow but safe.  Every access forces a file read/parse, modify 
in place, and then a write back out.  Yes, in theory that's amazingly 
slow, but I expect that A.) it won't be that big a problem since 
developers rarely thrash preferences and b.) if it is a problem, I 
expect that developers will end up caching values in memory anyway.

All that said, a memory card implementation could easily cache all the 
data behind the scenes and only flush when PrefLib_ClosePrefs() is 
called.

Brian

RE: [GD-General] A portable preferences library

[Garett B. <gt...@st...>]

// Andrew grant wrote in response to Colin Fahey:
//
// I'd be surprised if your approach makes it through
// QA of any publisher worth their salt.

	Colin's approach is exactly what is used by Quake, Quake2, Quake3,
Half-Life, and by the transitive property, Counter-Strike.  Another popular
game using this technique is Battlefield 1942.

	Personally, I find Colin's suggestion to be a perfectly acceptable means of
managing preferences for a game.  I particularly like the ability to keep a
variety of preference files onhand.  More than one per user can be handy if
you are experimenting with some scripted input behavior in your spare time
but don't want to lose your competition config.

	Now, I'm not sure this is true, but I've heard that Counter-Strike is
currently the most popular online FPS, and that 1942 is second most popular.
And yet you exclude Activision and EA from your set of all "publishers worth
their salt".

// Something that's pretty common these days where
// Dad has to install the games little Johnny wants
// to play on the family PC.

	Ok, this makes me feel a little dumb.  I've been trying to set up a
restricted access user on a Win2k box at work, and no matter what I
disallow, I still can't figure out how to prevent the user from installing
stupid crap from the internet.

	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.

	So, I'm guessing that the multi-user advantages of the registry-stored
preferences are likely used only by an elite few with some serious IT
skills.  Another example of 99% in, 1% out.  I'm partial to 1942's handy
built-in multiple profiles dialog.  I suppose you could always use a single
registry key to set a default profile for each system-level user.

	Apologies in advance for the rants.

Curious,
Garett

Re: [GD-General] Unicode

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

On Wed, 19 Nov 2003 11:58:18 -0600 
Garett Bass <gt...@st...> wrote:

> Which leaves me wondering, how do you figure out where one character
> ends and the next begins?

Recursive descent.

-- 
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: [GD-General] Unicode

[<cas...@ya...>]

Hi,

there seems to be some confusion around Unicode, that I will try to clear up.
The Unicode character set is a standard that provides different encoding
formats. 

There are two different kind of encodings, some represent the full Unicode
character set and others don't. The "loosless" formats are utf8, utf16 and
utf32. utf8 and utf16 are multibyte charcter sets, that means that a
character can be represented by multiple bytes. For example, in utf8 a
character may be take 1, 2, 3, up to 6 bytes. The nice thing about utf8 is
that it does not contain embedded zeros, so you can still use strlen, strcpy,
strdup, etc. However, in this case strlen does not provide the lenght but the
size of the string. 

utf16 usually takes a word, however some characters need two words. The
second word is usually called surrogate and is only needed by some strange
characters, usually old languages that are not used anymore. Windows NT and
Java only support a subset of unicode called UCS2, that is utf16 without the
surrogate. Windows XP on the other side is supposed to support surrogates.

Finally, the last encoding is utf32 (or ucs4) that uses a 32bits and
represents the full unicode character set.

Which representation you choose mainly depends on your application. Web
applications usually use utf8, because you can reuse the existing code and
most of the net is written using ASCII characters, so utf8 turns out to be
the most efficient. I currently use ucs2 internally in my applications, and
that's probably what most games will need.

This is an oversimplification, so check this out for more info:
http://www.unicode.org/faq/

Hope that helps,

--
Ignacio Castaño
cas...@ya...


___________________________________________________
Yahoo! Messenger - Nueva versión GRATIS
Super Webcam, voz, caritas animadas, y más...
http://messenger.yahoo.es

Re: [GD-General] Feedback wanted on POSH

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

On Wed, 19 Nov 2003 11:13:16 -0600 
Garett Bass <gt...@st...> wrote:

> I'm not sure I understand what you mean by "Unsized" here.  If you're
> defining char8 to be uint8, then its size is 8 bits.

Ahem.  Bytes are not required to be 8 bits, they merely usually are.

> Not being too familiar with unicode, I find this confusing.  I thought
> that "Unicode" was a multibyte format with no set number of bytes per
> character, ie. a single asian character may be represented by four
> bytes while the subsequent character is represented by two.

Correct, but there is a max width and in order to be able to handle
indexed aggregates like arrays when in non-string form they are assumed
to be of constant width.  Its in string form that they are packed.

-- 
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: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

> So, I'm guessing that the multi-user advantages of the registry-
> stored preferences are likely used only by an elite few with some
> serious IT skills.

this is true, but it's still there.  Even if it's just 1% of users, if 
your game sells 200K units, that's 2000 users that will run into 
problems with your game.  

That gets amplified pretty seriously.  Even our own piddly little 
puzzle games ran into this.  

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

Brian

RE: [GD-General] A portable preferences library

[Garett B. <gt...@st...>]

//// I wrote:
////
//// So, I'm guessing that the multi-user advantages
//// of the registry-stored preferences are likely
//// used only by an elite few with some serious
//// IT skills.

// Brian Hook wrote:
//
// this is true, but it's still there.  Even if it's
// just 1% of users, if your game sells 200K units,
// that's 2000 users that will run into problems
// with your game.

Actually, I'm suggesting that those 2000 users are the only ones who will
benefit from registry-based user-specific profiles, whereas a system like
that in 1942 lets you choose one of many profiles no matter which user you
are.

If you are planning to write your registry prefs into HKLU, then you are
choosing to cause trouble for someone who suddenly wonders where their prefs
went after they switch from their admin account to their user account.  This
is a problem that using the registry can cause.  I, agree with Colin Fahey:

// The window system is an application with its own
// "preferences".  Microsoft...used [the] Registry...
// for this purpose.
// Application-specific data belongs with the
// application, not with the window manager
// application.

I just don't see how the Registry is in any way an analogue of a memory card
or application bundle.  Just the opposite, it is an increasingly obscure
database bloated with junk data that is very difficult to give a thorough
spring cleaning.

Regards,
Garett

RE: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

Okay, so back to the actual file format....

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.

So instead of doing a UUEncode, I could do an inefficient translation 
to ASCII by simply converting directly to ASCII.  It would double in 
size if I used hex, but it would still be editable in a text editor.

So if you need to write out 0x12 0x9A 0xBC 0x55 to the key "foo" then 
the file foo.pref would have:

foo=3D129ABC55

Not efficient, but it works.

Any obvious problems going this route?

Brian

RE: [GD-General] A portable preferences library

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

> Okay, so back to the actual file format....
> 
> 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.
> 
> So instead of doing a UUEncode, I could do an inefficient translation 
> to ASCII by simply converting directly to ASCII.  It would double in 
> size if I used hex, but it would still be editable in a text editor.
> 
> So if you need to write out 0x12 0x9A 0xBC 0x55 to the key "foo" then 
> the file foo.pref would have:
> 
> foo=129ABC55
> 
> Not efficient, but it works.

If you are really opposed to using XML - after all, why would a "simple"
preferences library need a big bad XML parser (answer: you'll likely need
an XML parser in the game anyway...), you can play the revolutionary by
using YAML:

http://www.yaml.org

quote from the site:

YAML(tm) (rhymes with "camel") is a straightforward machine parsable data serialization format designed for human readability and
interaction with scripting languages such as Perl and Python. YAML is optimized for data serialization, configuration settings, log
files, Internet messaging and filtering. YAML(tm) is a balance of the following design goals: 

YAML documents are very readable by humans. 
YAML interacts well with scripting languages. 
YAML uses host languages' native data structures. 
YAML has a consistent information model. 
YAML enables stream-based processing. 
YAML is expressive and extensible. 
YAML is easy to implement. 

RE: [GD-General] A portable preferences library

[<ma...@ch...>]

On Thu, 4 Dec 2003, Garett Bass wrote:

> // Andrew grant wrote in response to Colin Fahey:
> //
> // I'd be surprised if your approach makes it through
> // QA of any publisher worth their salt.
> 
> 	Colin's approach is exactly what is used by Quake, Quake2, Quake3,
> Half-Life, and by the transitive property, Counter-Strike.  Another popular
> game using this technique is Battlefield 1942.

Under Linux at least, q3 uses ~/.q3a/ to store things in. 

~ == $HOME btw.

Mads

-- 
Mads Bondo Dydensborg.                               ma...@ch...
We can argue this until the cows come home, but let's agree to compromise.
If you're right, you can say "told you so". If I'm right, I can say... well,
whatever Bill allows me to say. Fair enough?
                   - /. comment by Rogerborg on 2002.07.02 on MS Palladium

Re: [GD-General] A portable preferences library

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

On Thu, 4 Dec 2003 21:08:37 -0600
Garett Bass <gt...@st...> wrote:

> So, I'm guessing that the multi-user advantages of the registry-stored
> preferences are likely used only by an elite few with some serious IT
> skills.  Another example of 99% in, 1% out.  I'm partial to 1942's
> handy built-in multiple profiles dialog.  I suppose you could always
> use a single registry key to set a default profile for each
> system-level user.

Mozilla has a rather nice multi-user same account setup.  I've seen
quite a few non-technical homes setup with Mozilla and separate user
configurations.  It also has a rather decent divide between system level
configuration and defaults and per-user overrides.

--
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: [GD-General] A portable preferences library

[Andrew G. <ag...@cl...>]

Perhaps there are other reasons for that requirement (although I can't think
of them) but if that was the only one it smacks of a lack of planning. No
disrespect intended to anyone from Blizzard who's reading this ;)

Most developers won't even have that leeway anyway. The same as how back in
1999 not many developers other than id could get away with telling their
publisher they intended to release a game which required hardware T&L
support :)


_____________________________________
andrew grant | programmer | climax brighton
ag...@cl... - www.climax.co.uk





> -----Original Message-----
> From: Crosbie Fitch [mailto:cr...@cy...] 
> Sent: 04 December 2003 21:27
> To: gam...@li...
> Subject: RE: [GD-General] A portable preferences library
> 
> 
> > From: Andrew Grant
> > Also your scheme falls down the minute somebody without 
> write access 
> > to the games folder attempts to play it. Something that's pretty
> > common these days
> > where Dad has to install the games little Johnny wants to
> > play on the family
> > PC. I'd be surprised if your approach makes it through QA of
> > any publisher worth their salt.
> 
> You could compare it with Blizzard's requirement for Warcraft 
> III players to be administrators (on W2K, etc.).
> 
> 

RE: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

> back in 1999 not many developers other than id could get away with
> telling their publisher they intended to release a game which
> required hardware T&L support :)

For the record, Q3 did not require hardware T&L support.  id required 
working OpenGL drivers, that was it.

Brian

RE: [GD-General] A portable preferences library

[Andrew G. <ag...@cl...>]

To all intents and purposes, it required hardware T&L support.


_____________________________________
andrew grant | programmer | climax brighton
ag...@cl... - www.climax.co.uk




> -----Original Message-----
> From: Brian Hook [mailto:ho...@py...] 
> Sent: 04 December 2003 21:58
> To: gam...@li...
> Subject: RE: [GD-General] A portable preferences library
> 
> 
> > back in 1999 not many developers other than id could get away with 
> > telling their publisher they intended to release a game 
> which required 
> > hardware T&L support :)
> 
> For the record, Q3 did not require hardware T&L support.  id required 
> working OpenGL drivers, that was it.
> 
> Brian
> 
> 

RE: [GD-General] A portable preferences library

[Brian H. <ho...@py...>]

> 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

RE: [GD-General] A portable preferences library

[Andrew G. <ag...@cl...>]

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








> -----Original Message-----
> From: Brian Hook [mailto:ho...@py...] 
> Sent: 04 December 2003 21:57
> To: gam...@li...
> Subject: RE: [GD-General] A portable preferences library
> 
> 
> > I agree the registry isn't the place to store the data, but 
> neither is 
> > the game install folder. Anything you need to save from 
> your game and 
> > that doesn't ask the user for a path should go into the whatever's 
> > returned by SHGetFolderLocation(.., CSIDL_APPDATA, ..);
> 
> So what's the accepted wisdom now on use SHGetSpecialFolderLocation() 
> vs. GetWindowsDirectory(), GetSystemDirectory() and getenv( 
> "HOMEPATH" 
> )?
> 
> 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
> 

RE: [GD-General] A portable preferences library

[Tom S. <to...@pi...>]

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

RE: [GD-General] A portable preferences library

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

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

I believe Microsoft are working on something like "zero-install" games, where
the CD is just popped into the drive, and the game uses part of the HDD for
caching - but doesn't rely on it being preserved across runs, similar to what 
games use the Xbox HDD.