gamedevlists-windows — List for discussing game development on the Windows platform

RE: [GD-Windows] Stopping a thread cleanly

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

> Somehow, you're giving this worker thread instructions, so I'd 
> suggest sending a shutdown message the same way you send other 
> commands to the thread.

Actually, I'm not giving it instructions -- it's completely autonomous
based on the parameter passed to it which is a pointer to the shared
data it needs to operate on.  It doesn't have any communication
mechanism with the main thread except for the synchronization objects.

> If the worker thread is supposed to asynchronously "pick up" work 
> every so often (sometimes necessary) then you should use the 
> time- out on the wait operation as your throttle for when to look for 
> more work. That way, you can signal this event (or whatever) when 
> it's time to exit, and the thread will immediately wake up and 
> exit, instead of you having to wait for however long the sleep 
> operation would take. You can even use the condition of "waiting 
> for this object did NOT return time-out" as your exit condition, 
> for a race condition free way of doing it :-)
 
> Finally, the most dangerous thing with exiting threads is having 
> other threads wait for those threads; unless you design carefully, 
> it's very easy to get into deadlock that way...

Yeah, that can be nasty, but thankfully it's only a single thread and
only one place kills it, basically via:

SetEvent( event );

while ( !gThreadDead ) ; //pray that gThreadDead actually gets set

DeleteSharedData();

Brian

Re: [GD-Windows] Stopping a thread cleanly

[Andrew G. <an...@ra...>]

It's just 'better' really. One case that I can remember is this:


int ThreadFunc()
{
    while (false == bExit)
    {
    }
}

In this case the compiler could put bExit in a register due to optimisation
which obviously isn't good. You could specify it as volatile which will
prevent that, but that seems a bit ugly.

And you have the cases where the compiler might rearrange the order of

bExit=false;
CreateThread();

// andrew

----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Sunday, February 17, 2002 7:37 PM
Subject: [GD-Windows] Stopping a thread cleanly


> Okay, kind of a newbie question, but I thought I understood it, now I'm
> not so sure.
>
> What are the advantages/disadvantages of exiting a thread based on
> WaitForSingleObject with short timeout vs. checking a global variable?
> Both are effectively in a delayed hard polling loop, where the delay is
> a Sleep( 250 ).
>
> The only advantage I can really see is that the WFSO call is going to
> avoid race conditions intrinsically, whereas checking a global variable
> I'll have to be a lot more diligent about guarding accesses to the
> variable.
>
> Brian
>
>
> _______________________________________________
> 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] Stopping a thread cleanly

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

> Which specific kind of synchronization are you doing here?

This is real primitive stuff.  Basically it's a background thread that's
filling a soundbuffer for streaming audio.  Works great, except for the
potential race condition that occurs when I need to shut down the
thread/streaming audio.  To kill the thread I was using a global
variable, which was a bit messy, but I've now switched to
WaitForSingleObject which is a lot cleaner.

I'm using both a critical section and the event -- the critical section
guards against access to the actual streaming buffer and DSound data,
the event is just to signal to the thread to quit.

Off the top of my head, my new loop is something like:

while ( 1 )
{
   //Guard access to the shared data used in DoWork()
   EnterCriticalSection();

   //Make sure that the event wasn't signaled prior to
   //entering the critical section
   if ( WaitForSingleObject( ... ) == WAIT_TIMEOUT )
   {
      DoWork();
      LeaveCriticalSection();
   }
   else
   {
      LeaveCriticalSection();
      break;
   }

   //Sleep for 250ms or until the event is signaled
   //indicating that the thread should die
   if ( WaitForSingleObject( event, 250 ) == WAIT_OBJECT_0 )
   {
      break;
   }
   //Theoretically a thread switch could occur between here
   //and entering the critical section, which is why
   //we check again inside the critical section for the
   //event
}

Brian

RE: [GD-Windows] Stopping a thread cleanly

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

> What are the advantages/disadvantages of exiting a thread based on
> WaitForSingleObject with short timeout vs. checking a global variable?

Someone should teach me to not mis-read other people's 
questions. ;-)

You have a worker thread, and it's gotten time to shut it down? 
Somehow, you're giving this worker thread instructions, so I'd 
suggest sending a shutdown message the same way you send other 
commands to the thread.

I think that either suggestion you have (wait on an object with 
a time-out, versus sleeping) are sub-optimal, because they're 
polling. Instead, you might want to block (for real) on some 
primitive until there is work to do, and make sure that primitive 
gets signalled once work is put in. You may find it easier to 
use a condition variable for this set-up.

Once it's time to exit the thread, you simply set a global (or 
queue a command, or whatever) and wake the thread up; it'll wake 
up and notice there's a quit condition (without re-entering the 
kernel) and go away.

If the worker thread is supposed to asynchronously "pick up" work 
every so often (sometimes necessary) then you should use the time-
out on the wait operation as your throttle for when to look for 
more work. That way, you can signal this event (or whatever) when 
it's time to exit, and the thread will immediately wake up and 
exit, instead of you having to wait for however long the sleep 
operation would take. You can even use the condition of "waiting 
for this object did NOT return time-out" as your exit condition, 
for a race condition free way of doing it :-)

Finally, the most dangerous thing with exiting threads is having 
other threads wait for those threads; unless you design carefully, 
it's very easy to get into deadlock that way...

Cheers,

				/ h+

RE: [GD-Windows] Stopping a thread cleanly

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

The global variable doesn't enter the kernel, whereas the wait 
call does. On the other hand, if the thing is already held, then 
spinning and polling for your entire quanta isn't going to help 
much.

Which specific kind of synchronization are you doing here? I've 
found the Windows critical section to be very efficient, as it 
will not enter the kernel if there isn't contention, and it will 
do some number of spins in user space before entering the kernel 
if you're on a multi-CPU machine, under contention (exactly how 
many is detemined by you). The idea being that if you guard some 
simple operation like manipulating a list head/tail, then a 
thousand spins is likely to make the critical section available, 
and is a lot quicker than entering the kernel.

Sleep is also likely to enter the kernel, and thus is not very 
efficient. Remember that the time quanta is measured in milliseconds 
(actually, the "foreground time slice" can get closer to a hundred 
milliseconds) so anything "spinning" is bad if it's likely to be 
under contention. On the other hand, entering the kernel is also 
bad, because it's likely to cause death by context switching.

Cheers,

				/ h+


> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Brian Hook
> Sent: Sunday, February 17, 2002 11:37 AM
> To: gam...@li...
> Subject: [GD-Windows] Stopping a thread cleanly
> 
> 
> Okay, kind of a newbie question, but I thought I understood it, now I'm
> not so sure.
> 
> What are the advantages/disadvantages of exiting a thread based on
> WaitForSingleObject with short timeout vs. checking a global variable?
> Both are effectively in a delayed hard polling loop, where the delay is
> a Sleep( 250 ).
> 
> The only advantage I can really see is that the WFSO call is going to
> avoid race conditions intrinsically, whereas checking a global variable
> I'll have to be a lot more diligent about guarding accesses to the
> variable.
> 
> Brian
> 
> 
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 

[GD-Windows] Stopping a thread cleanly

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

Okay, kind of a newbie question, but I thought I understood it, now I'm
not so sure.

What are the advantages/disadvantages of exiting a thread based on
WaitForSingleObject with short timeout vs. checking a global variable?
Both are effectively in a delayed hard polling loop, where the delay is
a Sleep( 250 ).

The only advantage I can really see is that the WFSO call is going to
avoid race conditions intrinsically, whereas checking a global variable
I'll have to be a lot more diligent about guarding accesses to the
variable.

Brian

Re: [GD-Windows] SetForegroundWindow failing?

[Andrew G. <an...@ra...>]

Only a foreground process can call SFW, this was introduced by MS in Win98
and later to stop applications stealing the focus. There are other criteria
for SFW but this is probably the one that's tripping you up.

try:

ShowWindow(hWnd, SW_RESTORE);
SetForegroundWindow(hWnd);

// andrew




----- Original Message -----
From: "Brian Hook" <bri...@py...>
To: <gam...@li...>
Sent: Sunday, February 17, 2002 2:12 AM
Subject: [GD-Windows] SetForegroundWindow failing?


> My calls to SetForegroundWindow() are mysteriously failing.  On Win2K
> I'm getting GetLastError() of 0; on Win98, I get error 87
> (E_INVALIDPARMS).  The hWnd is valid.
>
> Any ideas what might cause this?
>
> Thanks,
>
> Brian
>
>
> _______________________________________________
> Gamedevlists-windows mailing list
> Gam...@li...
> https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_id=555
>

[GD-Windows] SetForegroundWindow failing?

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

My calls to SetForegroundWindow() are mysteriously failing.  On Win2K
I'm getting GetLastError() of 0; on Win98, I get error 87
(E_INVALIDPARMS).  The hWnd is valid.

Any ideas what might cause this?

Thanks,

Brian

RE: [GD-Windows] handling task switch

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

If you don't have a stack trace, here's a trick I often use to
bring clarity:

1) find the "ret" instruction following the crash location
2) count the amount of data popped off the stack between crash
   and ret
3) add that much to stack pointer
4) set eip to the ret instruction
5) single-step
6) repeat, until you're back in your own application

Sometimes it can be hard to figure out the correct offset for
esp. Then you can instead walk up the stack, looking for pointers
that look like they point into your code, and drag those values
into the disassembly view to figure out if you guessed right or
not.

All of this is vastly simpler if you set your memory display
window to show 4 longwords to the line (and anchor it at esp).

Cheers,

			/ h+

> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Ignacio Castaño
> Sent: Tuesday, February 12, 2002 3:18 PM
> To: gam...@li...
> Subject: [GD-Windows] handling task switch
>
>
> Hi again,
> I have the code for reloading resources and restarting devices
> ready, and it
> works fine. However, when I run it in response to WM_ACTIVATEAPP,
> it doesn't
> work, and produces a very strange crash. The vc debugger doesn't provide a
> stack trace at all, just a invalid call at an unknown dir. Maybe I'm not
> using the correct message... where should I handle the task switch? in
> WM_ACTIVATE? WM_KILLFOCUS?
>
> Any hints would be appreciated.
>
>
> Ignacio Castaño
> ca...@as...
>
>
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.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] handling task switch

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

Sorry for this message, after sending it I realized it's an OpenGL question
only, since in DirectX there is a method of testing and acquiring lost
devices and in OpenGL not. So I have to prevent that by releasing the device
and reloading it later. Anyway, if somebody has an answer or an experience
to share, please send it directly to me.


Ignacio Castaño
ca...@as...


Ignacio Castaño wrote:
> Hi again,
> I have the code for reloading resources and restarting devices ready, and
it
> works fine. However, when I run it in response to WM_ACTIVATEAPP, it
doesn't
> work, and produces a very strange crash. The vc debugger doesn't provide a
> stack trace at all, just a invalid call at an unknown dir. Maybe I'm not
> using the correct message... where should I handle the task switch? in
> WM_ACTIVATE? WM_KILLFOCUS?
>
> Any hints would be appreciated.




_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[GD-Windows] handling task switch

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

Hi again,
I have the code for reloading resources and restarting devices ready, and it
works fine. However, when I run it in response to WM_ACTIVATEAPP, it doesn't
work, and produces a very strange crash. The vc debugger doesn't provide a
stack trace at all, just a invalid call at an unknown dir. Maybe I'm not
using the correct message... where should I handle the task switch? in
WM_ACTIVATE? WM_KILLFOCUS?

Any hints would be appreciated.


Ignacio Castaño
ca...@as...



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [GD-Windows] os version

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

Sure but I was thinking of something more like pseudo-code for those parts.
Exactly like what you wrote : "here, restore lost surfaces, re-load
textures, etc".

Oh, well.

----- Original Message -----
From: Jon Watte <hp...@mi...>
To: <gam...@li...>
Sent: Tuesday, February 12, 2002 7:17 PM
Subject: RE: [GD-Windows] os version


>
> The problem is that the painful code is rather tightly integrated
> with your texture management and render target system. Restoring
> lost surfaces, re-loading texture image and whatnot is not exactly
> the kind of code that you can slap in an FAQ :-(
>
> Cheers,
>
> / h+
>
> > > This topic always causes flame wars. :-)
> >
> > Yeah and it's boring. Someone cool should write the painful code once
and
> > for all, put it somewhere on the net, answer the question in some FAQ,
end
> > of story.
>
>
>
> _______________________________________________
> 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] os version

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

The problem is that the painful code is rather tightly integrated
with your texture management and render target system. Restoring
lost surfaces, re-loading texture image and whatnot is not exactly
the kind of code that you can slap in an FAQ :-(

Cheers,

			/ h+

> > This topic always causes flame wars. :-)
>
> Yeah and it's boring. Someone cool should write the painful code once and
> for all, put it somewhere on the net, answer the question in some FAQ, end
> of story.

Re: [GD-Windows] os version

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

Brian Hook wrote:
> Oh, hey, that sounds familiar! =)
>
> Can you post that code, by any chance?  I'm actually working on a game
> for infants/toddlers that needs to have "button mash" mode enabled, i.e.
> they have to be able to hit ANYTHING except ctrl-alt-delete.  The Win
> key completely screws up this kind of "game".

Do you want me to post your code??

The os detection is in quake2/win32/sys_win.c function Sys_Init, line 234
The mentioned functions are in quake2/win32/vid_dll.c lines 68 & 87

I've attached my own version that includes other key variants and a
different method mentioned in the msdn.


> A code snippet to disable all keys on all Windows variants would
> actually be something very useful for the archives.

I agree, but it seems that you cannot do that with windows keys under win2k
:-(


Ignacio Castaño
ca...@as...

Re: [GD-Windows] disabling windows keys

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

Rich wrote:
> So make it a configurable option and everyone is happy.  People who
> want the Windows key to work get it to work and people who want to
> disable it get it disabled.  Disabling the Windows key is -entirely-
> different from disabling task-switching IMO.

I completely agree with that, I will just leave that as an option and handle
task switching correctly. However disabling windows keys would still be
usefull anyway.


Ignacio Castaño
ca...@as...



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

Re: [GD-Windows] os version

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

Jon Watte wrote:
> I am surprised by that. Well, as long as it isn't ATI drivers.
> Many OGL programs (like Maya, or 3DSMax, or ...) will not work
> well if you have those kinds of bugs.

yes, it's with ATI drivers only.


Ignacio Castaño
ca...@as...



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

RE: [GD-Windows] os version

[Tom F. <to...@mu...>]

I suspect the DX FAQ's opinion on this this could be expanded slightly:

Q: How do I disable ALT+TAB and other task switching?
A: You don't. Really.

(http://msdn.microsoft.com/library/techart/DirectX8faq.htm)


It's absolutely correct of course. The fundamental problem is that the
number of apps that don't handle loss of focus correctly is huge, and they
really don't want to encourage people to continue this sort of lazy coding
by letting them delude themselves that you can actually prevent loss of
focus. You can see where they're coming from.

Sounds like something suitable for a Games Programming Gem or a Gamasutra
article to me.


Tom Forsyth - purely hypothetical Muckyfoot bloke.

This email is the product of your deranged imagination,
and does not in any way imply existence of the author.



> -----Original Message-----
> From: Pierre Terdiman [mailto:p.t...@wa...]
> Sent: 12 February 2002 13:27
> To: gam...@li...
> Subject: Re: [GD-Windows] os version 
> 
> 
> > This topic always causes flame wars. :-)
> 
> Yeah and it's boring. Someone cool should write the painful 
> code once and
> for all, put it somewhere on the net, answer the question in 
> some FAQ, end
> of story.
> 
> Thinking about it, maybe R. Dunlop already has something 
> related on his
> site. Else it would be a nice new article to write. Gonna check.
> 
> 
> _______________________________________________
> 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] os version

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

> This topic always causes flame wars. :-)

Yeah and it's boring. Someone cool should write the painful code once and
for all, put it somewhere on the net, answer the question in some FAQ, end
of story.

Thinking about it, maybe R. Dunlop already has something related on his
site. Else it would be a nice new article to write. Gonna check.

RE: [GD-Windows] os version

[Tom F. <to...@mu...>]

Agreed. Make it a user-selectable option to disable Windows keys (I think
I've seen maybe two games with this - far too low a number), and _even if
it's selected_, handle loss of focus properly. I've lost count of the number
of games that have died because they gently prodded the internet, at which
point ZoneAlarm pops up and says "this program wants to talk to the net - do
you want it to let it?", forcing an Alt+Tab type behaviour which for most
apps toasts the machine (on Win98 - Win2k is much better at recovering
without a BSOD).

-Allow Alt+Tab, Ctrl+Alt+Delete, Windows key, etc.
-Give users an option to tick to disable the keys.
-Always handle loss of focus even if they tick the option.

This topic always causes flame wars. :-)


Tom Forsyth - Muckyfoot bloke.

What's he up to now (and can I have a go)?
http://www.eidosinteractive.com/downloads/search.html?gmid=86

> -----Original Message-----
> From: Matt Davies [mailto:ma...@co...]
> Sent: 12 February 2002 10:29
> To: Rich; gam...@li...
> Subject: RE: [GD-Windows] os version 
> 
> 
> I must say I completely agree with Rich.  I am so tired of 
> games that crash
> when I try to Alt-TAB to another application like my mail 
> client.  Well done
> to games like System Shock 2 and Diablo II that pause the 
> game automatically
> and handle it properly.  In Diablo II I occasionally press 
> TAB (for the map)
> and ALT (for seeing items) at the same time and switch out, 
> but since the
> game is paused its harmless and much more preferable to not 
> being able to
> task switch or, even worse, to crashing.  If I really didn't 
> like it, I
> could redefine the controls so I didn't have to use TAB anyway.
> 
> 
> Matt Davies
> Programmer, Confounding Factor
> ma...@co...
> www.confounding-factor.com
> 
> 
> 
> > -----Original Message-----
> > From: gam...@li...
> > [mailto:gam...@li...]On 
> Behalf Of
> > Rich
> > Sent: 12 February 2002 02:49
> > To: gam...@li...
> > Subject: Re: [GD-Windows] os version
> >
> >
> >
> > In article <001c01c1b368$4aab5e40$7f55533e@aurora>,
> >     =?iso-8859-1?Q?Ignacio_Casta=F1o?= <cas...@ya...>  writes:
> >
> > > Hmm... I just want to disable Alt+tab and other task 
> switching keys,
> >
> > Windows is not a Console system.  You don't own the OS, the 
> user owns
> > the OS.  Just deal with task switching and don't bother coding all
> > kinds of buggy OS version code.  If the user wants to task 
> switch away
> > from your application, who are you to defy the user?
> > --
> > Ask me about my upcoming book on Direct3D from Addison-Wesley!
> >   Direct3D Book <http://www.xmission.com/~legalize/book/>
> >     Don't Support Spammers!  Boycott Fractal Painter 7!
> >      <http://www.xmission.com/~legalize/spammers.html>
> >
> > _______________________________________________
> > Gamedevlists-windows mailing list
> > Gam...@li...
> > https://lists.sourceforge.net/lists/listinfo/gamedevlists-windows
> > Archives:
> > http://sourceforge.net/mailarchive/forum.php?forum_id=555
> 
> 
> _______________________________________________
> 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] os version

[Matt D. <ma...@co...>]

I must say I completely agree with Rich.  I am so tired of games that crash
when I try to Alt-TAB to another application like my mail client.  Well done
to games like System Shock 2 and Diablo II that pause the game automatically
and handle it properly.  In Diablo II I occasionally press TAB (for the map)
and ALT (for seeing items) at the same time and switch out, but since the
game is paused its harmless and much more preferable to not being able to
task switch or, even worse, to crashing.  If I really didn't like it, I
could redefine the controls so I didn't have to use TAB anyway.


Matt Davies
Programmer, Confounding Factor
ma...@co...
www.confounding-factor.com



> -----Original Message-----
> From: gam...@li...
> [mailto:gam...@li...]On Behalf Of
> Rich
> Sent: 12 February 2002 02:49
> To: gam...@li...
> Subject: Re: [GD-Windows] os version
>
>
>
> In article <001c01c1b368$4aab5e40$7f55533e@aurora>,
>     =?iso-8859-1?Q?Ignacio_Casta=F1o?= <cas...@ya...>  writes:
>
> > Hmm... I just want to disable Alt+tab and other task switching keys,
>
> Windows is not a Console system.  You don't own the OS, the user owns
> the OS.  Just deal with task switching and don't bother coding all
> kinds of buggy OS version code.  If the user wants to task switch away
> from your application, who are you to defy the user?
> --
> Ask me about my upcoming book on Direct3D from Addison-Wesley!
>   Direct3D Book <http://www.xmission.com/~legalize/book/>
>     Don't Support Spammers!  Boycott Fractal Painter 7!
>      <http://www.xmission.com/~legalize/spammers.html>
>
> _______________________________________________
> 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] disabling windows keys

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

>     This is just my two cents here, but personally I can't stand
> it when you
> bump a windows key while playing a game and it jumps right out in order to
> open the start menu or whatever (and it always seems to happen at the most

Buy a Microsoft keyboard. It comes with a special (better) input
control panel which allows you to disable those two Evil Keys of
Death: windows key and caps lock.

At least MacOS and BeOS has/had the decency to treat the key
between control and alt as a modifier, not as a character...

Cheers,

			/ h+

Re: [GD-Windows] disabling windows keys

[Rich <leg...@xm...>]

In article <OE7...@ho...>,
    "Lachlan Littlemore" <da_...@ho...>  writes:

>     This is just my two cents here, but personally I can't stand it when you
> bump a windows key while playing a game and it jumps right out in order to
> open the start menu or whatever (and it always seems to happen at the most
> unapropriate times =).

So make it a configurable option and everyone is happy.  People who
want the Windows key to work get it to work and people who want to
disable it get it disabled.  Disabling the Windows key is -entirely-
different from disabling task-switching IMO.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    Don't Support Spammers!  Boycott Fractal Painter 7!
     <http://www.xmission.com/~legalize/spammers.html>

Re: [GD-Windows] disabling windows keys

[Lachlan L. <da_...@ho...>]

    This is just my two cents here, but personally I can't stand it when you
bump a windows key while playing a game and it jumps right out in order to
open the start menu or whatever (and it always seems to happen at the most
unapropriate times =). If you ask me, as long as the game isn't running in
windowed mode, it should be able to trap the windows keys. If the player
wants to use other windows operations then maybe they can run the game in
windowed mode or something. There should at least be an option to turn
windows keys off.

    Hope I didn't kick up an ant-hill here =)

    - Lachlan

----- Original Message -----
From: Rich <leg...@xm...>
To: <gam...@li...>
Sent: Tuesday, February 12, 2002 1:50 PM
Subject: Re: [GD-Windows] disabling windows keys


>
> In article <002c01c1b36b$7cee2920$7f55533e@aurora>,
>     =?iso-8859-1?Q?Ignacio_Casta=F1o?= <cas...@ya...>  writes:
>
> > Ok, I got rid of alt+tab, ctrl+esc, and alt+esc key combinations, but
the
> > user is still able to switch the task just by pressing any windows keys.
> > Does somebody know how to disable them?
>
> Please tell me what title you're working on so I know to recommend
> people to stay away from it.  I can't stand games that try to disable
> functionality that I -expect- to work on my PC.  This philosophy is
> the same one that gives us all those "NetMeeting disabled D3D"
> problems.
> --
> Ask me about my upcoming book on Direct3D from Addison-Wesley!
>   Direct3D Book <http://www.xmission.com/~legalize/book/>
>     Don't Support Spammers!  Boycott Fractal Painter 7!
>      <http://www.xmission.com/~legalize/spammers.html>
>
> _______________________________________________
> 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] disabling windows keys

[Rich <leg...@xm...>]

In article <002701c1b371$6b163b60$0101a8c0@HOOKDELL220>,
    Brian Hook <bri...@py...>  writes:

> - when alt and tab may be used as a key combination in the game.  cf.
> Quake.  And if you want to argue that this is "bad UI design", to
> paraphrase you -- if the user wants to do something, who are we to say
> "No, alt + tab is an invalid key combination".

I think there is a difference between disabling Alt+Tab because the
user has controls mapped to that configuration and the general issue
of disabling alt+tab because programmers don't want to handle lost
devices.  99.999% of the time I see people asking how to disable task
switching its for the latter reason, not the former.  The latter is
-not- an example of the user asking for something, its the programmer
forcing something on the user because they appear to be too lazy to
program the correct solution.

> - "games" where the keyboard needs to be "locked down" because you have
> an 18 month old toddler banging on keys to see pretty lights happen on
> the monitor

Has it yet been established that this is the case here?  This comes up
all the time in DirectX discussion forums.  A certain amount of
laziness is good in a programmer, but when the laziness leads to the
programmer trying to stop the user from doing normal things because
they can't handle it properly that is just shoddy programming IMO.
The world already has enough crappy programs, we should be focusing on
giving users GREAT programs.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
  Direct3D Book <http://www.xmission.com/~legalize/book/>
    Don't Support Spammers!  Boycott Fractal Painter 7!
     <http://www.xmission.com/~legalize/spammers.html>

RE: [GD-Windows] disabling windows keys

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

With all due respect Rich, you're particular world view isn't going to
necessarily match everyone else's.

Sure, disabling Alt-tab as a general rule is a Bad Idea, but there are
at least two valid cases where it makes sense:

- when alt and tab may be used as a key combination in the game.  cf.
Quake.  And if you want to argue that this is "bad UI design", to
paraphrase you -- if the user wants to do something, who are we to say
"No, alt + tab is an invalid key combination".

- "games" where the keyboard needs to be "locked down" because you have
an 18 month old toddler banging on keys to see pretty lights happen on
the monitor

Brian