@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.
NES games and differences in input reaction
Moderator: Moderators
Re: NES games and differences in input reaction
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
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.
Re: NES games and differences in input reaction
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?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.
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: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).
Code: Select all
; 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
Re: NES games and differences in input reaction
For the D-pad part, I think it needs some buffer for performing the head butt move vianesrocks wrote: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.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
Re: NES games and differences in input reaction
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.Gilbert wrote: For the D-pad part, I think it needs some buffer for performing the head butt move viadouble clickingpressing 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.
@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.
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.
Double dragon 2 and 3 are consistent. 6 frames.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Re: NES games and differences in input reaction
It was also consistent 6 frames for 1 for me.nesrocks wrote:Double dragon 2 and 3 are consistent. 6 frames.
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.
- rainwarrior
- Posts: 8732
- Joined: Sun Jan 22, 2012 12:03 pm
- Location: Canada
- Contact:
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.
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.
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.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!