🔒 Locked

Continous method

Started by CupOJava Jun 13, 2010 at 9:03 AM 5 replies 900+ views

Original Post

Jun 13, 2010 at 9:03 AM

I'm a relative beginner to programming(less than a year in a starting course), and I've run into a bit of a wall in a program I'm making.
Okay, so I'm making a game based off of the original Donkey Kong games and I'm trying to make the KeyListener's delay(the whole "w...wwwwww" thing) go away and I've come up with a great idea, but the only problem is that I need a method go() that is constantly being applied and not just applied when an event is fired, which would constantly apply changes in a variable controlling the x position, and allow for smooth movement(ideally). I just can't seem to figure out how to get a method to run continuously while other methods are still active...would it be something using threads? Is it even possible? Any help would be greatly appreciated.

Zakwayda

Jun 13, 2010 at 11:08 AM

I'm not completely sure I understand your question, but if you're talking about disabling key repeat, most APIs that you would use for input will provide a way to do this. Once you've disabled key repeat, you simply watch for 'key down' and 'key up' events and set or clear a 'moving left' flag (for example) as needed.

Alternatively, you could just check to see if the key is currently down; most input APIs provide support for this type of query as well.

If that doesn't answer your question, perhaps you could tell us what API you're using for input so that we can provide more specific advice.

earl

Jun 13, 2010 at 5:01 PM

It sounds to me like you have 2 problems here. The first being that you need to disable key repeat, which is entirely API specific. The second being that you need to learn about game loops.

Once you have the first problem sorted out, rather than processing the game logic within the key event, you will probably want to set or clear a flag when you receive a key down or up event (as jyk mentioned), then test that flag from within the game loop. Threads are not required.

This will all depend on your language and API, but here is an example of what it might look like:

// Eventsvoid onKeyDown(KeyEvent evt){    if (evt.keyCode == KC_LEFT)        isLeftKeyDown = true;    else if (evt.keyCode == KC_RIGHT)        isRightKeyDown = true;}void onKeyUp(KeyEvent evt){    if (evt.keyCode == KC_LEFT)        isLeftKeyDown = false;    else if (evt.keyCode == KC_RIGHT)        isRightKeyDown = false;}// Game Loop - probably called within your// programs entry point (often called 'main')bool done = false; // Set this to true when the application is finished.                   // This could be when the ESCAPE key is pressed.while (!done){    if (isLeftKeyDown)        movePlayerLeft();    if (isRightKeyDown)        movePlayerRight();    // Draw sprites here...}

CupOJava

Jun 13, 2010 at 6:45 PM

Thanks for all the help guys, I actually figured it out on my own a few hours back when fiddling with starting a new thread to simultaneously run with the rest of the applet.

alvaro

Jun 13, 2010 at 7:50 PM

Quote:
Original post by CupOJava
Thanks for all the help guys, I actually figured it out on my own a few hours back when fiddling with starting a new thread to simultaneously run with the rest of the applet.

If that other thread is checking input in a tight loop with no delay, you'll be using 100% or one core for no good reason. It may work, but it's not a very good solution.

CupOJava

Jun 13, 2010 at 8:00 PM

There is a delay, it's about 50 or 60 milliseconds.

alvaro

Jun 13, 2010 at 8:11 PM

Quote:
Original post by CupOJava
There is a delay, it's about 50 or 60 milliseconds.

That's more acceptable. However, since the input and the rest of the game don't cycle on the same schedule, you may have trouble reproducing the game from a log of the input, which is a neat feature when you are trying to debug your code. So it might still be an issue if you ever try to reproduce any bugs.

What was the problem with checking the input in the main loop, say just before the scene update?

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.