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

Re: [GD-Windows] Input thread

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

> Is there any reason why you'd rather write a multithreaded keyboard system
> rather than using windows messages or buffered DirectInput?

Honestly, I don't know. It's been a long time now, but one year ago (or
maybe two) I was using Windows messages in that part of the code, and IIRC I
ran into some problems of lost messages. Typically, the "key up" event
sometimes was never caught, so for example :
- on key down, I was sending a message to a state machine, that eventually
made the character walk
- key up event was missed
- the character kept walking forever

That's why I switched to GetAsyncKeyState() in the first place : no
messages, just read key status when needed, no problem (at least, no
immediate problem).

Now, if you all say Windows messages are just fine and can't ever be missed,
I probably will try it again. It's very possible the bug was somewhere else
(as you see, I'm not exactly working hard on this project since it's already
years-old). Usually I don't have to deal with game input code (not exactly
needed in my job), that's why I also wanted to avoid DirectInput.

Anyway, you pretty much all answered my question : no, what I had in mind
isn't a standard thing to do. I suppose Thatcher went that way because it's
not a Windows guy, to begin with. Answering your question, that would be "a
reason". Maybe the only one.

- Pierre

Re: [GD-Windows] Input thread

[Javier A. <ja...@py...>]

Pierre Terdiman wrote:
>> I haven't tried that myself either, but Thatcher has some code
>> snipplets and some notes about that:
>>
>> http://www.tulrich.com/geekstuff/
>
> Thanks, looks exactly like what I wanted....

Is there any reason why you'd rather write a multithreaded keyboard system
rather than using windows messages or buffered DirectInput?

  Javier Arevalo
  Pyro Studios

Re: [GD-Windows] Input thread

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

> I haven't tried that myself either, but Thatcher has some code snipplets
and
> some notes about that:
>
> http://www.tulrich.com/geekstuff/

Thanks, looks exactly like what I wanted....

[GD-Windows] OT - Game Development Professionals Network

[Nalin S. <ns...@vs...>]

Hi,

This is Nalin Savara here.

I"ve just created a network on Ryze.com (see: http://www.ryze.com ) which is
a premier business network site that's called "GameDevPros" or the "Game
Development Professionals Network" to serve as an online meeting place for
game development professionals of all backgrounds to network, meet and
discuss and exchange ideas and opportunities and support each other in
meeting challenges.

Right now, it's somewhat small, since I've just created it; but your
participation I guess is the only thing it's waiting for.

Do check it out and become part of it.

This network has game designers, programmers, digital artists, animators,
producers, audio engineers, and management & marketing specialists as
members. This is where experts feed their minds with ideas, discussions and
contacts and discuss new gaming methods, technologies and business models.

Regards,
Nalin Savara
CEO and Technical Director,
Darksun Technologies Pvt Ltd.
http://www.darksuntech.com
ns...@da...

Ph: +91-9811109407

Re: [GD-Windows] Input thread

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

What's wrong with calling GetKeyState instead of GetAsyncKeyState?
-- 
"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>

Re: [GD-Windows] Input thread

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

I haven't tried that myself either, but Thatcher has some code snipplets and
some notes about that:

http://www.tulrich.com/geekstuff/



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


Pierre Terdiman wrote:
> Hi,
>
> Here's an old question of mine I never really solved (since it was for
some
> home project I never find enough time to work on :
> www.codercorner.com/Oni.htm)
>
> The question is about keyboard input management, on Windows. The trouble
is
> when you rely on multiple keys beeing pressed in a sequence, to do a combo
> (like in a fighting game).
>
> Currently I use GetAsyncKeyState() and do my own little analysis to detect
> combos. It works well as long as framerate is ok, since I only query
> keyboard values on-the-fly, each frame.
>
> As soon as framerate drops, it happens that some combos are missed, and
> overall controls appear a bit laggy & not responding wery well.
>
> I read somewhere an old MSDN article from 1996 (that I can't seem to find
> again) that advocated the use of a separate thread (actually a multimedia
> timer, as in timeSetEvent) to read keyboard values at a fixed rate.
>
> It sounds like a good idea indeed, but I never bothered implementing it,
> since it also sounds a bit overkill. So before I give it a try, my 2
> questions are :
>
> - is this a standard thing to do ?
> - is this still relevant nowadays, or is there a better alternative ? (in
> particular, using multimedia timers might be an obsolete thing, superseded
> by DirectInput maybe. But I'd like to avoid D.I. since otherwise I never
> needed it in this particular project).

RE: [GD-Windows] Input thread

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

> - is this a standard thing to do ?

It works awright. I've not actually needed it, though; we're using=20
Windows key events and they work very well (and give you sequencing!)

Note that multimedia timers (and threads, in general) may only be=20
as accurate as your hardware devices on Windows 98, which may mean=20
20 milliseconds jitter. Sampling the keyboard 100 times a second=20
would be plenty...

Cheers,

				/ h+

[GD-Windows] Input thread

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

Hi,

Here's an old question of mine I never really solved (since it was for some
home project I never find enough time to work on :
www.codercorner.com/Oni.htm)

The question is about keyboard input management, on Windows. The trouble is
when you rely on multiple keys beeing pressed in a sequence, to do a combo
(like in a fighting game).

Currently I use GetAsyncKeyState() and do my own little analysis to detect
combos. It works well as long as framerate is ok, since I only query
keyboard values on-the-fly, each frame.

As soon as framerate drops, it happens that some combos are missed, and
overall controls appear a bit laggy & not responding wery well.

I read somewhere an old MSDN article from 1996 (that I can't seem to find
again) that advocated the use of a separate thread (actually a multimedia
timer, as in timeSetEvent) to read keyboard values at a fixed rate.

It sounds like a good idea indeed, but I never bothered implementing it,
since it also sounds a bit overkill. So before I give it a try, my 2
questions are :

- is this a standard thing to do ?
- is this still relevant nowadays, or is there a better alternative ? (in
particular, using multimedia timers might be an obsolete thing, superseded
by DirectInput maybe. But I'd like to avoid D.I. since otherwise I never
needed it in this particular project).


- Pierre

Re: [GD-Windows] Troubles with Win32 slider

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

>Here's code from a wrapper I wrote for personal use a long time 

Thanks, it worked.

Mailing lists, great invention :)

Pierre

RE: [GD-Windows] Troubles with Win32 slider

[Mitch W. <mi...@mi...>]

And had I read more closely, I would have realized you didn't mean =
scrollbars. :P=20

-----Original Message-----
From: "Pierre Terdiman" <p.t...@wa...>
Sent: 5/27/03 5:53:00 PM
To: "gam...@li..." =
<gam...@li...>
Cc:=20
Subject: [GD-Windows] Troubles with Win32 slider

I put a vanilla Win32 slider in a dialog (in VC6's resource editor), and =
I can't seem to get it work.

This is probably very easy once you know how to do it, but neither the =
MSDN nor Google seems to answer this basic question clearly : how do I =
get back the slider's position ? (!)

Note that :
- For checkboxes or radio buttons it worked like a charm using, for =
example, IsDlgButtonChecked(). I'm looking for similar brain-dead =
functions to handle sliders.
- I don't want to / can't use MFC here.
- I tried to catch various messages in the parent window, =
GetScrollPos(), etc, nothing seems to work.

I'll appreciate a small overview, or a working link to a decent =
tutorial.

Thanks,

- Pierre
www.codercorner.com

RE: [GD-Windows] Troubles with Win32 slider

[Mitch W. <mi...@mi...>]

Search MSDN for "Scroll Bar Controls in Win32". The message I think you =
are interested in is SBM_GETPOS.

-----Original Message-----
From: "Pierre Terdiman" <p.t...@wa...>
Sent: 5/27/03 5:53:00 PM
To: "gam...@li..." =
<gam...@li...>
Cc:=20
Subject: [GD-Windows] Troubles with Win32 slider

I put a vanilla Win32 slider in a dialog (in VC6's resource editor), and =
I can't seem to get it work.

This is probably very easy once you know how to do it, but neither the =
MSDN nor Google seems to answer this basic question clearly : how do I =
get back the slider's position ? (!)

Note that :
- For checkboxes or radio buttons it worked like a charm using, for =
example, IsDlgButtonChecked(). I'm looking for similar brain-dead =
functions to handle sliders.
- I don't want to / can't use MFC here.
- I tried to catch various messages in the parent window, =
GetScrollPos(), etc, nothing seems to work.

I'll appreciate a small overview, or a working link to a decent =
tutorial.

Thanks,

- Pierre
www.codercorner.com

RE: [GD-Windows] Troubles with Win32 slider

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

The slider will send you WM_SCROLL messages. Actually, working=20
with sliders in Win32, I've found to be a pain in the butt,=20
because they're so different from many other controls.

Here's code from a wrapper I wrote for personal use a long time=20
ago:

  virtual int value()
    {
      return SendMessage( controlWindow_->window()->hWnd(), TBM_GETPOS, =
0, 0 );
    }
  virtual void setValue( int v )
    {
      LRESULT lr =3D SendMessage( controlWindow_->window()->hWnd(), =
TBM_SETPOS, TRUE, v );
    }

Cheers,

                / h+

-----Original Message-----
From: gam...@li... =
[mailto:gam...@li...]On Behalf Of =
Pierre Terdiman
Sent: Tuesday, May 27, 2003 2:46 PM
To: gam...@li...
Subject: [GD-Windows] Troubles with Win32 slider


I put a vanilla Win32 slider in a dialog (in VC6's resource editor), and =
I can't seem to get it work.

This is probably very easy once you know how to do it, but neither the =
MSDN nor Google seems to answer this basic question clearly : how do I =
get back the slider's position ? (!)

Note that :
- For checkboxes or radio buttons it worked like a charm using, for =
example, IsDlgButtonChecked(). I'm looking for similar brain-dead =
functions to handle sliders.
- I don't want to / can't use MFC here.
- I tried to catch various messages in the parent window, =
GetScrollPos(), etc, nothing seems to work.

I'll appreciate a small overview, or a working link to a decent =
tutorial.

Thanks,

- Pierre
www.codercorner.com

RE: [GD-Windows] Troubles with Win32 slider

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

Trackbar is the correct name for the control I think you mean, that should
help you find the correct section in MSDN.
 
If not, all the messages are prefixed TBM_ and it's similar in concept to a
scrollbar.

-----Original Message-----
From: Pierre Terdiman [mailto:p.t...@wa...] 
Sent: 27 May 2003 14:46
To: gam...@li...
Subject: [GD-Windows] Troubles with Win32 slider


I put a vanilla Win32 slider in a dialog (in VC6's resource editor), and I
can't seem to get it work.
 
This is probably very easy once you know how to do it, but neither the MSDN
nor Google seems to answer this basic question clearly : how do I get back
the slider's position ? (!)
 
Note that :
- For checkboxes or radio buttons it worked like a charm using, for example,
IsDlgButtonChecked(). I'm looking for similar brain-dead functions to handle
sliders.
- I don't want to / can't use MFC here.
- I tried to catch various messages in the parent window, GetScrollPos(),
etc, nothing seems to work.
 
I'll appreciate a small overview, or a working link to a decent tutorial.
 
Thanks,
 
- Pierre
www.codercorner.com <http://www.codercorner.com> 

[GD-Windows] Troubles with Win32 slider

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

I put a vanilla Win32 slider in a dialog (in VC6's resource editor), and =
I can't seem to get it work.

This is probably very easy once you know how to do it, but neither the =
MSDN nor Google seems to answer this basic question clearly : how do I =
get back the slider's position ? (!)

Note that :
- For checkboxes or radio buttons it worked like a charm using, for =
example, IsDlgButtonChecked(). I'm looking for similar brain-dead =
functions to handle sliders.
- I don't want to / can't use MFC here.
- I tried to catch various messages in the parent window, =
GetScrollPos(), etc, nothing seems to work.

I'll appreciate a small overview, or a working link to a decent =
tutorial.

Thanks,

- Pierre
www.codercorner.com

[GD-Windows] (no subject)

[Michael A. <man...@ro...>]

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+

ATI data was Re: [GD-Windows] Some multimon data

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

Here's another sample point submitted by someone else for an ATI=
 
Radeon 8500 dual head.

GetSystemMetrics( SM_CMONITORS ) reports 2 monitors

\\.\DISPLAY1, "RADEON 8500 SERIES", attached, primary
   \\.\DISPLAY1\Monitor0, "Plug and Play Monitor"
      - attached
   \\.\DISPLAY1\Monitor1, "Plug and Play Monitor"
      - attached, multidriver
\\.\DISPLAY2, "RADEON 8500 SERIES", attached
   \\.\DISPLAY2\Monitor0, "Plug and Play Monitor"
      - attached, multidriver
   \\.\DISPLAY2\Monitor1, "Plug and Play Monitor"
      - attached

This is fairly alarming, because to a naive multimon inspection=
 it 
looks like there are two adapters, each with two monitors.  Both=
 
adapters are marked as attached, and each has two attached=
 monitors.  
The only difference is that the "multidriver" bit is set in the=
 flags 
field, which NVidia does not set anywhere that I'm aware of.

This isn't a documented bit for the DISPLAY_DEVICE::StateFlags 
structure, so I'm not even sure what it means other than it's=
 related 
to multihead adapters somehow?

Brian

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

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

I wonder gow the Matrox drivers solve this - I know that Serious Sam had an
option to render on two displays simmultaneously using when some Matrox c
----- 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

[Eero P. <epa...@ko...>]

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

[GD-Windows] Some multimon data

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

I hacked up a quick multimon information extractor (GDI only, no=
 DX 
stuff) and ran it on some of my multimon systems to see what 
interesting information I could glean (or not).

These are all Win2K systems, I'm not sure what happens on XP or 
Win98, but since the APIs are the same I'm assuming that it won't=
 do 
anything too out of whack.  Win98 is my biggest concern since=
 it's a 
different driver model.

System #1: GF3/AGP + Rage128/PCI + TNT2/PCI

GetSystemMetrics( SM_CMONITORS ) =3D 3
\\.\DISPLAY1
   - "NVIDIA GeForce3", attached, primary
   - \\.\DISPLAY1\Monitor0, "Plug and Play Monitor"
      - attached, 181 video modes
\\.\DISPLAY2
   - "Xpert 128", attached
   - \\.\DISPLAY2\Monitor0, "Default Monitor"
      - attached, 210 video modes
\\.\DISPLAY3
   - NVIDIA RIVA TNT2 Mode 64/Model 64 Pro, attached
   - \\.\DISPLAY3\Monitor0, "Default Monitor"
      - attached, 336 video modes
\\.\DISPLAY5
   - NetMeeting driver

That is a pretty sane system.

System #2a: GF4 Ti4200, single virtual desktop

GetSystemMetrics( SM_CMONITORS ) =3D 1
\\.\DISPLAY1
   - "NVIDIA GeForce4 Ti 4200", attached, primary
   - \\.\DISPLAY1\Monitor0, "Plug and Play Monitor"
      - NOT attached, 217 video modes, 2560x1024
\\.\DISPLAY3
   - "NetMeeting Driver"

Pretty bizarre all the way around.  Only a single monitor, only a=
 
single adapter found, and the monitor on DISPLAY1 is listed as 
"unattached", which is either a bug or clearly something I don't=
 
understand.

Next I configured it the same as above, but turned off one of the=
 
desktops, which _should_ make it seem like a complete single=
 monitor 
system.

System #2b: GF4 Ti4200, second monitor not enabled
GetSystemMetrics( SM_CMONITORS ) =3D 1
\\.\DISPLAY1
   - "NVIDIA GeForce4 Ti 4200", attached, primary
   - \\.\DISPLAY1\Monitor0, "Default Monitor"
   - \\.\DISPLAY1\Monitor1, "Default Monitor"
   - \\.\DISPLAY1\Monitor2, "Plug and Play Monitor"
   - \\.\DISPLAY2\Monitor3, "Plug and Play Monitor"
      - attached, 181 video modes
\\.\DISPLAY2
   - "NVIDIA Dualview", not attached
   - \\.\DISPLAY1\Monitor0, "Default Monitor"
   - \\.\DISPLAY1\Monitor1, "Default Monitor"
   - \\.\DISPLAY1\Monitor2, "Plug and Play Monitor"
      - attached, 275 video modes
   - \\.\DISPLAY2\Monitor3, "Plug and Play Monitor"
\\.\DISPLAY4
   - "NetMeeting Driver"

Well, this is a lot weirder than I was expecting.  The first big=
 
thing is that there are four monitors enumerated.  The second=
 thing 
is that it looks like there are two adapters in the system, when=
 
there's only one.  So long as the code observes "primary only 
adapters and attached monitors", it should be okay.

Finally I turned on the checkbox for "Treat each output as a=
 separate 
video device" (or whatever it's called).

System #2c: GF4 Ti4200, "independent" outputs, dual head
GetSystemMetrics( SM_CMONITORS ) =3D 2
\\.\DISPLAY1
   - "NVIDIA GeForce4 Ti 4200", attached, primary
   - \\.\DISPLAY1\Monitor0, "Default Monitor"
   - \\.\DISPLAY1\Monitor1, "Default Monitor"
   - \\.\DISPLAY1\Monitor2, "Plug and Play Monitor"
   - \\.\DISPLAY2\Monitor3, "Plug and Play Monitor"
      - attached, 181 video modes
\\.\DISPLAY2
   - "NVIDIA Dualview", attached
   - \\.\DISPLAY1\Monitor0, "Default Monitor"
   - \\.\DISPLAY1\Monitor1, "Default Monitor"
   - \\.\DISPLAY1\Monitor2, "Plug and Play Monitor"
      - attached, 275 video modes
   - \\.\DISPLAY2\Monitor3, "Plug and Play Monitor"

Finally, a little bit of sanity -- this works just like #2b,=
 except 
the second display is marked as attached.

So the heuristic that I'll probably use:

if more than one monitor reported
   enumerate monitors
      get primary
         get attached
else
   if aspect ratio is > 2:1
      assume single virtual desktop multimon system
   else
      treat as a regular old single head system

The major thing is that you just have to let the user choose to=
 run 
windowed for the SVD configuration or let them select "Don't=
 change 
video modes" or something similar.  That's just a shitty=
 situation to 
be in unfortunately.

Brian

Re: [GD-Windows] More multimon

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

In article <2003330172253.380519@HOOKDELL220>,
    Brian Hook <bri...@py...>  writes:

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

Make sure you tell nvidia.

NVidia has this annoying habit of trying to "fix things" for the
developer that don't need fixing.  Like you write code that's
incorrect and the driver "fixes" it for you behind your back, leaving
you oblivious to the dormant bug hiding in your code.  This sort of
thing just creates more problems than it solves, IMO, and leads to the
creation of more poorly written programs rather than less.
-- 
"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>

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] More multimon

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

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

That's part of the heuristic I will end up using.  I think the=
 Apple 
Cinema Displays are the stretchiest out there.

>No other special casing. This takes care of 95% of the special
>cases (which are only 5% of all users to begin with -- tops!)

That's a good point, but as a multimon user, I have a personal 
interest in the matter, especially after having played several=
 games 
now that try to center themselves right between my monitors.

>consumers won't be confused by an array of senseless check boxes=
 and
> popup menus ;-)

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.

As a short term hack I'll probably just have a check box in=
 graphics 
options to allow windowed mode along with a "use current screen 
resolution" check box which I'll use as a cue to do the centered=
 
window thing.

Brian

RE: [GD-Windows] More multimon

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

> Multi-monitor support is a bit of a mess.

My heuristic is that if the display is wider than 16:9 form factor,=20
it's probably two displays side-by-side, and I treat it according=20
to that. No other special casing. This takes care of 95% of the=20
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=20
user can determine what monitor for you to use, and what mode to set=20
it in, and where to put the viewport on that monitor. Document it for=20
the ten people who care to find it, and all your mass market=20
consumers won't be confused by an array of senseless check boxes and=20
popup menus ;-)

Cheers,

			/ h+