Thread: [GD-Windows] Complex GUIs
Brought to you by:
vexxed72
From: Brett B. <res...@ga...> - 2003-12-19 00:04:20
|
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 |
From: Brian H. <ho...@py...> - 2003-12-19 00:13:41
|
> 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 |
From: Jon W. <hp...@mi...> - 2003-12-19 00:38:12
|
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 |
From: Simon O'C. <si...@sc...> - 2003-12-19 00:43:44
|
> 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 |
From: Eric M. <ema...@um...> - 2004-02-05 17:58:13
|
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. |
From: <ce...@ce...> - 2003-12-19 07:38:45
|
> 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 |