• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

Alexander Deruwe

DInput.

5 posts in this topic

Surely if the code that responds to a key-press is being executed three or four times per key-press this would be because your main loop is very fast (say >60fps) and it's impossible to actually press a key for 1/60th of a second. DirectInput is very fast.
All sorts of other things can cause what look like input problems. For instance, I was using BltFast in windowed mode and because I wasn't properly waiting for my Blits to finish, they were being queued which lead to the input looking like it had a 2 second delay.
0

Share this post


Link to post
Share on other sites
Using a delay and repeat system works very nicely if you have the time to implement it. However, if you want to move left once for every physical keypress (with no repeating) you could just utilize buffered-input from DInput to check for a keypress event, or you could compare the last recorded state with the current state to the same effect.

- Splat

0

Share this post


Link to post
Share on other sites
Unless u actually need a realtime key state(like in flight simulators), the delay algorithms suck. They're always gonna be either too fast, or too slow, or have the strange feel.
The best way to deal with the problem is to implement buffered input, it works perfectly, and is relatively easy to set up. There is an article on GDNet somewhere about DirectX buffered input, look for it, even though it's for directx 3, it explains how to do it very well.
0

Share this post


Link to post
Share on other sites
You should definitely look at buffered device input as a solution to your problem, as the previous two posts say. I would just add that it is useful (and rather simple) to just set up an class (if you're using C++) that just enumeratates all of message buffers of the input devices that you need buffered data for.

This way you can get messages from all of the devices in sequential order (using the macro DISEQUENCE_COMPARE(dwSequence1, cmp, dwSequence2)).

Of course if you want to be able to have a key repeat a down message during a long keypress you would need to add some additional code to your game loop.

Just my two pence.

------------------
Where's my Golden Fleece?

0

Share this post


Link to post
Share on other sites
This question from a few weeks ago popped up while I was writing my last reply:

I have my main game loop, and in it I get the state of all keys with DI. Now, when I check them, it goes way too fast.
Sometimes when you hit "left" once, you go left 4-5 positions, just because the keypress is too slow (I think).

I've tried slowing this down with some timer code, but that isn't what it is supposed to be, since now there is like a delay sortof-feel on the keys.

Does anyone know what I might do to correct this problem?

0

Share this post


Link to post
Share on other sites
The best way that I have found to do it (in my opinion and if memory isn't to big of a deal) is to create another array of bools that you update to show that the key was pressed, not just held down. My code looks like this:

m_ButtonsClk[0] = (!m_Buttons[0] && (mouseState.rgbButtons[0]&0x80));
m_ButtonsClk[1] = (!m_Buttons[1] && (mouseState.rgbButtons[1]&0x80));
m_ButtonsClk[2] = (!m_Buttons[2] && (mouseState.rgbButtons[2]&0x80));
m_ButtonsClk[3] = (!m_Buttons[3] && (mouseState.rgbButtons[3]&0x80));
m_ButtonsClk[4] = (!m_Buttons[4] && (mouseState.rgbButtons[4]&0x80));
m_ButtonsClk[5] = (!m_Buttons[5] && (mouseState.rgbButtons[5]&0x80));
m_ButtonsClk[6] = (!m_Buttons[6] && (mouseState.rgbButtons[6]&0x80));

m_Buttons[0] = (mouseState.rgbButtons[0] & 0x80 );
m_Buttons[1] = (mouseState.rgbButtons[1] & 0x80 );
m_Buttons[2] = (mouseState.rgbButtons[2] & 0x80 );
m_Buttons[3] = (mouseState.rgbButtons[3] & 0x80 );
m_Buttons[4] = (mouseState.rgbButtons[4] & 0x80 );
m_Buttons[5] = (mouseState.rgbButtons[5] & 0x80 );
m_Buttons[6] = (mouseState.rgbButtons[6] & 0x80 );

where mouseState is the updated DIMOUSESTATE, m_Buttons tells whether the key is down(pressed or being held down), and m_ButtonsClk tells whether or not the button was pressed (and not being held down). This seems to work well for everything that I have done. Hope this helps.

0

Share this post


Link to post
Share on other sites