Input delay at the start?

Found a bug in R'n'D? Report it here!

Moderators: Flumminator, Zomis

Post Reply
User avatar
Aurora
Posts: 24
Joined: Sun Oct 13, 2013 6:46 pm

Input delay at the start?

Post by Aurora »

This is something I encountered in version 4.0.1.0, so if it's been fixed in a subsequent version, please let me know!
Basically, there seems to be an input delay when you first start a level, that makes certain levels that require immediate movement (specifically, level 32 of Supaplex Level Collection 02) impossible.
I'm not too sure if this is an issue with the in-game Supaplex engine, or with RnD in general, but would it be possible to fix that? Thanks!

e: This still appears to be an issue in the most recent release :(
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: Input delay at the start?

Post by filbo »

I have always experienced that the player does not get the first move, the game engine does. Except 'always' is 'last few years, when I've been working through EMC levels', so might be EMC engine-specific.

e.g. suppose I start a game in single-step mode. The first command I give does nothing, and the game goes through one action cycle. 2nd command does what it's supposed to do. As far as I know this is by design, but I have occasionally wondered if it wasn't. Holger?
User avatar
Aurora
Posts: 24
Joined: Sun Oct 13, 2013 6:46 pm

Re: Input delay at the start?

Post by Aurora »

Apparently the automatic level restart in the new version of the game actually fixes this particular issue.
Though it's still present if you start a level from the main menu.
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Input delay at the start?

Post by Holger »

Basically, there seems to be an input delay when you first start a level, that makes certain levels that require immediate movement (specifically, level 32 of Supaplex Level Collection 02) impossible.
Thanks a lot for reporting this issue, and also many thanks for providing a level to easily reproduce this issue!

This should indeed be seen as a major bug (not specifically related to the Supaplex game engine, but to event handling in R'n'D after starting a game in general). In fact, R'n'D has a time limit to handle input events; if this limit is reached, a game and video frame is processed before continuing with event processing. Unfortunately, when starting a new game from the main menu, processing the "start game" event (like pressing the space bar) involves various additional delays (like doing screen fading or opening doors or sliding in game panels), which causes the initial delay to handle input events to run out, therefore immediately continuing with the first game frame -- without further input events that might have been entered in the meantime (like quickly pressing a direction key while the game is about to start)!

A workaround for this bug was the following: In the main menu, press the "pause" key, then press the "record" key in the tape recorder, which starts the game in immediate pause mode (before handling the first game frame). (Using this, it is possible to play level 32 of Supaplex Level Collection 02, for example. But this is just a workaround, not a solution.)

The solution is easy: Reset the input event delay timer after each finished screen change.

I've fixed this bug now as described. A new version of R'n'D with this bugfix will be available soon.
I have always experienced that the player does not get the first move, the game engine does.
Yep, that's the same bug.
Except 'always' is 'last few years, when I've been working through EMC levels', so might be EMC engine-specific.
Interestingly, this bug does NOT affect the native Emerald Mine game engine! That's because the EM engine starts with seven "empty" frames where the engine does -- nothing at all! That's because the EM engine is (contrary to the R'n'D or Supaplex engine, for example) a "synchronized" game engine, which consists of a number of "game cycles" that each consist of eight single game (or video) frames. During seven of these frames, the player (and all other elements) cannot start moving at all. (That's why the EM engine always feels a bit jerky -- input events may be delayed by up to seven game frames before they are handled, which is up to 140 ms, which is enough to feel that it is not an immediate reaction!)

As input events are initially delayed by seven inactive game frames in the EM engine anyway, the bug described above does not affect this game engine.
e.g. suppose I start a game in single-step mode. The first command I give does nothing, and the game goes through one action cycle. 2nd command does what it's supposed to do. As far as I know this is by design, but I have occasionally wondered if it wasn't. Holger?
As described above, it *is* indeed by design. But the "and the game goes through one action cycle" is technically not correct here, as no actions are ever performed during these inactive game frames.

What single step does when used with the EM engine right from the start is the following: It always waits until it gets input events, then unpauses the game and processes these input events, and finally it returns to pause mode -- when it reaches the next "full game cycle" (next full count of eight game/video frames, when the engine able to process the next input event).

As the first game frame (of the EM engine) that processes input events is the 8th frame, single step mode plays the first seven game frames and then goes to pause mode right before this frame! That's why there's always one initial step when using single-step mode that does nothing when playing levels that use the EM engine.

But as this feels wrong, I have fixed this so that single-step mode initially does not enter pause mode before reaching the first game frame that really handles input events. This results in the first "single-step cycle" now being 15 game frames instead of seven (which is indeed slightly noticeable), but overall it plays and feels more like it should now.

Both fixes will be released with the next version of the game, hopefully very soon.
filbo
Posts: 647
Joined: Fri Jun 20, 2014 10:06 am

Re: Input delay at the start?

Post by filbo »

> But as this feels wrong, I have fixed this so that single-step mode initially does not enter pause mode before reaching the first game frame that really handles input events. This results in the first "single-step cycle" now being 15 game frames instead of seven (which is indeed slightly noticeable), but overall it plays and feels more like it should now.

I imagine I will have some trouble getting used to this change, but will get over it.

Will this affect the playback of tapes produced under the old scheme? (I'm curious both as a matter of concern: don't break old tapes!; and technical curiosity: yes, it would affect them, but you've anticipated that and put in a quirk handler for old tapes?)
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: Input delay at the start?

Post by Holger »

I imagine I will have some trouble getting used to this change, but will get over it.
I hope so! :wink:
Will this affect the playback of tapes produced under the old scheme?
Definitely not! It just changes when single-step mode will automatically enter pause mode.
don't break old tapes!
Exactly! :)
Post Reply