Tag Info

Hot answers tagged

59

First of all, XNA also uses C# too so it's the same programming language. And although the underlying API might have some differences from DirectX, that has nothing to do with jumping, so the same tutorials or answers should apply here. Also, there are numerous ways to implement this, depending on a lot of factors. What I'll describe below is just one of the ...


52

Here is an extremely detailed Sonic The Hedgehog physics guide. I would recommend reading it over, if not actually copying parts of it mostly-verbatim.


36

Although you are targeting desktops, there will be players on (gaming) laptops and for some of them, it will be an inconvenience to get a mouse before being able to play your game. It would sound like a good thing to me, if you were to support alternative control schemes or customizable controls. This is not a very "sciency" answer - I've just run into this ...


29

In a game which is controlled by a gamepad, where control inputs directly change GUI focus from one GUI button to another, those GUI buttons should be activated when a controller button is pressed. In a game which is controlled by a mouse (or if a gamepad is used to move a virtual mouse cursor around the screen), on-screen buttons should be activated when ...


22

It really depends what you mean by "assume". Are you making this assumption at the point of designing your gameplay mechanics? Or at the point of deciding whether or not to implement fully customizable key bindings? You could mean "I assume real gamers have a 3 button mouse, therefore I don't need to offer the option to rebind bayonet-thrust to a keyboard ...


21

It's quite tricky to implement, say, 'Mario-like' physics using a real physics engine. Last time I tried this, using Chipmunk, I modelled the player as 2 circles - a 'body circle' on top of a 'feet circle' The 'feet circle' had some friction, was non-bouncy, and fairly small. The 'body circle' was larger and frictionless, to avoid sticking to walls/steep ...


20

There is no one perfect mapping that gives you a platform specific abstraction, because obviously most of the identifiers that make sense for a 360 controller are wrong for a PlayStation controller (A instead of X, B instead of Circle). And of course a Wii controller is another thing altogether. The most effective way I've found to deal with this is to use ...


18

Keyboards have hardware limitations on how many keys can be pressed and recognized at the same time. Your code is not the problem here, it's most likely the design of the keyboard.


17

What you're trying to do is simple to solve without having to resort to doing any timing on the input (in fact I recommend you not to do so in this case - timing is more useful for scenarios such as limiting the firing rate of a spaceship). If you want for only the initial press of the key to be registered, the way it's usually done is: Keep track of ...


16

Can I discourage you from attempting to emulate a D-pad on a touchscreen device? The problems with emulating a D-pad on a touch screen are: the D-pad takes up screen space that you could be using for the game; unlike a real D-pad, an emulated D-pad offers almost no feedback: as a player, you can't tell which direction you're pressing in, neither by feel ...


16

It depends on the requirements of your game and hardware. Most games are usually interested in changes to input state, i.e. user presses the fire key and their weapon starts firing, user releases the fire key and their weapon stops firing, user presses the move key and starts moving, releases the move key and stops moving, etc., so an event-driven input ...


15

Honestly I don't think using a physics engine is the right approach for something of that size domain with super strict requirements. Just write it all yourself. You'll get much better results by saying "move character up by x units in this parabola shape when holding down jump button for length y" than by having a bunch of knobs to tweak.


15

If you stop calling it "pushing forward" on the joystick/mouse, and start calling it "pushing up" (which is the way that most players think of it -- particularly the ones who don't play flight simulators), then the "invert Y axis" name makes complete sense, since pushing up causes the player to look down. Edit: The fundamental issue here is people's mental ...


13

Recognising arbitrary shape vectors is hard! A simpler technique is to use a grid and count the edges crossed by the stroke drawn by the user. This list of edges is used as a "signature" which is compared against a dictionary of signatures of pre-defined shapes. Algorithm Sub-divide the input area into a grid (eg: 3x3 with infinite edges), and give each ...


13

Distance-Based You will basically need to take two things into consideration: a threshold (inversely a deadzone) and the dominant vector. Given an enum like the following: public enum Direction { None, Up, Down, Left, Right } You would find the dominant direction (if the deadzone isn't in play) and use that. // You could make this user-configurable. ...


12

While you can implement this using SDL_WarpCursor(), I've run into problems with that method on some platforms. I've had real problems with some platforms not reliably performing the WarpCursor() action, particularly when I've been calling it every frame. Also, remember that on many platforms, the cursor is handled at a higher frequency than your app. ...


12

You're on the right track with figuring out when the mouse is transitioning from down to up and writing a handler for that. For a lot of games, it's good enough to treat a mouseUp event as a click. Depending on your game, you're probably want to handle both events -- for example, in an RTS, you'll probably want to incorporate drag-box selecting as well as ...


12

Split this into several layers. At the lowest layer you have raw input events from the OS. SDL keyboard input, mouse input, joystick input, etc. You might have several platforms (SDL is a least-common-denominator lacking several input forms, for instance, which you might later care about). You can abstract these with a very low-level custom event type, ...


11

When working with XNA in general you have to move from an event driven code paradigm to a loop driven code paradigm. Your update code loops 60 times/sec. So each time, look at the state of the mouse and if a button is down & pointer is within your rect, then branch to code you would normally place in an OnClick event.


11

It's easiest to think of your order in a single frame, think of it as a series of dependencies. User input depends on nothing, so it goes first. Objects being updated depend on the user input, so they go second. Physics depend on the new updated objects, so it goes third. Rendering depends on the latest physics state and object updates, so it goes fourth. ...


11

Keyboards have a key matrix, where the buttons have been arranged into something roughly square, with the keyswitches each being tied to one row and one column. The keyboard activates each row and then reads the columns. If you sketch this out you will see that some button combinations must activate "phantom" keys. You can fix this with one diode per button ...


10

The XNA Keys struct is not marked with the Flags Attribute which means that it's not legal to | a load of keys together like that. Keys keyCombo = Keys.Left | Keys.A; Console.WriteLine(keyCombo); Will print NumPad5, which is clearly not what you want here! You've never been able to do this in any version of XNA, I think the book is just wrong here :O ...


10

Did you search in the interactive fiction community? They still write parsers and some try to push the envelope by implementing new techniques such as natural language processing. See for example this link for articles describing approaches used: http://ifwiki.org/index.php/Past_raif_topics:_Development:_part_2#Parsing


10

I know this isn't the most useful answer, but unless you are porting a project over from another platform, I'd suggest reconsidering on the virtual D-Pad. Most implementations of virtual D-Pads have been poor at best, the lack of tactile feedback make them a poor choice for the platform. You are far better off looking at building an interface to your game ...


10

We used a state system, as you mentioned before. We would create a map that would contain all the keys for a specific state with a flag that would allow pass through of previously mapped keys or not. When we changed states the new map would be pushed on or a previous map would be popped off. Quick simple example of input states would be Default, In-Menu ...


10

An SDL_KEYDOWN event is only sent when the key is first pressed. You will receive an SDL_KEYUP event when it's released. You'll want to handle moving in code which gets called every frame, not in response to an event. Inside Avatar::handle_input, you'll instead want to set variables to tell you whether each key is up or down, and update those variables as ...


10

Many laptops lack a middle button, especially those with a trackpad, and you need special software to emulate it. Mac laptops have only one button. Right-click is pretty easy (two finger click) and not uncommon in Mac games, and the two finger drag to scroll isn't bad, but only in slower paced games. However, there is no concept of a middle click in the ...


9

void Main::processInput() { Uint8* keystate = SDL_GetKeyState(NULL); //continuous-response keys if(keystate[SDLK_LEFT]) { } if(keystate[SDLK_RIGHT]) { } if(keystate[SDLK_UP]) { } if(keystate[SDLK_DOWN]) { } //single-hit keys, mouse, and other general SDL events (eg. windowing) ...


9

How about you use a Queue<T>? There are 4 significant members of Queue<T> you can use: Queue.Enqueue(T item) - put your item at the end of the queue. T Queue.Peek() - look at the first item without removing it. T Queue.Dequeue() - get and remove the first item. Queue.Count - check how many items are in queue. Sample usage Here's what ...


9

Moving the joystick in a complete circle gives you the upper bounds of the joystick range, but the at rest (i.e. no input) position of the joystick can't be accurately determined from those values. You could assume that that rest position is the exact center of the available range but that is only true in ideal circumstances. Over time controllers wear in ...



Only top voted, non community-wiki answers of a minimum length are eligible