gamedevlists-windows Mailing List for gamedev (Page 35)
Brought to you by:
vexxed72
You can subscribe to this list here.
2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(48) |
Oct
(58) |
Nov
(49) |
Dec
(38) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
(124) |
Feb
(83) |
Mar
(17) |
Apr
(37) |
May
(12) |
Jun
(20) |
Jul
(47) |
Aug
(74) |
Sep
(62) |
Oct
(72) |
Nov
(54) |
Dec
(13) |
2003 |
Jan
(36) |
Feb
(8) |
Mar
(38) |
Apr
(3) |
May
(6) |
Jun
(133) |
Jul
(20) |
Aug
(18) |
Sep
(12) |
Oct
(4) |
Nov
(28) |
Dec
(36) |
2004 |
Jan
(22) |
Feb
(51) |
Mar
(28) |
Apr
(9) |
May
(20) |
Jun
(9) |
Jul
(37) |
Aug
(20) |
Sep
(23) |
Oct
(15) |
Nov
(23) |
Dec
(27) |
2005 |
Jan
(22) |
Feb
(20) |
Mar
(5) |
Apr
(14) |
May
(10) |
Jun
|
Jul
(6) |
Aug
(6) |
Sep
|
Oct
(12) |
Nov
(1) |
Dec
|
2006 |
Jan
(18) |
Feb
(4) |
Mar
(3) |
Apr
(6) |
May
(4) |
Jun
(3) |
Jul
(16) |
Aug
(40) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
(2) |
2007 |
Jan
(5) |
Feb
(2) |
Mar
(4) |
Apr
(1) |
May
(13) |
Jun
|
Jul
(26) |
Aug
(3) |
Sep
(10) |
Oct
|
Nov
(4) |
Dec
(5) |
2008 |
Jan
(1) |
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
(3) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Grills, J. <jg...@so...> - 2003-03-24 18:49:19
|
Assuming C++, shouldn't a virtual destructor be sufficient to solve this problem? At the very most, you might have to have the virtual destructor and overload new and delete per class, but those could trivially turn around and call the global versions. I load our graphics interface from a DLL, and it does allocate memory that is released from the client. I've hooked the memory management functions in the DLL to call back into the main game executable so that I really only have one heap. My intent wasn't to work around this issue, but rather to make sure that I had all memory in a single heap so that I could monitor the game's memory usage and fragmentation. j -----Original Message----- From: Rich [mailto:leg...@xm...] Sent: Monday, March 24, 2003 12:08 PM To: gam...@li... Subject: Re: [GD-Windows] new/delete across DLL's In article <E18...@sc...>, Ben Hawes <cr...@ca...> writes: > in the game exe, I call wibble =3D new CFooBar; > Later on, within the exe, I call delete wibble; and get an Assert= > warning because I'm deallocating from the wrong heap. Yep. That's the way Windows DLLs work. Allocations inside a DLL are done on the heap belonging to the DLL (because the DLL can live in memory longer than your process, it must use its own heap for allocations). You can deal with it in one of several ways: - use a static library, not a DLL - use a helper function in the DLL that does the deallocation for you I'd use a static library unless there really is some overriding reason to use a DLL. "It just works" that way. |
From: Javier A. <ja...@py...> - 2003-03-24 18:33:48
|
If both the EXE and your DLL link with the MSVC DLL runtime, it will work correctly because all allocations are physically performed inside the (single instance of the) runtime DLL. Rich wrote: > >> in the game exe, I call wibble =3D new CFooBar; >> Later on, within the exe, I call delete wibble; and get an Assert= >> warning because I'm deallocating from the wrong heap. > > Yep. That's the way Windows DLLs work. Allocations inside a DLL are > done on the heap belonging to the DLL (because the DLL can live in > memory longer than your process, it must use its own heap for > allocations). > > You can deal with it in one of several ways: > - use a static library, not a DLL > - use a helper function in the DLL that does the deallocation for you > > I'd use a static library unless there really is some overriding > reason to use a DLL. "It just works" that way. Javier Arevalo Pyro Studios |
From: Jon W. <hp...@mi...> - 2003-03-24 18:21:08
|
Welcome to DLL hell. There are two kinds of DLL hell: the Unix hell, where some library can=20 decide to replace malloc() in the global symbol table, and suddenly=20 you're running with some other allocator than you tested your code=20 with; and the Windows hell, where each DLL can run with its own=20 allocator (say, debug vs release vs version 7.0), which means that you=20 have to balance all allocations and deletions. The only sane way around this that I've found is to base your cross- DLL object model on factory functions and abstract interfaces, and use=20 "deleteYourself()" as a virtual function to delete an instance (or go=20 all the way and acquire()/release() with ref counting). You may note that COM does a lot of these things, btw :-) Also, for the same reasons, inline functions are often a very bad idea=20 for objects that are supposed to live in DLLs. First, because you have=20 to re-compile the user when you change the implementation of the object=20 (so you can't rev the DLL separately unless you take a LOT of care).=20 Second, because if you happen to allocate memory, then the inline may=20 live in one of many different modules. This is especially bad with STL=20 style containers. Cheers, / h+ > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...]On Behalf Of > Ben Hawes > Sent: Monday, March 24, 2003 9:08 AM > To: gam...@li... > Subject: [GD-Windows] new/delete across DLL's >=20 >=20 > Am I doing something wrong, or is this correct behaviour: >=20 > in core.dll I have a class CFooBar. >=20 > in the game exe, I call wibble =3D new CFooBar; > Later on, within the exe, I call delete wibble; and get an Assert=20 > warning because I'm deallocating from the wrong heap. >=20 > This seems very strange, that I can only deallocate a class=20 > defined in a DLL from within that DLL, even if the instance was=20 > allocated somewhere else. Am I understanding this correctly, or=20 > am I doing something else to cause the problem? Is there any way=20 > round this? >=20 > [ cruise / casual-tempest.net / transference.org ] >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_idU5 >=20 |
From: Rich <leg...@xm...> - 2003-03-24 18:08:53
|
In article <E18...@sc...>, Ben Hawes <cr...@ca...> writes: > in the game exe, I call wibble =3D new CFooBar; > Later on, within the exe, I call delete wibble; and get an Assert= > warning because I'm deallocating from the wrong heap. Yep. That's the way Windows DLLs work. Allocations inside a DLL are done on the heap belonging to the DLL (because the DLL can live in memory longer than your process, it must use its own heap for allocations). You can deal with it in one of several ways: - use a static library, not a DLL - use a helper function in the DLL that does the deallocation for you I'd use a static library unless there really is some overriding reason to use a DLL. "It just works" that way. -- "The Direct3D Graphics Pipeline"-- code samples, sample chapter, FAQ: <http://www.xmission.com/~legalize/book/> izfree: Open source tools for Windows Installer <http://izfree.sourceforge.net> |
From: Ben H. <cr...@ca...> - 2003-03-24 17:08:58
|
Am I doing something wrong, or is this correct behaviour: in core.dll I have a class CFooBar. in the game exe, I call wibble =3D new CFooBar; Later on, within the exe, I call delete wibble; and get an Assert= warning because I'm deallocating from the wrong heap. This seems very strange, that I can only deallocate a class= defined in a DLL from within that DLL, even if the instance was= allocated somewhere else. Am I understanding this correctly, or= am I doing something else to cause the problem? Is there any way= round this? [ cruise / casual-tempest.net / transference.org ] |
From: Matt N. <mat...@ni...> - 2003-02-27 17:41:48
|
Thanks, that seems to be what I'm looking for. Matt. > -----Original Message----- > From: Paul Bleisch [mailto:pa...@mi...]=20 > Sent: 27 February 2003 15:09 > To: gam...@li... > Subject: RE: [GD-Windows] PDB files >=20 >=20 >=20 > You might look at John Robbins crash finder stuff: >=20 > http://www.wintellect.com/about/instructors/robbins/default.aspx >=20 > > -----Original Message----- > > From: Matt Newport [mailto:mat...@ni...] > > Sent: Thursday, February 27, 2003 5:20 AM > > To: gam...@li... > > Subject: [GD-Windows] PDB files > >=20 > >=20 > > Given a .PDB file and a Windows crash report containing the > > values of the CS and EIP pointers what's the easiest way of=20 > > finding the associated function and line number? I know you=20 > > can do this by loading the project into Visual Studio and=20 > > setting a breakpoint but it seems there ought to be an easier=20 > > / more direct way of doing this. > >=20 > > Thanks, > >=20 > > Matt. > >=20 > > --- > > Outgoing mail is certified Virus Free. > > Checked by AVG anti-virus system (http://www.grisoft.com). > > Version: 6.0.458 / Virus Database: 257 - Release Date: 24/02/2003 > > =20 > >=20 > >=20 > > ------------------------------------------------------- > > This SF.NET email is sponsored by: > > SourceForge Enterprise Edition + IBM + LinuxWorld =3Domething 2 See! = > > http://www.vasoftware.com=20 > > _______________________________________________ > > Gamedevlists-windows mailing list=20 > > Gam...@li... > > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > > Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU5 > >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf=20 > _______________________________________________ > Gamedevlists-windows mailing list=20 > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: http://sourceforge.net/mailarchive/forum.php?forum_idU5 >=20 > --- > Incoming mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.458 / Virus Database: 257 - Release Date: 24/02/2003 > =20 >=20 --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.458 / Virus Database: 257 - Release Date: 24/02/2003 =20 |
From: Paul B. <pa...@mi...> - 2003-02-27 15:08:58
|
You might look at John Robbins crash finder stuff: http://www.wintellect.com/about/instructors/robbins/default.aspx > -----Original Message----- > From: Matt Newport [mailto:mat...@ni...]=20 > Sent: Thursday, February 27, 2003 5:20 AM > To: gam...@li... > Subject: [GD-Windows] PDB files >=20 >=20 > Given a .PDB file and a Windows crash report containing the=20 > values of the CS and EIP pointers what's the easiest way of=20 > finding the associated function and line number? I know you=20 > can do this by loading the project into Visual Studio and=20 > setting a breakpoint but it seems there ought to be an easier=20 > / more direct way of doing this. >=20 > Thanks, >=20 > Matt. >=20 > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.458 / Virus Database: 257 - Release Date: 24/02/2003 > =20 >=20 >=20 > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld =3Domething 2 See! > http://www.vasoftware.com > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_idU5 >=20 |
From: Matt N. <mat...@ni...> - 2003-02-27 11:17:44
|
Given a .PDB file and a Windows crash report containing the values of = the CS and EIP pointers what's the easiest way of finding the associated = function and line number? I know you can do this by loading the project = into Visual Studio and setting a breakpoint but it seems there ought to = be an easier / more direct way of doing this. Thanks, Matt. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.458 / Virus Database: 257 - Release Date: 24/02/2003 =20 |
From: Grisha S. <_g...@tu...> - 2003-02-21 11:57:14
|
I get this results only with lfFaceName set to "Courier New". With "Lucida Console" all works if antialiasing not disabled in DisplayProperties/Appearance/Effects. Both fonts is OpenType fonts, there is no other Courier New fonts in system (only bold&italic versions) and it supports antialiasing - i can get ClearType antialiasing on it, but can't get standard antialiasing. And I can't get antialiasig in any form if it is disabled in DisplayProperties/Appearance/Effects. Display is 32-bit color. And I select font into device context: HGDIOBJ hFontOld2 = SelectObject( GetDC( 0 ), (HGDIOBJ)hFont ); HGDIOBJ hFontOld1 = SelectObject( hDC, (HGDIOBJ)hFont ); HGDIOBJ hFontOld = SelectObject( hMemoryDC, (HGDIOBJ)hFont ); -grisha |
From: Jon W. <hp...@mi...> - 2003-02-21 01:07:51
|
> When I set lfQuality in LOGFONT structure to ANTIALIASED_QUALITY > I get NONantialiased font. Select it into a real screen (physical device) DC before selecting it into your offscreen DC. Cheers, / h+ |
From: Javier A. <ja...@py...> - 2003-02-20 23:59:00
|
>From MSDN: ------------- Windows NT 4.0 and later: Font is antialiased, or smoothed, if the font supports it and the size of the font is not too small or too large. Windows 95 with Plus!, Windows 98/Me: The display must greater than 8-bit color, it must be a single plane device, it cannot be a palette display, and it cannot be in a multiple display monitor setup. In addition, you must select a TrueType font into a screen DC prior to using it in a DIBSection, otherwise antialiasing does not happen. ------------- Also check this out, he talks a bit about situations where Windows will/won't honor the flag: http://unreal.epicgames.com/TTFImport.htm Hope this helps. Grisha Spivak wrote: > Hi, > During writing the routine on creating font texture I have faced with > strange behaviour of CreateFontIndirect. > When I set lfQuality in LOGFONT structure to ANTIALIASED_QUALITY I get > NONantialiased font. > > With over values of lfQuality I get following results: > > with antialiasing settings set to ClearType in > DisplayProperties/Appearance/Effects: > > DEFAULT_QUALITY - ClearType (color pixels) > DRAFT_QUALITY - antialiased font (grayscale) > PROOF_QUALITY - ClearType > NONANTIALIASED_QUALITY - nonantialiased > ANTIALIASED_QUALITY - nonantialiased - WHY???? > CLEARTYPE_QUALITY - ClearType > > with antialiasing settings set to Standard: > all - nonantialiased, only CLEARTYPE_QUALITY - ClearType > > with antialiasing settings set to Off: > all - nonantialiased > > lfFaceName is "Courier New" > lfHeight = -20 > > Is it normal? > > -grisha > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. > The most comprehensive and flexible code editor you can use. > Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 |
From: Grisha S. <_g...@tu...> - 2003-02-20 23:06:36
|
Hi, During writing the routine on creating font texture I have faced with strange behaviour of CreateFontIndirect. When I set lfQuality in LOGFONT structure to ANTIALIASED_QUALITY I get NONantialiased font. With over values of lfQuality I get following results: with antialiasing settings set to ClearType in DisplayProperties/Appearance/Effects: DEFAULT_QUALITY - ClearType (color pixels) DRAFT_QUALITY - antialiased font (grayscale) PROOF_QUALITY - ClearType NONANTIALIASED_QUALITY - nonantialiased ANTIALIASED_QUALITY - nonantialiased - WHY???? CLEARTYPE_QUALITY - ClearType with antialiasing settings set to Standard: all - nonantialiased, only CLEARTYPE_QUALITY - ClearType with antialiasing settings set to Off: all - nonantialiased lfFaceName is "Courier New" lfHeight = -20 Is it normal? -grisha |
From: Javier A. <ja...@py...> - 2003-02-10 14:19:57
|
Hi, our IME support seems to be working well, but we're still unable to prevent the F5 key from popping up the IME pad window - right now the window shows ups with the usual fullscreen flickering. Any ideas? Javier Arevalo Pyro Studios |
From: Javier A. <ja...@py...> - 2003-01-24 14:47:12
|
I thought you would use SHGetSpecialFolderPath() instead. Dale Freya <df...@op...> wrote: >> Are you sure this is true for Windows 98? From MSDN, "Shell and >> Common Controls Versions" >> (MSDN\Shellcc.chm::/shellcc/Shell/versions.htm): >> >> "All Windows 98 systems have version 4.72 of Shell32.dll." >> >> It _is_ true for Windfows 95, though. > > SHGetFolderPath requires shell32.dll version 5.0 or later. > SHGetFolderPath can only be accessed on Windows 98 through the > ShFolder.dll redistributable. > > http://msdn.microsoft.com/library/en- > us/shellcc/platform/shell/reference > /functions/shgetfolderpath.asp?frame=true > > - Dale > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 Javier Arevalo Pyro Studios |
From: Dale F. <df...@op...> - 2003-01-24 12:22:09
|
> Are you sure this is true for Windows 98? From MSDN, "Shell and Common > Controls Versions" (MSDN\Shellcc.chm::/shellcc/Shell/versions.htm): > > "All Windows 98 systems have version 4.72 of Shell32.dll." > > It _is_ true for Windfows 95, though. SHGetFolderPath requires shell32.dll version 5.0 or later. SHGetFolderPath can only be accessed on Windows 98 through the ShFolder.dll redistributable. http://msdn.microsoft.com/library/en-us/shellcc/platform/shell/reference /functions/shgetfolderpath.asp?frame=true - Dale |
From: Javier A. <ja...@py...> - 2003-01-24 11:27:55
|
Are you sure this is true for Windows 98? From MSDN, "Shell and Common Controls Versions" (MSDN\Shellcc.chm::/shellcc/Shell/versions.htm): "All Windows 98 systems have version 4.72 of Shell32.dll." It _is_ true for Windfows 95, though. Dale Freya <df...@op...> wrote: > The SHGetFolderPath functionality is available on Win98 in the > ShFolder.dll Platform SDK redistributable. > > http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdkredist.htm > > If you want to use SHGetFolderPath on Win98 make sure you always link > to the SHGetFolderPath in ShFolder.dll and not the one in shell32.dll. > > See... > How to play well with WindowsR XP > http://www.microsoft.com/mscorp/corpevents/meltdown2001/presentations.as > p > Mike Burrows - Microsoft Corporation [Meltdown 2001] > > - Dale > > > -----Original Message----- > From: gam...@li... > [mailto:gam...@li...] On Behalf Of > Jon Watte > Sent: Friday, 24 January 2003 4:28 AM > To: gam...@li... > Subject: RE: [GD-Windows] Security/access when writing to registry > > >> Is it impossible to put that stuff along with save data in the >> folder where >> the game was installed ??? > > Yes; if the game is installed by a user who is administrator, and > then run by a user who is not, the second user won't be able to > write to the folder where the game is installed. Lots of older > games are failing on Windows XP for this reason (or forcing users > to run as Administrator all the time, which is bad for different > reasons). > >> Personaly I'm swearing each time some "smart" pc developper put >> settings, highscores and save games in some weird location in my >> computer, because it >> means I cannot backup my game saves. > > I'd be happy if they just DOCUMENTED where these were. I use three > different computers at different times during the week, and I want > to drag my savegames with me. Some games make finding out what I > need to drag with me easier than others. > > The right thing to do, really, is using the > SHGetSpecialFolderLocation() call (NT4, Win95) or the > SHGetFolderLocation() call (Win2k, WinME). Pass > CSIDL_COMMON_DOCUMENTS on < WinME/Win2k; possibly pass > CSIDL_COMMON_APPDATA on Win2k and WinME and later (too bad that's > not available for Win98) > > On the MacOS, the FindFolder() function has been around since the > late '80s, so users are quite used to finding the "settings" folder > and expecting all application settings to go there. > > Cheers, > > / h+ > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 Javier Arevalo Pyro Studios |
From: Wayne C. <wc...@re...> - 2003-01-24 09:38:07
|
> I agree though, it is a *real* pain in Windows to transfer application > data > (i.e Outlook Express with mail, folders, addresses * newsgroups) to > another > computer. Hmmm, I've not really considered a 'travelling' install. Although if I were aiming to support such a feature then maybe an extra option on the applications start bar entry would be an option? (ie. "Programs->My App->Build Travel Bag" or some-such). Wayney "I'm sure at least 2% of my mails are not inane babble!" - Wayne Coles, 2003 -Virus scanned and cleared ok |
From: Dale F. <df...@op...> - 2003-01-23 23:37:57
|
The SHGetFolderPath functionality is available on Win98 in the ShFolder.dll Platform SDK redistributable. http://www.microsoft.com/msdownload/platformsdk/sdkupdate/psdkredist.htm If you want to use SHGetFolderPath on Win98 make sure you always link to the SHGetFolderPath in ShFolder.dll and not the one in shell32.dll. See... How to play well with WindowsR XP http://www.microsoft.com/mscorp/corpevents/meltdown2001/presentations.as p Mike Burrows - Microsoft Corporation [Meltdown 2001] - Dale -----Original Message----- From: gam...@li... [mailto:gam...@li...] On Behalf Of Jon Watte Sent: Friday, 24 January 2003 4:28 AM To: gam...@li... Subject: RE: [GD-Windows] Security/access when writing to registry > Is it impossible to put that stuff along with save data in the > folder where > the game was installed ??? Yes; if the game is installed by a user who is administrator, and then run by a user who is not, the second user won't be able to write to the folder where the game is installed. Lots of older games are failing on Windows XP for this reason (or forcing users to run as Administrator all the time, which is bad for different reasons). > Personaly I'm swearing each time some "smart" pc developper put settings, > highscores and save games in some weird location in my computer, > because it > means I cannot backup my game saves. I'd be happy if they just DOCUMENTED where these were. I use three different computers at different times during the week, and I want to drag my savegames with me. Some games make finding out what I need to drag with me easier than others. The right thing to do, really, is using the SHGetSpecialFolderLocation() call (NT4, Win95) or the SHGetFolderLocation() call (Win2k, WinME). Pass CSIDL_COMMON_DOCUMENTS on < WinME/Win2k; possibly pass CSIDL_COMMON_APPDATA on Win2k and WinME and later (too bad that's not available for Win98) On the MacOS, the FindFolder() function has been around since the late '80s, so users are quite used to finding the "settings" folder and expecting all application settings to go there. Cheers, / h+ ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Gamedevlists-windows mailing list Gam...@li... https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows Archives: http://sourceforge.net/mailarchive/forum.php?forum_id=555 |
From: Andrew G. <ag...@cl...> - 2003-01-23 18:39:00
|
If it's Win98 you can just bung the scores file in the same directory where the game was installed to. I agree though, it is a *real* pain in Windows to transfer application data (i.e Outlook Express with mail, folders, addresses * newsgroups) to another computer. Andy @ Climax Brighton > -----Original Message----- > From: Jon Watte [mailto:hp...@mi...] > Sent: 23 January 2003 18:28 > To: gam...@li... > Subject: RE: [GD-Windows] Security/access when writing to registry > > > > > For me it's summarised in one single choice: If it's worthwhile > > for the user > > to backup it, use the "app local data" you are talking about. > > But that doesn't solve the initial problem, which was data shared > by ALL users, such as highscores. You need the "global" versions > of these folders. > > Unfortunately, appdata is only defined on WinME/Win2k, so if you > want to support Win98 (you do!) then you'll have to go with a > "documents" kind of folder :-( Or maybe not support high score > sharing on that version of Windows. > > Cheers, > > / h+ > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > _______________________________________________ > Gamedevlists-windows mailing list > Gam...@li... > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows > Archives: > http://sourceforge.net/mailarchive/forum.php?forum_id=555 > |
From: Jon W. <hp...@mi...> - 2003-01-23 18:30:10
|
> For me it's summarised in one single choice: If it's worthwhile > for the user > to backup it, use the "app local data" you are talking about. But that doesn't solve the initial problem, which was data shared by ALL users, such as highscores. You need the "global" versions of these folders. Unfortunately, appdata is only defined on WinME/Win2k, so if you want to support Win98 (you do!) then you'll have to go with a "documents" kind of folder :-( Or maybe not support high score sharing on that version of Windows. Cheers, / h+ |
From: Jon W. <hp...@mi...> - 2003-01-23 18:30:10
|
> Is it impossible to put that stuff along with save data in the > folder where > the game was installed ??? Yes; if the game is installed by a user who is administrator, and then run by a user who is not, the second user won't be able to write to the folder where the game is installed. Lots of older games are failing on Windows XP for this reason (or forcing users to run as Administrator all the time, which is bad for different reasons). > Personaly I'm swearing each time some "smart" pc developper put settings, > highscores and save games in some weird location in my computer, > because it > means I cannot backup my game saves. I'd be happy if they just DOCUMENTED where these were. I use three different computers at different times during the week, and I want to drag my savegames with me. Some games make finding out what I need to drag with me easier than others. The right thing to do, really, is using the SHGetSpecialFolderLocation() call (NT4, Win95) or the SHGetFolderLocation() call (Win2k, WinME). Pass CSIDL_COMMON_DOCUMENTS on < WinME/Win2k; possibly pass CSIDL_COMMON_APPDATA on Win2k and WinME and later (too bad that's not available for Win98) On the MacOS, the FindFolder() function has been around since the late '80s, so users are quite used to finding the "settings" folder and expecting all application settings to go there. Cheers, / h+ |
From: Mickael P. <mpo...@ed...> - 2003-01-23 16:02:14
|
Wayne Coles wrote: >> Personaly I'm swearing each time some "smart" pc developper put >> settings, highscores and save games in some weird location in my >> computer, because it means I cannot backup my game saves. > > Although I don't think the registry is the correct place to store > 'shared' information. I also don't think the applications local > directory tree is the correct place either. The ability to 'lock > down' what an application can do is part of where the OS is going > (Windows anyway). Okay. When I was talking about the "folder where the program is installed", I was refering in general to any well documented place where the user can expect to find his data. > If it's for a single user and it's small, I suggest the registry. > If it's for a single user and it's large, I suggest the app local data > directory (as mentioned before, obtained by calling > SHGetSpecialFolderPath with CSIDL_APPDATA). > If it's shared across users, I suggest the app common data directory > (SHGetSpecialFolderPath with CSIDL_COMMON_APPDATA). For me it's summarised in one single choice: If it's worthwhile for the user to backup it, use the "app local data" you are talking about. Mickael Pointier |
From: Wayne C. <wc...@re...> - 2003-01-23 15:34:12
|
> Personaly I'm swearing each time some "smart" pc developper put settings, > highscores and save games in some weird location in my computer, because > it means I cannot backup my game saves. Although I don't think the registry is the correct place to store 'shared' information. I also don't think the applications local directory tree is the correct place either. The ability to 'lock down' what an application can do is part of where the OS is going (Windows anyway). Even now, the .net framework allows the user to prevent applications writing anywhere they like. Providing 'isolated storage' (which is basically the app-data directory someone mentioned before). So in the future you're application may not be able to write to its home directory. If it's for a single user and it's small, I suggest the registry. If it's for a single user and it's large, I suggest the app local data directory (as mentioned before, obtained by calling SHGetSpecialFolderPath with CSIDL_APPDATA). If it's shared across users, I suggest the app common data directory (SHGetSpecialFolderPath with CSIDL_COMMON_APPDATA). Personally I quite like the idea, although I'm known to be a little strange (by some) :) Wayney "I'm sure at least 2% of my mails are not inane babble!" - Wayne Coles, 2003 -Virus scanned and cleared ok |
From: Gareth L. <GL...@cl...> - 2003-01-23 15:25:59
|
Mickael. > Perhaps that due to my less than average english skills I > missed something > of the whole thread, but why actually do you want to put this > kind of things > in the registry ??? Well, it makes sense. > Is it impossible to put that stuff along with save data in > the folder where > the game was installed ??? That is the first thing a lot of us ask. You can't put the data in the directory the game was installed, because the directory the game was installed in, isn't always writable to the player. For example, most games install under "Program Files". As said before, someone might decide that for their children, Program Files will not be writable, so now when little Johnny makes a high-score, the game crashes. > Personaly I'm swearing each time some "smart" pc developper > put settings, > highscores and save games in some weird location in my > computer, because it > means I cannot backup my game saves. True, but there are only 2 real options, Registry and a directory guarenteed to be writable, for example "Documents and Settings\All Users". And for save games, that makes a lot of sense. But if all you want to store are high-scores, then to me, personally, the registry makes more sense. Anyway, even if you do use the All Users directory, you still want to store what directory you used in the registry :) > Sometimes better is worse. Yes, but sometimes simpler is wrong. |
From: Mickael P. <mpo...@ed...> - 2003-01-23 15:13:03
|
> It seems that I simply ignored this stuff about sharing > highscores;-( Perhaps that due to my less than average english skills I missed something of the whole thread, but why actually do you want to put this kind of things in the registry ??? Is it impossible to put that stuff along with save data in the folder where the game was installed ??? Personaly I'm swearing each time some "smart" pc developper put settings, highscores and save games in some weird location in my computer, because it means I cannot backup my game saves. Recently I had to change my computer and was more than happy to be able to copy save games of most of what I had installed directly in the program folder on the new pc. Sometimes better is worse. Mickael Pointier (perplexifié) |