gamedevlists-windows

[GD-Windows] Complex GUIs

[Brett B. <res...@ga...>]

Hello,
Hope this is the correct forum to post this. We currently develop PS2 =
and GameCube titles and our Windows programming is limited to tools so =
far. Also, we have only made "twitch" games for consoles before, so the =
idea of doing something more complex leads us to wonder how much of the =
low-level to-the-metal approach we should give up.

If we wanted to do a complex GUI for a Windows game, on the order of an =
MMORPGs (toolbars, menus, windows, buttons, lists, etc.), would it be =
best to:
1. Use Windows native functions but overriding the drawing, etc. with =
hooks to render a game interface instead of windows default application =
interface.
2. Use a third party gui widget toolkit and put in our own rendering =
functions to render the widgets.
3. Just do it how we do on consoles and use a thin, lightweight GUI =
built over the immediate mode toolkit.

The second related part (or maybe this should come first?) would be the =
event system that the above is all hooked up into. Would you:
1. Use Windows native event/messaging to drive the gui.
2. Use Direct Input and develop you own event messaging to drive the =
gui.
3. ???

As an example, I was particularly impressed with Star Wars Galaxies GUI =
and that would be a good example of the different kinds of things we =
want a gui to do.

Thanks,
Brett

Re: [GD-Windows] Complex GUIs

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

> If we wanted to do a complex GUI for a Windows game, on the order
> of an MMORPGs (toolbars, menus, windows, buttons, lists, etc.),
> would it be best to:
> 1. Use Windows native functions but overriding the drawing, etc.

Oh, hell no.

> 2. Use a third party gui widget toolkit and put in our own
> rendering functions to render the widgets.

Doubtful that this would be general purpose enough to make you happy.

> 3. Just do it how we do on consoles and use a thin, lightweight GUI
> built over the immediate mode toolkit.

Bingo.

> 1. Use Windows native event/messaging to drive the gui. 2. Use
> Direct Input and develop you own event messaging to drive the gui.

I think either approach works, they both have their pros and cons.  
There have been games that have used the GDI messages directly (e.g. 
Quake) with success, but DirectInput has a couple moderate advantages, 
especially when it comes to support of more exotic input devices, e.g. 
with force feedback.

Brian

RE: [GD-Windows] Complex GUIs

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

We use a different approach: we write our GUIs in Macromedia Flash. There's
awesome tools available to generate Flash, and we embed the actual,
honest-to-goodness Flash ActiveX control, making it render to a texture with
translucency (we actually have to render twice to get the translucency
right). ActionScript and some custom Monikers complete the circle, and it's
fully integrated.

CPU usage if your UI animates is really high, though.

Cheers,

			/ h+


-----Original Message-----
From: gam...@li...
[mailto:gam...@li...]On Behalf Of
Brian Hook
Sent: Thursday, December 18, 2003 4:14 PM
To: gam...@li...
Subject: Re: [GD-Windows] Complex GUIs


> If we wanted to do a complex GUI for a Windows game, on the order
> of an MMORPGs (toolbars, menus, windows, buttons, lists, etc.),
> would it be best to:
> 1. Use Windows native functions but overriding the drawing, etc.

Oh, hell no.

> 2. Use a third party gui widget toolkit and put in our own
> rendering functions to render the widgets.

Doubtful that this would be general purpose enough to make you happy.

> 3. Just do it how we do on consoles and use a thin, lightweight GUI
> built over the immediate mode toolkit.

Bingo.

> 1. Use Windows native event/messaging to drive the gui. 2. Use
> Direct Input and develop you own event messaging to drive the gui.

I think either approach works, they both have their pros and cons.
There have been games that have used the GDI messages directly (e.g.
Quake) with success, but DirectInput has a couple moderate advantages,
especially when it comes to support of more exotic input devices, e.g.
with force feedback.

Brian




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=ick
_______________________________________________
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] Complex GUIs

[Simon O'C. <si...@sc...>]

> 3. Just do it how we do on consoles and use a thin, 
> lightweight GUI built over the immediate mode toolkit.

I'm with Brian on this one, you don't want to be modifying Windows UI stuff
to do game UI stuff - there's a lot of pain if you do.

As an aside, even the work and toolset for a lightweight GUI on top of the
engine can be simplified by things such as Thatcher Ulrich's GameSWF:

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


 
> The second related part (or maybe this should come first?) 
> would be the event system that the above is all hooked up 
> into. Would you:
> 1. Use Windows native event/messaging to drive the gui.
> 2. Use Direct Input and develop you own event messaging to 
> drive the gui.

Windows messages do take much more account of user preference (mouse button
swapping, click rates, acceleration etc) and accessibility stuff for free. 

All of this can be queried and copied in your own DirectInput based system
of course - though it does mean a bit more work. The upshot is (slightly)
lower latency, exotic device support and more exclusivity/control.

When it comes to mice, things like force feedback are still extremely rare
(though trends like that take off surprisingly quickly, and OEM deals for
games that support rare features can be very good).


> Thanks,
> Brett

Simon O'Connor
Programmer @ Acclaim
& Microsoft DirectX MVP  

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.552 / Virus Database: 344 - Release Date: 15/12/2003
 

[GD-Windows] Faking Input on Clients

[Eric M. <ema...@um...>]

Hello All,
  I'm really stuck on this one and can't seem to find a good answer on the
web. I have several clients and one server computer. The clients are all
running the same game/app/demo/whatever. I would like to capture the input
from the control computer (not a problem), send it to each client (not a
problem), and then simulate the keyboard and mouse events on each client as
if a local user did them. (big problem) For a little context, each client
renders a separate screen and I want to synchronize their input so that all
screens line up. I can do this without a problem running my own applications
since the app is setup to handle external input streams. However, I can't
seem to find a way to do it for a generic demo or game. I spotted the
SendInput() command, but that seems to only work on the current window. Any
insight would be appreciated.

Thanks

E.

P.S. All are running XP.

RE: [GD-Windows] Complex GUIs

[<ce...@ce...>]

> 1. Use Windows native functions but overriding the drawing, etc. with
hooks to render a game interface instead of windows default application
interface.

I think this option was chosen by the Worms 2 developers. Not 100% sure
though.

Cheers,
Adrian