D-Pad emulation

[Celius]

I guess it's fine if they cancel each other out. I just implemented this. But Blargg, registering which one was most recently pressed sounds definitely like the best way to go. But I've got to confess, at the moment I'm too lazy to implement that. I'm assuming left and right won't be pressed too often simultaneously. And plus, even though my game is action-based, it won't require lightning fast reflexes and very precise timing, so it's not that big of a deal. Thanks for everyone's help!

[Banshaku]

I guess it's fine if they cancel each other out. I just implemented this. But Blargg, registering which one was most recently pressed sounds definitely like the best way to go. But I've got to confess, at the moment I'm too lazy to implement that. I'm assuming left and right won't be pressed too often simultaneously. And plus, even though my game is action-based, it won't require lightning fast reflexes and very precise timing, so it's not that big of a deal. Thanks for everyone's help!

My recommendation: focus on the game first then optimize your code for those things after. Why would it be an issue during the developing phase?

my 2 cent.

[baisoku]

Some games have more than "interesting" behaviour if conflicting directions are pressed. Commando crashes if left and right are pressed simultaneously.

[Jon]

Some games have more than "interesting" behaviour if conflicting directions are pressed. Commando crashes if left and right are pressed simultaneously.

simple. before doing anything with the directions in the game logic just have left-right instantly kill you, and up-down make your invisible (not invincible). then TAS people can't scam your game.

[Celius]

My recommendation: focus on the game first then optimize your code for those things after. Why would it be an issue during the developing phase?

I like to get as much out of the way as possible before realizing my project is a hopeless mess and having to start over like I have so many times before. And in the earlier stages of development, I think it's best to make sure it doesn't crash.

my 2 cent.

I'm sorry, I really don't mean to be nit picky (I don't like to be nit picky), but I notice you write this after nearly every post. It's almost like signing each post with "-<your name>" all the time. It's not really annoying or anything, I just think by this point we know what you're posting is your 2 cents, and you could save yourself the trouble of typing it all the time. If you feel you need to, go ahead, but it's just my 2 cents .

[Banshaku]

I like to get as much out of the way as possible before realizing my project is a hopeless mess and having to start over like I have so many times before. And in the earlier stages of development, I think it's best to make sure it doesn't crash.

It always depends on much your joystick input routine have an impact on your game. From my point of view, you are just reading a state of an input device that will be stored in a buffer somewhere. this buffer will be used after in another routine. Those 2 routines are not tied together and should be independent.

To optimize later the the way the buffer is read to avoid pressing button should have no impact on your current development cycle unless they are deeply coupled in some way. This is why I said that it shouldn't be an issue. Those are the kind of details that always delay the development cycle of a program because we think they could be important and annoys us but often they are not.

I'm sorry, I really don't mean to be nit picky (I don't like to be nit picky), but I notice you write this after nearly every post. It's almost like signing each post with "-<your name>" all the time. It's not really annoying or anything, I just think by this point we know what you're posting is your 2 cents, and you could save yourself the trouble of typing it all the time. If you feel you need to, go ahead, but it's just my 2 cents .

It just happens that I wrote it to a few message recently but I don't write it to all of them. I don't like signatures and it was not the intend. I always write it for some specific messages only.

If it so irritating then I will try to avoid using it compulsively. my 2 .. argggg

[tokumaru]

I actually don't worry about what can and cannot be pressed on a hardware level, I just assume everything can. I don't get any bugs because my logic/physics does not collapse if opposing directions are pressed. If left and right are pressed at the same time, my engine will just take both forces into account, and the character will most likely just stand there, no problem. If it was walking in one direction and the opposite key was pressed (while the other remained pressed), the character would just slow down because of the opposing force and eventually stop.

I didn't have to deal with up and down yet (because I haven't used up), but I'd probably handle it using states, favoring the current state. If the character was looking down and the player pressed up, I'd look into the request of looking up, but wouldn't allow it since the character was currently looking down (as I wouldn't for many other states, such as jumping, getting hurt, etc). Same thing if it was looking up, I'd deny a look down until it stopped looking up.

I really feel that this problem is best resolved at the game logic level. If you filter keys at the hardware level (the emulator does it for you or you do it on your joypad reading routine) you loose the power to prioritize keypresses on a case-by-case basis. blargg's solution is interesting, but what if for some reason during a specific portion of my game I need to prioritize the key that was pressed first (as opposed to the most recent)?

Just out of curiosity, I just checked how Sonic 1 and 2 handle the looking up/down thing. It just prioritizes looking up, which I think is wrong. I know that some NES games have bugs when opposing directions are pressed, and I see this as sloppy coding, right along with visible scrolling artifacts and other "pearls" present in so called "professional" games.

[Xkeeper]

Just wanted to note that since all the buttons are latched simultaneously by the shift register, there's virtually no way a normal controller can register conflicting directions.

All it takes is a low quality pad or a pad that does not work correctly and suddenly it is indeed very possible.

Oh wait, nothing ever goes wrong with consoles or their hardware. Silly me.

Jesus Christ you assholes are uptight over this shit.

Who is an asshole? And who's uptight about what?

hint: the person I quoted right before saying that.

[Near]

Bottom line: don't worry about it. And why emulator authors added that option is beyond me -- I'd love to punch them in the balls.

That's a bit extreme. I can name a few titles with spots that will lock the game in an infinite loop if you press up+down or left+right at the same time. Since it's difficult to do it with a real D-pad anyway, it's a good option to have when using a keyboard for input. I'd even say it's best to block the combinations by default.

That said, since the hardware technically allows it, it's best to put the input filtering code on the UI side, and not in the core register polling routines.

[Bregalad]

I never understood how tool asisted stuff could make the hero make super jumps or being teleported. Dodes some game have this kind of behavior when up+down or left+right are pressed ?

To kill tool assisted stuff you could show directly the ending whenever up+down or left+right are pressed, so that people will think "that's unfair" and will watch real speedruns instead.

[blargg]

I originally added this filter to my emulator after spending a long time chasing a bug in the Battletoads snake pit levels. Pressing left+right causes your character to float upwards, and not go back down when you release them. Since that game has such tricky timing and delays enabling rendering, I spent the longest time looking for timing bugs.

[tokumaru]

I never understood how tool asisted stuff could make the hero make super jumps or being teleported. Dodes some game have this kind of behavior when up+down or left+right are pressed ?

I think they use all sorts of bugs from the games, not just up+down/left+right. I guess that teleports are often the result of collision detection issues (like when a character gets stuck into a wall and is ejected from it, either to the other side or to the top), or coordinate system issues (unusual coordinates are misinterpreted and the characters shows up somewhere else). High jumps, I believe, are the result of jumping again at the exact frame where the engine is not certain if the character is on the ground or not. In some games (SMB is one of them, I think) you can jump when pressed against a wall if the character is vertically aligned with a wall block that is perceived as floor.

[Zepper]

- Short answer: programming bugs.
- Well, Battletoads gameplay is ruined during vertical stages if you press down+up. In Zelda 2, Link can slide almost instantly with left+right.

- As quick note, when someone says "up+down", it can be "hold up THEN press down" as example.

[Xkeeper]

I never understood how tool asisted stuff could make the hero make super jumps or being teleported. Dodes some game have this kind of behavior when up+down or left+right are pressed ?

To kill tool assisted stuff you could show directly the ending whenever up+down or left+right are pressed, so that people will think "that's unfair" and will watch real speedruns instead.

That really won't kill tool-assisted speedruns (why would you want to, anyway?).

There are several games with extreme game-breaking glitches (Link's Awakening is one of them, both original and DX versions). That is why there's a TAS of the full game.


I never got the reason for all the hate over TASes. I, for one, enjoy both; TASes are meant to be a demonstration of perfection, speedruns are a demonstration of skills. They're not at odds with each other, and you would do yourself well to understand that.



As for left+right/up+down bugs, surprisingly few games actually have ones that are anything beyond "low" in severity. SMB1's, for example, just makes you moonwalk.

[Kasumi]

simple. before doing anything with the directions in the game logic just have left-right instantly kill you, and up-down make your invisible (not invincible). then TAS people can't scam your game.

All Killing the character would do is make the TAS player not press left+right. They'll still TAS the game, and you'll have accomplished nothing. Making the character invisible would not stop a dedicated TAS player, who would simply find his position in RAM. As a matter of fact, it would give a TAS player a reason to TAS your game, as going through an entire game invisible would make a SPECTACULAR TAS to watch. All these two things would do is seriously confuse a player with a broken down NES controller, or an emulator that doesn't filter up+down or left+right. Not to mention that programming the game to handle the case so nothing weird happens is a much better solution anyway.

As for making up+down display a game's ending, the TAS player could simply... not press up+down?

Xkeeper: I don't understand TAS hate either. TAS are always clearly labeled, so they don't compete with regular speedruns. I don't think people understand the knowledge that goes into making some of the better ones. You have to know SO much about the game to get a really good one. There's a lot more to them than just playing a game frame by frame, or pressing "illegal button combinations". Especially some of the better RPG ones that manipulate "luck" by watching locations in RAM.