gamedevlists-windows

Re: [GD-Windows] More multimon

[Adrian C. <ce...@ce...>]

(Sorry for the split message, my bad :< )
...chip, and I'm not sure, but I remember that they said it accelerated both
displays. I'll try and re-install my old G450 if any of you is interested in
how such a card handles multimon.

Sorry again for splitting this message in two,
Adrian

----- Original Message -----
From: "Eero Pajarre" <epa...@ko...>
To: <gam...@li...>
Sent: Monday, March 31, 2003 12:45 PM
Subject: Re: [GD-Windows] More multimon


> Brian Hook wrote:
> >
> >
> > This is also a good point.  I don't mind the multimon hacking about,
> > but the nVidia "I'm just a big wide monitor as far you're concerned"
> > thing is kind of annoying because it's probably the single most
> > prevalent multimon config out there.
> >
> >
>
> I was extremely happy when I tried and found this working on a
> Windows XP machine. Considering Microsoft support for OpenGL
> I don't know how I would be able to get fullscreen HW-accelerated
> (OpenGL) graphics for both projectors without it.
>
>
> Eero
>
>
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: ValueWeb:
> Dedicated Hosting for just $79/mo with 500 GB of bandwidth!
> No other company gives more support or power for your dedicated server
> http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>
>

RE: [GD-Windows] More multimon

[Jon W. <hp...@mi...>]

> >My heuristic is that if the display is wider than 16:9 form factor,
> >it's probably two displays side-by-side, and I treat it according to
> >that.
>=20
> That's part of the heuristic I will end up using.  I think the Apple=20
> Cinema Displays are the stretchiest out there.

I once had a Sony laptop which was 1024x480. But I'm prepared to write=20
that off as a fluke :-)=20

There area also the 16:9 DVD playing laptops from Matrix, and Dell seems =

to be jumping on the bandwagon, too. How about making your game adapt to =

whatever aspect ratio the user is using? The main problem is if you=20
have a lot of pixel-perfect 2D art...

Cheers,

				/ h+

RE: [GD-Windows] More multimon

[Kent Q. <ken...@co...>]

At 04:12 PM 3/30/2003 -0800, you wrote:

> > Multi-monitor support is a bit of a mess.
>
>My heuristic is that if the display is wider than 16:9 form factor,
>it's probably two displays side-by-side, and I treat it according
>to that. No other special casing. This takes care of 95% of the
>special cases (which are only 5% of all users to begin with -- tops!)
>
>I suppose you could document an ultra-l33t config file where the
>user can determine what monitor for you to use, and what mode to set
>it in, and where to put the viewport on that monitor. Document it for
>the ten people who care to find it, and all your mass market
>consumers won't be confused by an array of senseless check boxes and
>popup menus ;-)

We just create a file called settings.xml that controls (among other 
things) a bunch of video setup parameters. We haven't had anyone ask about 
the dual monitor problem yet, so I haven't worried about it -- but that's 
where I'd put stuff like this.

In general, I think you worry about the unwashed masses in your normal 
configuration, and if someone's got dual head they're probably on the 
ultra-l33t side anyway, and can handle editing a text file.

I am fretting about the LCD thang myself, though. Sadly, I think the right 
solution is usually to generate multiple sets of art.

         Kent




Kent Quirk, CTO, CogniToy
ken...@co...
http://www.cognitoy.com 

RE: [GD-Windows] Multimon compile/link hell (WINVER)

[Jon W. <hp...@mi...>]

You need to download the entire Platform SDK, and install=20
it for your language of choice. Note that you need to separately=20
re-configure MSDEV to point at the new headers/libs rather than=20
the ones that it comes with. Platform SDK is not a component of=20
MSDEV, in Microsoft parlance, AFAICT.

It may be that there's actually EnumDisplayDevicesA and=20
EnumDisplayDevicesU, and you need to pick up the appropriate=20
#define to get it linked.

Cheers,

			/ h+

Re: [GD-Windows] Security/access when writing to registry

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

Brian Hook wrote: 
> Ideas on a clean solution to this problem?

Internet based high-scores?
You could have both, global hi-scores (for all the users) and local hi-scores
for each copy of the game. It should be safe if only registered users are
able to send their hi-scores. However, the users that are not connected while
playing the game won't see the difference.


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


___________________________________________________
Yahoo! Móviles
Personaliza tu móvil con tu logo y melodía favorito 
en http://moviles.yahoo.es

RE: [GD-Windows] Security/access when writing to registry

[Brian S. <bs...@mi...>]

I'm certainly not a NT security expert, but in this particular instance
you only have access to HKLM if you have admin privileges (since you can
essentially screw up the whole machine from there).  Similarly, I don't
think non-admins can install DLLs to the system directory.  It's
probably more correct to say that admin privileges imply the ability to
write to HKLM, and non-admins might have that particular privilege
enabled, but that's way too much detail.  The important point is that
HKCU should always be accessible. =20

I don't have any links to point you to, but I'm sure you could search
MSDN or Google for something like "porting from 95 to Win2k" to get a
list of other gotchas.

--brian

-----Original Message-----
From: Brian Hook [mailto:bri...@py...]=20
Sent: Thursday, December 20, 2001 10:25 AM
To: gam...@li...
Subject: RE: [GD-Windows] Security/access when writing to registry

> Write to HKEY_CURRENT_USER instead of HKEY_LOCAL_MACHINE.

Can you elaborate on this a bit more (or point me somewhere that does)?
Do you mean simply replace my HKEY_LOCAL_MACHINE places directly with
HKEY_CURRENT_USER?

Brian


_______________________________________________
Gamedevlists-windows mailing list
Gam...@li...
https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows

RE: [GD-Windows] Security/access when writing to registry

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

Thanks for the help everyone.  Yes, I was writing into
HKEY_LOCAL_MACHINE instead of HKEY_CURRENT_USER.  Unfortunately, since
the game is already out and it stores config/high scores information
there, I need to either write an import facility or just continue to use
HKLM when possible.  The latter is easier, since 99.999% of our
particular users aren't going to have this problem.

So now I'm doing:

if ( RegCreateKeyEx( HKEY_LOCAL_MACHINE, ... ) != ERROR_SUCCESS )
   if ( RegCreateKeyEx( HKEY_CURRENT_USER, ... ) 
.
.
.

Future versions will, of course, use HKEY_CURRENT_USER.

Brian

RE: [GD-Windows] Security/access when writing to registry

[Andrew G. <And...@ho...>]

There's another important thing in this area to remember as well. Depending
on their permissions users might not have write permissions to the directory
the game is stored in. It's now recommended that you ensure persistantdata
is stored in folders that users have guaranteed access to, and use
SHGetFolderPath to retrieve this path with the correct identifier. In the
case of application data it would be CSIDL_COMMON_APPDATA, or for user
specific settings you would use CSIDL_APPDATA.

This is going to become a real issue now that XP is around and allows people
to restrict access like this. We've already had one bug report from a
previous project because our game relied on write access to it's install
folder, and little Johhny's dad had locked him off from modifying the
Program Files subtree.

There was an excellent presentation from Mike Burrows at Meltdown this year
about how to write well behaved Windows apps taking these and other aspects
into account. It's now online and well worth a read.

<http://www.microsoft.com/mscorp/corpevents/meltdown2001/ppt/GamingWinXP.ppt
>


Andrew Grant
Hothouse Creations 



> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 20 December 2001 20:40
> To: gam...@li...
> Subject: RE: [GD-Windows] Security/access when writing to registry

> .
> 
> Future versions will, of course, use HKEY_CURRENT_USER.
> 
> Brian
> 
> 
> 


This email is covered by the following disclaimer, please read before
accepting this email. http://www.hothouse.org/disclaimer/

[GD-Windows] SM_SLOWMACHINE

[Pierre T. <p.t...@wa...>]

Just out of pure curiosity, what the hell is that function exactly doing to
tell between a slow and a not-slow machine ?

BOOL Res = GetSystemMetrics(SM_SLOWMACHINE);

I find that one rather amusing :)

P.

RE: [GD-Windows] Security/access when writing to registry

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

Brian,

The new Windows Installer stuff (.MSI files) has an option "Install for just
this user, or install of all users". 

I assume the latter enumerates all the users (Under HKEY_USERS) and adds the
stuff there, instaid of HKCU. That will add it to the current user and all
new users automatically. This is for settings, not shared data like
high-scores.

HKLM is where I would put high-scores, or in some shared folder, as others
have posted. One option is to require admin access when the installer is
run, and to create your install folder as writeable for everyone. Basically
either you use the All Users folder, which works, but I think is messy (I
don't like games installing stuff all over the place) or you make sure your
install folder is writable by all.

Regards, Gareth Lewin

> -----Original Message-----
> From: Brian Hook [mailto:bri...@py...]
> Sent: 22 January 2003 08:02
> To: gam...@li...
> Subject: Re: [GD-Windows] Security/access when writing to registry
> 
> 
> Yes, I'm revisiting a thread that's over a year old =)
> 
> I've been using HKCU instead of HKLM like a good Windows app, but it 
> seems like you can't win 'em all.
> 
> The problem with HKCU is that, well, it's per user.  I've gotten very 
> sporadic complaints about having to install our games multiple times 
> (including unlock codes), which isn't that big a deal.  But what IS a 
> big deal is when you have multiple users on the same machine trying 
> to compete against each other, but now their high scores aren't 
> shared.  This is a pretty galling thing, since a lot of our games are 
> competitive that way and we do find that more than a few of our 
> players are on multi-user systems.
> 
> Ideas on a clean solution to this problem?
> 
> Brian
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: Scholarships for Techies!
> Can't afford IT training? All 2003 ictp students receive scholarships.
> Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more.
> www.ictp.com/training/sourceforge.asp
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_idU5
> 

RE: [GD-Windows] Security/access when writing to registry

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

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.

RE: [GD-Windows] Security/access when writing to registry

[Wayne C. <wc...@re...>]

> 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

RE: [GD-Windows] Security/access when writing to registry

[Mickael P. <mpo...@ed...>]

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

RE: [GD-Windows] Security/access when writing to registry

[Jon W. <hp...@mi...>]

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

RE: [GD-Windows] Security/access when writing to registry

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

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
> 

RE: [GD-Windows] Security/access when writing to registry

[Wayne C. <wc...@re...>]

> 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