nesdev.com
http://forums.nesdev.com/

NES games and differences in input reaction
http://forums.nesdev.com/viewtopic.php?f=2&t=16488
Page 2 of 2

Author:  nesrocks [ Wed Sep 13, 2017 8:42 am ]
Post subject:  Re: NES games and differences in input reaction

@dougeff: well, I tried several different types of moves for the games that didn't react as fast as possible (the games on the 3, 4, 5 and 6 list of the original post). I tried moving, attacking, jumping, etc, so I think that rules out the sub-frame movement issue.

@tokumaru, so that would explain the games on the "3" list on the original post? I think arkanoid is well programmed, at least it looks super clean and smooth, but it has that extra lag frame.

Author:  tokumaru [ Wed Sep 13, 2017 8:46 am ]
Post subject:  Re: NES games and differences in input reaction

I don't know, I haven't personally reverse-engineered any of those games, that was just a conclusion I came to when developing my own programs.

Author:  tepples [ Wed Sep 13, 2017 9:34 am ]
Post subject:  Re: NES games and differences in input reaction

dougeff wrote:
Consider that some games might be doing acceleration at the sub-pixel level. So, it might only be moving the main character 0.3 pixels for the first few frames...making it appear like no movement has taken place.

My nrom-template (along with snrom-template, lorom-template, and the Wrecking Ball Boy tech demo in Pygame, which have similar walking physics) has acceleration lag. Would it be a significant improvement in responsiveness to plug this by moving a stopped player character near the edge of the subpixel that he is facing?

tokumaru wrote:
There are of course solutions that don't require any lag, but they often require more CPU time (e.g. visiting objects more than once per frame).

The Curse of Possum Hollow visits objects twice. The overhead of this is minimal, about two scanlines, and it allows sprite cycling by visiting objects in a varying order. From memory, the logic is something like this:

Code:
; draw enemy closest to player and player
ldx high_priority_actor_id
bmi no_high_priority_actor
  jsr draw_actor_x
no_high_priority_actor:
lda mercy_flash_phase
bne player_hidden_by_mercy
  ldx #0
  jsr draw_actor_x
player_hidden_by_mercy:

; draw other enemies, giving each a chance to be first
ldx #NUM_ACTORS_ROUNDED_UP_TO_POWER_OF_2_MINUS_1
draw_actor_loop:
  txa
  eor flicker_bias  ; this varies each frame
  and #NUM_ACTORS_ROUNDED_UP_TO_POWER_OF_2_MINUS_1
 
  ; Skip already drawn or invalid actor IDs
  beq skip_drawing_actor  ; actor 0 is already drawn
  cmp #NUM_ACTORS
  bcs skip_drawing_actor  ; past the end of the non-PO2 actor table
  cmp high_priority_actor_id
  beq skip_drawing_actor  ; high-prio actor closest to player is already_drawn
    stx cur_turn
    tax
    jsr draw_actor_x
    ldx cur_turn
  skip_drawing_actor:
  dex
  bpl draw_actor_loop

Author:  Gilbert [ Wed Sep 13, 2017 10:01 am ]
Post subject:  Re: NES games and differences in input reaction

nesrocks wrote:
Bregalad wrote:
Double Dragon games uses the button combination A+B to jump. It is almost impossible to require for the player to press those buttons at the same time, so when the game detect that A or B is pressed, very likely it waits a few frames to see if the player press the other button

Very interesting, hadn't thought of that. The thing is, it doesn't just wait that long for A or B, it waits that long for any d-pad button too. That would have been unnecessary, imo.

For the D-pad part, I think it needs some buffer for performing the head butt move via double clicking pressing a direction twice. The game possibly checks whether a direction is kept pressed for a few frame, released for a few frames and then the same direction is pressed again to register it as a head butt (similar things should apply for fighting games with special moves performed with the direction keys, such as Street Fighter) and registers it as walking if the direction is kept pressed for more than some threshold number of frames.

Author:  Bregalad [ Wed Sep 13, 2017 11:33 am ]
Post subject:  Re: NES games and differences in input reaction

Gilbert wrote:
For the D-pad part, I think it needs some buffer for performing the head butt move via double clicking pressing a direction twice. The game possibly checks whether a direction is kept pressed for a few frame, released for a few frames and then the same direction is pressed again to register it as a head butt (similar things should apply for fighting games with special moves performed with the direction keys, such as Street Fighter) and registers it as walking if the direction is kept pressed for more than some threshold number of frames.

This does not require any additional delay, and I'm fairly sure Double Dragon's D-pad is very responsive. Only history of left/right button presses (or possibly time between last button state change) is required, waiting is not required. Only waiting for A+B for jumping is required.

@nesrocks: They way you count frames of delay should be wrong. I am fairly sure that there is a delay for punches and kicks, but it should be a constant amount of frames. It varying randomly between 3 and 10 is unthinkable. Simple quick testing with VirtuaNES indicates me a constant 6-frame delay.

Note that the delay between punches and kick is the reason why the game is challenging at all. If they were instantaneous (aka you press A and next frame your punch is in your opponent's face) then the game would be almost unloosable. That tiny window where the enemy can attack first is what makes the game dangerous, and as so, fun to play.

Dragon Warrior games as well as Ultima seems to wait that the engine's frame counter is at a multiple of 16 before starting any movement, probably because their scrolling engine is awfully simplified. This provides a delay varying randomly between 1 and 16 frames when moving to a direction after stopping, but no delay when moving and changing direction. This is acceptable (but annoying) because in RPGs timing is not very important, but this would be unacceptable for any action game.

Author:  nesrocks [ Wed Sep 13, 2017 12:05 pm ]
Post subject:  Re: NES games and differences in input reaction

I'm not counting it wrong. Open double dragon 1 on fceux, pause the emulator, press and hold "A", hit frame advance 11 times and then the character starts the punch animation. I counted 14 right now on level 4 for the elbow attack. It is inconsistent. Yes, I am including lag frames. I could get it to respond in 2 frame advances when walking (not punching) at some point, but that was the record, not the rule.

Double dragon 2 and 3 are consistent. 6 frames.

Author:  Bregalad [ Wed Sep 13, 2017 11:32 pm ]
Post subject:  Re: NES games and differences in input reaction

nesrocks wrote:
Double dragon 2 and 3 are consistent. 6 frames.

It was also consistent 6 frames for 1 for me.

A major problem with this method is that modern keyboards hardly support pressing multiple keys at once. Pressing a letter associated with the A button and then the space bar for frame advance simultaneously can get the OS confused about what to do and it is possible that the emulator does not frame advance even when you press the bar. This might be why either of us can get the count wrong (i.e. too many frames before action). At least for me counting was hard, sometimes it didn't work at all and the character wasn't punching. It's really tedious to see. Playing a "video" with frame advance, and pre-recorded buttons might be a better idea to do that but I don't know how to do it.

Author:  rainwarrior [ Thu Sep 14, 2017 12:38 am ]
Post subject:  Re: NES games and differences in input reaction

A USB gamepad makes that problem very easy to solve. I tend to think of one as an essential debugging tool.

Author:  nesrocks [ Thu Sep 14, 2017 6:18 am ]
Post subject:  Re: NES games and differences in input reaction

I'm a veteran speedrunner, I know what I'm doing. The most basic thing is a frame advance... Here are my TAS: http://tasvideos.org/Subs-295up.html
My frame advance key is set to left control, so that problem is non existent. I configured it that way exactly because of that, and I do the same for every new emulator I use, so much so that if the emulator doesn't allow me to configure it like that I don't even use the emulator anymore. Besides, the keyboard ignoring keys is consistent. If A+X doesn't work that's because it won't ever work, so I couldn't be advancing just some frames. I'd be in an eternal stop if that was the problem. So no, I'm not counting it wrong.

What emulator are you using? Is it configured to ignore lag frames? It shouldn't be. As I said in the original post lag frames are included because they are part of the experience and add to the total real response time, which is the point of the whole test. In fact, ignoring lag frames is a terrible idea overall for testing anything. Turn it off and redo your tests.

Here's the thing, since there are lag frames:
walking may take 2-3 frames
kicking may take 5-6 frames
punching may take 11-12 frames
It all depends on when you pressed the button

I have tested double dragon U, double dragon J and even the beta rom and all of them are like this.

Page 2 of 2 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/