Game Development Community

Questions about canvas focus and control in Torque Combat.

by Stephen Murrish · in Torque X 2D · 09/12/2007 (10:48 pm) · 7 replies

I am wondering about the proper Torque way to tell the engine to make the GuiBitMapChoice to get focus from the position of the mouse. Once you set up a cursor and get mouse movement, do you have to set up some kind of collision routines and have them tell the canvas that this is or that button is selected when the mouse pointer texture collides with the GuiBitMapChoice texture? And then also do you have to write routines to handle mouse clicks on the canvas as well? That is, to detect the location of the mouse during the click and then testing against collsion with a gui control and then calling the proper routine for the selection of that gui control? Or is much of that already automatically handled by the canvas and all you have to do is change a few properties and give a callback function for what to do when the particular moused-over gui control is clicked?

#1
09/13/2007 (7:16 am)
If you are not using the Windows mouse cursor, you should be aware that GUI elements are always drawn on top af all game objects (like T2DStatic/AnimatedSprite), even if you try to use the Layer property. If you want your mouse cursor to be visible when moving over GUI elements, you will have to use a GUI element (like GUIBitmap) as a mouse cursor, which does not provide the same fancy graphics features as T2DSceneObjects like e.g. on-the-fly transparency changes.

Detecting which GUI element the mouse is currently clicking on is a bit more complicated since you cannot query them spatially (see www.garagegames.com/mg/forums/result.thread.php?qt=66873). You either have to check every GUI element in the current folder to find the one(s) that match the mouse position, or you might try it with collisions.
#2
09/13/2007 (2:57 pm)
Ahhh, that's unfortunate.

It seems that they are supporting keyboard input more and mouse input less because the mouse is "platform specific"? As far as I know, there is no keyboard attachment for the XBOX.

Perhaps I could simply make my menu items all game object types and have them call functions on collisions that test for mouse input? This could make for some very interesting behaviors in the menu items... I suppose the mouse would be the player and the menu would be a game level.
#3
09/13/2007 (7:52 pm)
XBox 360 keyboard. :P

Seriously though, more sophisticated mouse and GUI interaction is something we want to do, we just haven't gotten to it yet.

In the meantime, if you're just interested in clicking on things or detecting mouse-over events, you can calculate the mouse position relative to the bounds of a GUI control with simple math (mouse position vs. GUI position/size).
#4
09/13/2007 (10:44 pm)
Hehehe. Nice one, Thomas. I am surprised that Microsoft changed its policy regarding keyboards and the XBOX.

I figured that I would write a small routine to handle that handles mouse pointer collision with a gui bitmap rectangle.

In the game I want to do, I want the mouse to move a target reticle around to provide the direction for player attacks of various kinds and also to click on and interact with objects in the game depending on the context. I want to use the mouse for menus as well.

I suppose I'll also map into one of the directional sticks of the XBOX controller to provide the same function as the mouse. I currently have no XBOX or XBOX controller, so that support will probably come after I get the keyboard/mouse support done.
#5
09/13/2007 (11:14 pm)
Yeah I'm going to pick up one of those soon, maybe this weekend. I use a 360 controller to play WoW myself and that will help. I think their biggest concern wasn't the input method but the desire to not having players feel they need to break out the keyboard and mouse in the gaming/living room on the couch. There were keyboards for the nintendo and older ps that had the controllers built into a keybaord (on either side), but tey were still big clunky keyboards. Since console gaming has been and (I feel) should be mostly controller play over typing stuff in I think it was a good choice. There's nothing wrong with controlling the direction of your product.

Now they have a solution. You can have a semi-decent typing device that's not big and clunk, and still devotes most of its space to the controller action. It's alright to make it small because typing in text should be secondary to using the controller on a console game.

Thena gain you can blow off anything I say as weird because when I go to quakecon I play FPS games on my PC with my 360 controller :-) It just seems more natural (especially with triggers) than a big mouse and keyboard. I'm looking forward to integrating that kind of [optional] interface into proejcts I develop with the Torque line of games.

It just requires devotion to developing an interface that will work. You could look at Guild Wars, for example. You are limited (or rather disciplined) to using only 8 skills. That's perfect for 4 main buttons on a controller, plus another button (left trigger for example or shoulder) as a shift for 4 more. Not much really requires the mouse and keyboard.
#6
09/13/2007 (11:50 pm)
My opinion on the issue is the more options the better. There are games that really feel nice with the keyboard and mouse and don't feel so good with a controller.

On the game (Gravity Drive) I worked on with a team as a student project, we chose to have a keyboard and mouse as well as an XBOX type controller control. WASD controlled movement and the mouse controlled a targeting reticle, space bar was jump and the mouse buttons were shoot and change weapon. On the controller, one directional pad controlled movement (a la WASD), another controlled the targeting reticle, and various mappable buttons shot, changed weapons, and jumped. It worked out very well with both control schemes and what you used was a matter of preference.

I want to do the same control scheme with this project.
#7
09/14/2007 (2:00 pm)
Yeah don't get me wrong, giving options to the player (to a point) is always good. Plus, if you create for the PC you can never prevent keyboard/mouse use because those are the only real things you can really count on being there. Having said that, defining the interface of course needs to take into consideration these things. Since while keyboard/mouse can adapt, it's not necessarily the other way around.