Thread: Re: [GD-General] Unicode (Page 2)
Brought to you by:
vexxed72
Menu
▾
▴
gamedevlists-general
|
From: Thatcher U. <tu...@tu...> - 2003-11-19 19:42:21
|
On Nov 19, 2003 at 07:55 +0100, Nicolas Romantzoff wrote: > > - MBCS: "Multi Byte Character Sets", using a variable number of > characters depending on the first one. > That's exactly the kind of things that drives me nuts: inventing a > stupid thing for badly engineered older things to continue working. But > hey, that's life. There, you cannot tell the size of a character, > however, the system is providing you with functions for that. > Basically you are ALWAYS pointing to the first byte of the character > (otherwise everything is broken). Given that byte, you can tell the size > of the character (mbclen or something like that), incrementing the > pointer will then give you the next character. Last char is 0. > Note that it is IMPOSSIBLE to go backward unless you know the string > first character address. I believe this is wrong, w/r/t UTF-8. This is one of its design features. You can safely start in the middle of a string, as well as go backwards. Though counting characters is not as simple as with w_char_t or single-byte encodings. -- Thatcher Ulrich http://tulrich.com |
|
From: Paul R. <pa...@so...> - 2003-11-19 19:01:27
|
I can't claim to be an expert by any means. I've just started digging into it all myself. The actual implementation of Unicode support is extremely compiler dependent (http://oss.software.ibm.com/icu/docs/papers/unicode_wchar_t.html). GCC and VC++ both have a data type declared wchar_t that you use for working with unicode strings. A string literal is declared with a leading 'L': wchar_t* str = L"This is my fancy string"; From what I understand so far, both compilers used fixed size for all characters that are big enough to hold any code point. (GCC is 32-bit, and VC++ is 16-bit). So pointer arithmetic and sizeof(whcar_t) are still reliable. There's lots of more info about the Unicode standard http://www.unicode.org/standard/principles.html... "Character encoding standards define not only the identity of each character and its numeric value, or code point, but also how this value is represented in bits. The Unicode Standard defines three encoding forms that allow the same data to be transmitted in a byte, word or double word oriented format (i.e. in 8, 16 or 32-bits per code unit). All three encoding forms encode the same common character repertoire and can be efficiently transformed into one another without loss of data. The Unicode Consortium fully endorses the use of any of these encoding forms as a conformant way of implementing the Unicode Standard. UTF-8 is popular for HTML and similar protocols. UTF-8 is a way of transforming all Unicode characters into a variable length encoding of bytes. It has the advantages that the Unicode characters corresponding to the familiar ASCII set have the same byte values as ASCII, and that Unicode characters transformed into UTF-8 can be used with much existing software without extensive software rewrites. UTF-16 is popular in many environments that need to balance efficient access to characters with economical use of storage. It is reasonably compact and all the heavily used characters fit into a single 16-bit code unit, while all other characters are accessible via pairs of 16-bit code units. UTF-32 is popular where memory space is no concern, but fixed width, single code unit access to characters is desired. Each Unicode character is encoded in a single 32-bit code unit when using UTF-32. All three encoding forms need at most 4 bytes (or 32-bits) of data for each character." -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Garett Bass Sent: Wednesday, November 19, 2003 9:58 AM To: gam...@li... Subject: RE: [GD-General] Unicode Paul, It was after reading Joel's article that I understood Unicode to use an indeterminate number of bytes per character. Specifically: "In UTF-8, every code point from 0-127 is stored in a single byte. Only code points 128 and above are stored using 2, 3, in fact, up to 6 bytes." Which leaves me wondering, how do you figure out where one character ends and the next begins? Thanks in advance, Garett -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Paul Reynolds Sent: Wednesday, November 19, 2003 11:31 AM To: gam...@li... Subject: RE: [GD-General] Feedback wanted on POSH This is a pretty good overview of text encoding*: http://www.joelonsoftware.com/articles/Unicode.html I'd say everyone working on a shipping game should really evaluate if raw char* strings are really a good idea. If you've ever had to localize a 7-bit ascii game, you'll know what I'm talking about. Other software industries have been embracing unicode for quite some time. * - For the record, I'm not a Joel Spolsky fanboy. I can usually take him or leave him. ;o) -----Original Message----- From: gam...@li... [mailto:gam...@li...]On Behalf Of Garett Bass Sent: Wednesday, November 19, 2003 9:13 AM To: gam...@li... Subject: RE: [GD-General] Feedback wanted on POSH // Crosbie Fitch wrote: // Hmmn maybe the chars should be like this: You will notice that POSH doesn't provide a char typedef, presumably because sizeof(char) == 1 in ANSI C, as mentioned in another post. I imagine that defining your own integer character type will require an explicit cast anytime you want to use a string manipulation function, which seems a little awkward. Of course, if you use C++ and STL, then you can always create a std::basic_string<char_utf8>, or whatever. // typedef char8 char_ascii; // Unsized char able to contain 7bit ASCII // typedef char8 char_utf8; // Unsized char able to contain... // typedef char16 char_ucs2; // Unsized char able to contain... 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. // typedef char_utf8 char_unicode; // Unsized char suitable for Unicode // typedef char_unicode character; // Unsized char suitable for any text 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. Regards, Garett ------------------------------------------------------- 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 ------------------------------------------------------- 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 |
|
From: Thatcher U. <tu...@tu...> - 2003-11-19 19:44:51
|
On Nov 19, 2003 at 11:01 -0800, Paul Reynolds wrote: > > UTF-8 [...] > > UTF-16 [...] > > UTF-32 [...] > > All three encoding forms need at most 4 bytes (or 32-bits) of data for each > character." Apparently UTF-8 uses up to 6 bytes for certain characters. -- Thatcher Ulrich http://tulrich.com |
|
From: Jani K. <ka...@ga...> - 2003-11-19 19:46:55
|
wchar_t is platform dependent, but on the other hand you probably don't need
Unicode string literals at all. You can use ASCII-7 as source string and
read the (Unicode) translations in different languages of specific strings
from a file, so you can store internally the string in whatever UTF format
you want and still use only ASCII-7 in source code, something like:
String translatedUnicodeString =
translator->translate( "File {0} not found", filename );
For simple UTF-8/16/32/ASCII-7 converter have a look at
http://catmother.sourceforge.net source package and it's source file
lang/UTFConverter.cpp. It's very simple and doesn't handle special cases
correctly like incorrect UTF-data as guided in the Unicode standard, but it
should serve as simple encoder/decoder. For more complete Unicode
implementation ICU is the weapon of choice, a very complete and very
high-quality library, but also very heavy-weight and probably overkill for a
typical game. (just my opinion of course)
Regards,
Jani
----- Original Message -----
From: "Paul Reynolds" <pa...@so...>
To: <gam...@li...>
Sent: Wednesday, November 19, 2003 9:01 PM
Subject: RE: [GD-General] Unicode
> I can't claim to be an expert by any means. I've just started digging into
> it all myself. The actual implementation of Unicode support is extremely
> compiler dependent
> (http://oss.software.ibm.com/icu/docs/papers/unicode_wchar_t.html). GCC
and
> VC++ both have a data type declared wchar_t that you use for working with
> unicode strings. A string literal is declared with a leading 'L':
>
> wchar_t* str = L"This is my fancy string";
>
> From what I understand so far, both compilers used fixed size for all
> characters that are big enough to hold any code point. (GCC is 32-bit, and
> VC++ is 16-bit). So pointer arithmetic and sizeof(whcar_t) are still
> reliable.
>
> There's lots of more info about the Unicode standard
> http://www.unicode.org/standard/principles.html...
>
> "Character encoding standards define not only the identity of each
character
> and its numeric value, or code point, but also how this value is
represented
> in bits.
>
> The Unicode Standard defines three encoding forms that allow the same data
> to be transmitted in a byte, word or double word oriented format (i.e. in
8,
> 16 or 32-bits per code unit). All three encoding forms encode the same
> common character repertoire and can be efficiently transformed into one
> another without loss of data. The Unicode Consortium fully endorses the
use
> of any of these encoding forms as a conformant way of implementing the
> Unicode Standard.
>
> UTF-8 is popular for HTML and similar protocols. UTF-8 is a way of
> transforming all Unicode characters into a variable length encoding of
> bytes. It has the advantages that the Unicode characters corresponding to
> the familiar ASCII set have the same byte values as ASCII, and that
Unicode
> characters transformed into UTF-8 can be used with much existing software
> without extensive software rewrites.
>
> UTF-16 is popular in many environments that need to balance efficient
access
> to characters with economical use of storage. It is reasonably compact and
> all the heavily used characters fit into a single 16-bit code unit, while
> all other characters are accessible via pairs of 16-bit code units.
>
> UTF-32 is popular where memory space is no concern, but fixed width,
single
> code unit access to characters is desired. Each Unicode character is
> encoded in a single 32-bit code unit when using UTF-32.
>
> All three encoding forms need at most 4 bytes (or 32-bits) of data for
each
> character."
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Garett Bass
> Sent: Wednesday, November 19, 2003 9:58 AM
> To: gam...@li...
> Subject: RE: [GD-General] Unicode
>
>
> Paul,
>
> It was after reading Joel's article that I understood Unicode to use an
> indeterminate number of bytes per character. Specifically:
>
> "In UTF-8, every code point from 0-127 is stored in a single byte. Only
code
> points 128 and above are stored using 2, 3, in fact, up to 6 bytes."
>
> Which leaves me wondering, how do you figure out where one character ends
> and the next begins?
>
> Thanks in advance,
> Garett
>
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Paul Reynolds
> Sent: Wednesday, November 19, 2003 11:31 AM
> To: gam...@li...
> Subject: RE: [GD-General] Feedback wanted on POSH
>
>
> This is a pretty good overview of text encoding*:
> http://www.joelonsoftware.com/articles/Unicode.html
>
> I'd say everyone working on a shipping game should really evaluate if raw
> char* strings are really a good idea. If you've ever had to localize a
7-bit
> ascii game, you'll know what I'm talking about. Other software industries
> have been embracing unicode for quite some time.
>
> * - For the record, I'm not a Joel Spolsky fanboy. I can usually take him
or
> leave him. ;o)
>
> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Garett Bass
> Sent: Wednesday, November 19, 2003 9:13 AM
> To: gam...@li...
> Subject: RE: [GD-General] Feedback wanted on POSH
>
>
> // Crosbie Fitch wrote:
> // Hmmn maybe the chars should be like this:
>
> You will notice that POSH doesn't provide a char typedef, presumably
because
> sizeof(char) == 1 in ANSI C, as mentioned in another post. I imagine that
> defining your own integer character type will require an explicit cast
> anytime you want to use a string manipulation function, which seems a
little
> awkward. Of course, if you use C++ and STL, then you can always create a
> std::basic_string<char_utf8>, or whatever.
>
> // typedef char8 char_ascii; // Unsized char able to contain 7bit ASCII
> // typedef char8 char_utf8; // Unsized char able to contain...
> // typedef char16 char_ucs2; // Unsized char able to contain...
>
> 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.
>
> // typedef char_utf8 char_unicode; // Unsized char suitable for Unicode
> // typedef char_unicode character; // Unsized char suitable for any text
>
> 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.
>
> Regards,
> Garett
>
>
>
> -------------------------------------------------------
> 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
>
>
>
> -------------------------------------------------------
> 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
|
|
From: Thatcher U. <tu...@tu...> - 2003-11-19 19:06:40
|
You might want to read these after (or instead of) the Joel article: http://www.cl.cam.ac.uk/~mgk25/unicode.html (the first few sections are packed with info and apply to any OS) http://www.utf-8.com -T On Nov 19, 2003 at 11:58 -0600, Garett Bass wrote: > Paul, > > It was after reading Joel's article that I understood Unicode to use an > indeterminate number of bytes per character. Specifically: > > "In UTF-8, every code point from 0-127 is stored in a single byte. Only code > points 128 and above are stored using 2, 3, in fact, up to 6 bytes." > > Which leaves me wondering, how do you figure out where one character ends > and the next begins? > > Thanks in advance, > Garett > > > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On Behalf Of > Paul Reynolds > Sent: Wednesday, November 19, 2003 11:31 AM > To: gam...@li... > Subject: RE: [GD-General] Feedback wanted on POSH > > > This is a pretty good overview of text encoding*: > http://www.joelonsoftware.com/articles/Unicode.html > > I'd say everyone working on a shipping game should really evaluate if raw > char* strings are really a good idea. If you've ever had to localize a 7-bit > ascii game, you'll know what I'm talking about. Other software industries > have been embracing unicode for quite some time. > > * - For the record, I'm not a Joel Spolsky fanboy. I can usually take him or > leave him. ;o) > > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On Behalf Of > Garett Bass > Sent: Wednesday, November 19, 2003 9:13 AM > To: gam...@li... > Subject: RE: [GD-General] Feedback wanted on POSH > > > // Crosbie Fitch wrote: > // Hmmn maybe the chars should be like this: > > You will notice that POSH doesn't provide a char typedef, presumably because > sizeof(char) == 1 in ANSI C, as mentioned in another post. I imagine that > defining your own integer character type will require an explicit cast > anytime you want to use a string manipulation function, which seems a little > awkward. Of course, if you use C++ and STL, then you can always create a > std::basic_string<char_utf8>, or whatever. > > // typedef char8 char_ascii; // Unsized char able to contain 7bit ASCII > // typedef char8 char_utf8; // Unsized char able to contain... > // typedef char16 char_ucs2; // Unsized char able to contain... > > 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. > > // typedef char_utf8 char_unicode; // Unsized char suitable for Unicode > // typedef char_unicode character; // Unsized char suitable for any text > > 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. > > Regards, > Garett > > > > ------------------------------------------------------- > 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 > > > > ------------------------------------------------------- > 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 -- Thatcher Ulrich http://tulrich.com |
|
From: Crosbie F. <cr...@cy...> - 2003-11-19 18:00:37
|
> From: Garett Bass > 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. 'Unsized' as in "The code accommodates any size, but requires storage for something of a particular type" int is unsized in the sense its size is not known implicitly. In my example char_utf8 is unsized (even though defined in terms of the sized types char8 and uint8). |
|
From: Aaron D. <ri...@in...> - 2003-11-20 03:37:41
|
I haven't really had much experience with autoconf/automake/configure it but it seems like this sort of stuff would fit nicely into that system rather than compete with it. Maybe someone more familiar with this system could provide some more insight? On Thu, 20 Nov 2003 05:04 am, Crosbie Fitch wrote: > > From: Garett Bass > > 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. > > 'Unsized' as in "The code accommodates any size, but requires storage for > something of a particular type" > > int is unsized in the sense its size is not known implicitly. > > In my example char_utf8 is unsized (even though defined in terms of the > sized types char8 and uint8). > > > > ------------------------------------------------------- > 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 -- - Aaron "Today's mighty oak is just yesterday's nut that held its ground." |
|
From: Brian H. <ho...@py...> - 2003-11-20 05:31:26
|
On Thu, 20 Nov 2003 14:35:51 +1100, Aaron Drew wrote: > I haven't really had much experience with > autoconf/automake/configure it but it seems like this sort of stuff > would fit nicely into that system rather than compete with it. > Maybe someone more familiar with this system could provide some > more insight? The problem is that those require an external tool and configuration process. POSH is specifically designed to be drop-in, compile and go with minimal configuration. Brian |
|
From: Thatcher U. <tu...@tu...> - 2003-11-20 06:06:36
|
My opinion on the auto* tools: very unintuitive, very hacky, very awkward to develop with, very very very (almost magically) portable amongst Unix-like systems. So it's fantastic for distributing source tarballs. But that stuff isn't really compatible with MS's Windows tools, let alone consoles. POSH seems much more game-developer-friendly, in that you just drop it in to virtually any build environment. Plus it's Public Domain, so no license sweating. -Thatcher On Nov 20, 2003 at 02:35 +1100, Aaron Drew wrote: > I haven't really had much experience with autoconf/automake/configure it but > it seems like this sort of stuff would fit nicely into that system rather > than compete with it. Maybe someone more familiar with this system could > provide some more insight? > > On Thu, 20 Nov 2003 05:04 am, Crosbie Fitch wrote: > > > From: Garett Bass > > > 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. > > > > 'Unsized' as in "The code accommodates any size, but requires storage for > > something of a particular type" > > > > int is unsized in the sense its size is not known implicitly. > > > > In my example char_utf8 is unsized (even though defined in terms of the > > sized types char8 and uint8). > > > > > > > > ------------------------------------------------------- > > 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 > > -- > - Aaron > > "Today's mighty oak is just yesterday's nut that held its ground." > > > > ------------------------------------------------------- > 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 -- Thatcher Ulrich http://tulrich.com |
|
From: Brian H. <ho...@py...> - 2003-12-02 06:59:30
|
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. It is designed to be minimal, and will wrap around the Windows registry; CFPreferences on MacOS/OS X; and the standard file system on Linux. The features will be: - open/close/delete a preferences object - read/write 16-bit, 32-bit, 64-bit, float, double, string, and byte-bucket objects safely (e.g. endianess) - delete keys 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). If you do not have privilege for the operation, tough cookies -- it's the app's responsibility to ensure that appropriate privilege exists. Key enumeration is not planned at this time. As an example, using an ad hoc API, it would look something like: prefs p; PrefsLib_OpenPrefs( &p, "~/MyCompany/ThisGame" ); //local to user PrefsLib_WriteFloat( p, "joystickX", fJoystick ); PrefsLib_WriteString( p, "username", getUserName() ); PrefsLib_ClosePrefs( p ); You get the gist. If anyone has comments/suggestions, I'd love to hear them. Brian |
|
From: <ma...@ch...> - 2003-12-03 14:53:24
|
On Tue, 2 Dec 2003, Brian Hook wrote: > PrefsLib_OpenPrefs( &p, "~/MyCompany/ThisGame" ); //local to user I hope this maps to ~/.MyCompany ? Mads -- Mads Bondo Dydensborg. ma...@ch... Unix is user-friendly; it's just a little particular about which users it is friendly to. |
|
From: Brian H. <ho...@py...> - 2003-12-03 18:38:10
|
On Wed, 3 Dec 2003 15:53:17 +0100 (CET), ma...@ch... wrote: > On Tue, 2 Dec 2003, Brian Hook wrote: > > >> PrefsLib_OpenPrefs( &p, "~/MyCompany/ThisGame" ); //local to user >> > > I hope this maps to ~/.MyCompany ? Yes, that is the intent, although in retrospect, encoding that in the filename is probably not the right way to do things. I'll probably change it to: PrefsLib_OpenPrefs( &p, "MyCompany/ThisGame", PLFLAG_SYSTEM ); where you can specify PLFLAG_SYSTEM, PLFLAG_USER or PLFLAG_CURRENT_DIR. Brian |
|
From: <ma...@ch...> - 2003-12-04 09:07:27
|
On Wed, 3 Dec 2003, Brian Hook wrote:
>
>
> On Wed, 3 Dec 2003 15:53:17 +0100 (CET), ma...@ch... wrote:
> > On Tue, 2 Dec 2003, Brian Hook wrote:
> >
> >
> >> PrefsLib_OpenPrefs( &p, "~/MyCompany/ThisGame" ); //local to user
> >>
> >
> > I hope this maps to ~/.MyCompany ?
^
Please note the .
>
> Yes, that is the intent, although in retrospect, encoding that in the
> filename is probably not the right way to do things. I'll probably
> change it to:
>
> PrefsLib_OpenPrefs( &p, "MyCompany/ThisGame", PLFLAG_SYSTEM );
>
> where you can specify PLFLAG_SYSTEM, PLFLAG_USER or
> PLFLAG_CURRENT_DIR.
Sounds better!
Mads
--
Mads Bondo Dydensborg. ma...@ch...
Maybe you don't care about Microsoft's victims. When Microsoft starts
charging you for every time you turn your computer on, will you care then?
- Melantha Bacchae on /.
|
|
From: Colin F. <cp...@ea...> - 2003-12-04 21:02:12
|
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...
|
|
From: Brian H. <ho...@py...> - 2003-12-04 21:48:44
|
> [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. > [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; That's quite true. Except now you've committed to a plain text file, which might be bad if you have to store binary information for whatever reason (yeah, you could convert to 7-bit ASCII...bleh). > [c] Users can send or receive preferences files, or disucss > specific named settings, via e-mail or web pages; Yes. Although technically you can do that with a Windows registry... > [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); Yep. > [e] Settings persist after clean install of operating system; Yep. > [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!) Yep. > 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. Unix used to be like that, and most applications on DOS used to be like that -- the good old days. In fact, most Unix applications were just an executable and didn't even have external crap associated with them. Today, even the most trivial Windows application seems to require numerous INI and DLL files. I'm in violent agreement with you. I don't like the Windows registry, it seriously pisses me off in fact, however it is kind of a de facto standard for preference storage and does have a couple (albeit minor) benefits. IT types like it simply because users don't know enough to get in and muck it up. Also, I believe you can do remote registry queries under NT. Standardized locations for everything is a nice thing, but whether it's worth the gigantic problem that the registry presents is questionable. That said, I prefer files, and will support files-as-preferences on Windows, but supporting the registry will probably be a requirement no matter what. On OS X, it's kind of the best of both worlds -- your preferences ARE files, and they're XML as well so they can be edited directly. > or somehow the application disappears from the computer without un- > install ever happening, leaving tons of scattered junk behind. That's my biggest pet peeve -- I shouldn't HAVE to uninstall, I should just be able to delete a directory and have it go away. Such a simple thing, but yet Windows still doesn't get it. 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. > 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. You must love OS X Application Bundles then? I happen to think they're one of the coolest aspects of OS X. > Okay, some of these ideas are radical, but I just wanted to share > my own thoughts about preferences files. Not THAT radical. Just in the Windows world =3D) Brian |
|
From: Garett B. <gt...@st...> - 2003-12-03 17:58:24
|
// Everyone seems like they have to write their own // portable preferences/registry wrapper... // It is designed to be minimal, and will wrap around // the Windows registry; CFPreferences on MacOS/OS X; // and the standard file system on Linux. Brian and others, I'm curious why you would want to use the Windows Registry or MacOS CFPrefs when you could just use the file system on all platforms? What is the advantage of using the Operating System's configuration database? Might you at least make a file-system-only implementation option on each platform? Before Win2K/XP, I considered registry-based configuration a huge disadvantage, since it was exceptionally difficult to persist settings if you needed to reinstall the OS. It was always nice to find that many non-MS apps still used .ini-file-esque settings and would just automagically work after a reinstall. Regards, Garett Bass gt...@st... |
|
From: Brian H. <ho...@py...> - 2003-12-03 18:17:48
|
> I'm curious why you would want to use the Windows Registry or MacOS > CFPrefs when you could just use the file system on all platforms? That's a good question, and in general I agree with you that having a separate configuration file seems to make a lot more sense. But for better or for worse, the registry has some advantages. It transparently handles multiple users without actually having to query the user's home path; it is a standard practice; there is little opportunity for the user to accidentally muck with it (file system errors occur a lot more than registry errors); and usually the changes are isolated to an area only your application cares about. Also, it's a standardized location. Right now a lot of applications are dumping settings in /windows/system32 or /windows or /Program Files/Application or /Documents and Settings/user, etc. I abhor applications that litter system areas with their own special files. > Might you at least make a file-system-only > implementation option on each platform? Definitely. I would like to do a file-system fallback path that can be specified, but this does add more work but hopefully could be generalized and shared among all implementations. Brian |
|
From: Brian H. <ho...@py...> - 2003-11-19 11:39:15
|
> There are two requirements for types I reckon: > 1) Size determined requirements with type > 2) Policy determined requirements with type Yes. POSH supplies the former (note specifically that POSH provides EXACTLY sized types, not "at least this size" types). The second requirements are provided (in theory) by ANSI C via the standard primitive type declarations. Brian |
|
From: Crosbie F. <cr...@cy...> - 2003-11-19 11:51:24
|
> From: Brian Hook > > The second requirements are provided (in theory) by ANSI C via the > standard primitive type declarations. I've never tried, but is it possible and advisable to do this: typedef short int; // ?? Maybe it might be a useful clarification if example definitions of policy determined types were provided, if only so that users of poshlib would appreciate the distinction? #if defined(POSH_INTEGER) typedef POSH_INTEGER posh_integer; // Compile time option to specify the unsized integer #else typedef int posh_integer; // Default #endif #if defined(POSH_FLOAT) typedef POSH_FLOAT posh_float; // Compile time option to specify the unsized float #else typedef float posh_float; // Default #endif |
|
From: J C L. <cl...@ka...> - 2003-11-19 14:00:48
|
On Wed, 19 Nov 2003 09:38:35 +0100 (CET) madsdyd <ma...@ch...> wrote: > Is it? Isn't the only requirement for a char, that it can contain a > "char", that is a single character from the platforms preferred > character set? Additionally sizeof(char)==1. -- 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: <ma...@ch...> - 2003-11-19 14:33:19
|
On Wed, 19 Nov 2003 ma...@ch... wrote:
> On Tue, 18 Nov 2003, Garett Bass wrote:
>
> > Also, I find it misleading to call an unsigned char a "byte", since all of
> > the char types are technically a byte
>
> Is it? Isn't the only requirement for a char, that it can contain a
> "char", that is a single character from the platforms preferred character
> set?
Sorry, that was wrong. I confused byte with octet.
Mads
--
Mads Bondo Dydensborg. ma...@ch...
If you aim the gun at your foot and pull the trigger, it's UNIX's job to
ensure reliable delivery of the bullet to where you aimed the gun (in
this case, Mr. Foot).
- Terry Lambert, FreeBSD-Hackers mailing list.
|
|
From: scoubidou944 <sco...@ho...> - 2003-11-19 10:21:31
|
After looking at your var definitions, I'm surprised to see a courageous
developper who can spend time to write long variable type name for basic
types ;p
Many libs (you can see BinkVideo from memory who use it) use this type of
definition :
(the underscore '_' between each parameter name is used to avoid naming
error with local variables overloaded by compiler).
#ifndef IN
#define IN
#endif
#ifndef OUT
#define OUT
#endif
#ifndef OPTIONAL
#define OPTIONAL
#endif
/* BASIC TYPES FOR MULTI PLATEFORM
* char is ALWAYS 8 bits long (plateform independant)
* short is 16 bits long with VISUAL, GNU and PSX2
* int is 32 bits long with VISUAL, GNU and PSX2
* long is 32 bits long with VISUAL, GNU and 64 bits long with PSX2
*/
/* WARNING : this implementation is OK for PSX2 AND VISUAL */
typedef unsigned int u32;
typedef signed int s32;
typedef unsigned short u16;
typedef signed short s16;
typedef unsigned char u8;
typedef char s8;
typedef float f32;
typedef double f64;
#ifdef WIN32
#pragma once
typedef unsigned __int64 u64;
typedef signed __int64 s64;
#endif
which can make a prototype simple to read like :
void MyFunction (IN const s32 _s32Int, IN const f32 *_pf32Array, IN OUT f32
*_pf32OutArray, OPTIONAL bool _bWrite);
Using this format, I think every body understand parameters & their use.
Vincent
----- Original Message -----
From: "Garett Bass" <gt...@st...>
To: <gam...@li...>
Sent: Wednesday, November 19, 2003 3:36 AM
Subject: RE: [GD-General] Feedback wanted on POSH
> Brian,
>
> After looking at posh.h I'm a bit confused. You have defined a whole list
> of basic types (posh_..._t), signed and unsigned integers of 8, 16, and 32
> bits respectively. I notice, however, the only platform you support that
> requires these typedefs is PalmOS, and then only for the 32-bit integers.
>
> This seems like overkill, especially considering the duplication of
> integer/signed types. This leaves me wondering whether some platforms
> define char as unsigned char while others define char as signed char. Why
> not simply define posh types based on the number of bits and leave the
> signed/unsigned up to the user? For example:
>
> typdef char my_byte;
> void Foo(unsigned my_byte bar) {/*...*/};
>
> Also, I find it misleading to call an unsigned char a "byte", since all of
> the char types are technically a byte and your posh "byte" has no
intrinsic
> indication of being unsigned. Also, having the same signed type appear
> under two different names may leave the user wondering whether there is a
> need to explicitly convert a variable of type i16 to s16, which serves no
> purpose.
>
> Grandmaster B, I seek enlightenment on these matters, would you mind
> explaining your reasoning?
>
> Regards,
> Garett Bass
> gt...@st...
|
|
From: Tom H. <to...@ve...> - 2003-11-19 10:58:09
|
At 02:22 AM 11/19/2003, you wrote: >After looking at your var definitions, I'm surprised to see a courageous >developper who can spend time to write long variable type name for basic >types ;p Auto-complete in your editor is a "good thing". Tom |
|
From: Brian H. <ho...@py...> - 2003-11-19 11:37:18
|
> After looking at your var definitions, I'm surprised to see a > courageous developper who can spend time to write long variable > type name for basic types ;p The purpose there is to avoid potential name clashes with pre-existing libraries. It's highly unlikely that someone else has posh_u16_t defined, but reasonably likely that someone out there has u16 or unsigned16 or u16_t defined. The intent is that developers will alias their own types to the posh ones instead of actually using the posh ones everywhere. I've updated the documentation to reflect this. > which can make a prototype simple to read like : > void MyFunction (IN const s32 _s32Int, IN const f32 *_pf32Array, IN > OUT f32 *_pf32OutArray, OPTIONAL bool _bWrite); I agree (I really wish that ANSI C had a "writeonly" keyword...), however I'm trying to make POSH more about utility and less about enforcing style. Brian |
|
From: Mat N. \(BUNGIE\) <mat...@mi...> - 2003-10-10 04:05:52
|
Debugging memory dumps is far more effective than you seem to think. = Especially with built in support for mapping debug info to said dump. =20 MSN ________________________________ From: gam...@li... on behalf of = Aaron Drew Sent: Thu 10/9/2003 8:45 PM To: gam...@li... Subject: Re: [GD-General] Is it possible to detect debugging? On Fri, 10 Oct 2003 10:53 am, Mat Noguchi (BUNGIE) wrote: > That won't stop me from running windbg in non-invasive mode and > capturing a memory dump, then inspecting that. > > I've done it before. It's not that hard at all. > True. But that isn't exactly debugging... Nor could you restore a memory snapshot and expect the application state and graphics card state to = also magically return to an operational condition. Of course there is no way = to stop a determined cracker/debugger but at least these mechanisms will = provide some sort of a road block to make things harder. (Although some may just = see it as a challenge..) I've had a few games with CD-copy protection (eg. The Sims) refuse to = load because I was running SoftICE (A debugger that runs below the OS). I'm = sure that I could have stepped through the 'debugger detection' routine and skipped it if I really wanted to but the hassle was enough of a deterant = for me (I just rebooted without it...) and I guess a large majority of = would-be crackers would just get stumped by your super-37173 crack detection and = not be able to figure out which jump command to modify. ): ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Gamedevlists-general mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-general Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=3D557 |
×
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