During times that the drawing engine was overtaxed, keyboard input could be ignored for an extended period.
BYOND Version:480
Operating System:Windows XP Pro
Web Browser:Opera 9.80
Applies to:Dream Seeker
Status: Resolved (481)

This issue has been resolved.
Descriptive Problem Summary:
This is an issue that a few people have reported with A Miner Adventure. It doesn't seem like the type of issue that would or could be my fault (only a couple of users experience it), so it seems like it'd have to be a BYOND bug.

From Zaole's comment on the game's hub:
i'm getting craaaaazy issues with the controls. i'll hold the right key and then press the jump key, and after 10 seconds of walking to the right my character will finally decide to jump (this is single player not-hosted, no lag). i'll tap the right key for half a second and then tap the left key for half a second, and my character will walk 5 paces to the right and then 25 paces to the left. all sorts of weird random things

I can't provide too much information about this because I don't experience the issue, but do you have any idea what might be causing this?

Numbered Steps to Reproduce Problem:
1. Sneak into Zaole's house (or Ganing's house, he reported the issue too)
2. Log onto their computer.
3. Play A Miner Adventure.

Code Snippet (if applicable) to Reproduce Problem:

Expected Results:
The player's mob should be responsive (move when you hit the arrow key, jump when you hit the key, etc.)

Actual Results:
Long delays occur before the key presses or releases are processed. It sounds like the key events are being processed, just in a very delayed manner.

Zaole also said that the demos in my Sidescroller library run just fine. It sounds like there is a difference between the simple demos and the game that is causing this. My hunch was that the game is more graphically intense (every turf has a couple of partially transparent overlays, I know they can slow down drawing) and that the CPU time spent on drawing the screen caused the keyboard input to be less responsive than in the graphically simple demos. Unfortunately, Zaole said that the CPU usage, as reported by task manager, was 8-14%.

The demos don't have sound and the game does, that might be causing the issue too.

Does the problem occur:
Every time? Or how often?
In other games?
In other user accounts?
On other computers?

When does the problem NOT occur?

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit to download old versions for testing.)


I've experienced the same thing in your demo/library, which I assume you used for Miner's. From what I saw, it was interface related, though I didn't bother investigating. EDIT: I complained about this a long time ago, in some forum post you made, but I can't seem to find it now.
EDIT 2: I'm having the same problem in the version of Miner's I just downloaded from your hub. Though I've played previous versions of it correctly.
What's interesting here is that the same user experiences the problem in the game but not in the library. I'm sure there are some people who will always experience this issue (or something like it) if they have hardware rendering disabled or have old hardware. I'm hoping this is some weird issue (like this one) where a performance issue exists, but isn't noticed when the default framerate is used.

Edit: Do you experience the same problem in the most recent version of the library?
It doesn't seem like a performance issue, and from what I've seen of BYOND, turning off hardware mode actually increases performance. But let me turn it back on and see if I still have the problem. I'll also break your demo so you can fix the game =P
Hardware mode (being off) does seem to cause the problem.
However, if I host the game on dream daemon, and then join locally, the game will run fine either way.

Also, on a somewhat unrelated note. When you start the game, it outputs a ton of runtime errors:
runtime error: Cannot modify null.layer.
proc name: New (/turf/New)
source file:,45
usr: null
src: the turf (170,150,6) (/turf)
call stack:
the turf (170,150,6) (/turf): New()
Warning: further proc crash messages are being suppressed to prevent overload...
Any ideas, BYOND staff? Without maxing out CPU usage (which I'm not), I wouldn't expect anything to cause these kinds of delays in the processing of keyboard input. I can understand actions being delayed by fractions of a second, but people are seeing much longer delays than that.
I ran the game on my laptop and was able to experience the problem as people have reported it. I would tap the right arrow key (have it held for ~0.05 seconds) but the delay between the processing of the key down event and key up event would be much greater. I can put some demos together to try to get better timing, but based on how far my character moved there was about a full 1 second delay before the game acknowledged the key being released.

The game was running with a world.tick_lag of 0.3. After changing it to 0.4 the problem went away completely. The game has a partially-transparent overlay on every tile and it seems like this is expensive to draw, but I'm not sure why the processing of keyboard input suffers such extreme delays.
A demo that reliably reproduces the problem is probably the minimum we'll need; without that there's simply nothing testable at our end.
Ok, here's a demo:

In the demo you press the left and right arrow keys to move. You start moving when you press the key and stop when you release it. The demo will then tell you how far you moved.

The demo also generates a specified number of objects per tile (specified by the constant called "NUMBER"). When you increase the value of NUMBER and lower the tick_lag, you'll reach a point where the key press/release events are extremely delayed. With a low value for NUMBER you'll move 2 pixels from a quick tap, but with greater values you might move 300 pixels from the same tap.

edit: its probably worth mentioning that when you move hundreds of pixels from a quick tap, the screen is updated many times. It appears to be intense graphics that causes the problem, but the screen is still being drawn at a reasonable rate. Keyboard events are firing much more slowly than the refresh rate of the map. With lag, I'd expect the same slowdown in both.

This roughly corresponds to what happens in A Miner Adventure. Each tile has overlays to show the shadows and water. The game also has a default tick_lag of 0.3. Based on the user's hardware, the drawing of these objects can be costly enough to cause the problem seen in the demo. I suspect that if those users ran the demo with NUMBER = 2 or 3, they'd see similar problems.
Have you tried the demo yet? Just checking to see if it was sufficient, if not I can look into other ways of causing the problem.
The demo was submitted on a weekend, so no. I'll try it today.
Ok, just checking. I also have a hunch that the problem could be related to audio, but I wasn't going to bother looking into that if this was sufficient.
It would be nice if the server could detect this problem. How practical would it be for the server to be made aware of the client's CPU usage? Is it worth making the feature request?
Considering this only happens when you're hosting/playing in DS, at least for me, world.cpu should provide the necessary info.
world.cpu is a measure of the time spent executing DM code, it wouldn't include the time that Dreamseeker spends drawing the screen.
Maybe? If you want to know how much the application is using then just check the task manager?
Maybe? If you want to know how much the application is using then just check the task manager?

The point would be that the game could use this value (client.cpu?) to tweak world.tick_lag when it detects poor performance.
Only in single player games. Though, tick_lag shouldn't really be altered in the first place.
Whatever you're talking about isn't relevant. I'll restate the request in case the staff takes a look:

It would be nice if the server could detect this problem. How practical would it be for the server to be made aware of the client's CPU usage? Is it worth making the feature request?
Forum_account wrote:
Whatever you're talking about isn't relevant.

You can't effectively change world.tick_lag in a multiplayer game. One person's computer is lagging behind, so you're going to slow the entire game down for the other 100 players?
Page: 1 2