Changing client pixel offsets multiple times per tick caused slowdowns.
BYOND Version:479
Operating System:Windows XP Pro
Web Browser:Firefox 3.6.12
Applies to:Dream Seeker
Status: Resolved (480)

This issue has been resolved.
Descriptive Problem Summary:
When client.pixel_z is changed and there is a screen object, dream seeker will lag horrifically.

Numbered Steps to Reproduce Problem:
Modify the client.pixel_z in an isometric map while there is a screen object on the client screen.

Expected Results:
No lag and a smooth update in picture.

Actual Results:
Terrible lag, easily 3-4 ticks per update, not much for single use but in some cases it's detrimental.

Don't user both at the same time.

Extra notes:
This lag only occurs when pixel_z is changed if it remains the same then there's no issue, however I use a jump ability in my isometric game and as such the game has to update the client.pixel_Z frequently causing massive lag when there is a screen object.
I noticed a similar problem in a sidescroller I'm working on. If there was a screen object the controls would become unresponsive when you jumped. If I added screen objects to a simple sidescroller demo it would run fine. I couldn't isolate the problem so I stopped looking into it.
I know what you mean. It's unfortunate though, it just seems like byond is possibly changing the pixel_z of the object as if it's an overlay onto the client itself, it then changes the clients pixel_z and afterward it resets the objects pixel_z.

For single points of change, no big deal, but when this is called several times in a row, (like in your isometric demo if added to the screen adjustment) it can cause issues.
I had seen this happen in my non-isometric platformer library. I'm pretty sure I tried putting a basic test case together but couldn't reproduce the problem. Maybe I'll give it another shot.
the key is repetition, editing the pixel_z one or twice doesn't cause a visual effect. but when you start doing it, once per tick for 5+ ticks the lag becomes very apparent.

It may sound like I'm just whining because my game is lagging, but I doubt that the Byond development team expected such a result from changing pixel_z so frequently
I have been unable to reproduce this in a simple test. Can you construct a demo for us?
Here is a zipped library of the isometric pixel movement with added files to give the results in question.

To use: open the DME to confirm that the files under the "TEST" directory. when either one is on alone, the game works fine with jumping, however when both sets of code are implemented it lags horribly.

so, to see the main effect, make sure both files are included and then try to jump while in-game with the space bar. It lags even more wile moving.

Like I said before, I'm not sure if this is because of heavy built-in processing, but I doubt you would have wanted the system to move so slowly while these two effects are used in synchronous.
I can't seem to narrow this problem down to a simple example. It seems like having to draw screen objects bogs the system down by a constant factor. If I try to reduce it to a simple, toy example then its effect is not noticeable. In actual game situations it lags so much that key press/release events are ignored or severely delayed.

I can post a demo of it in action but I don't think that'll help. I tried to profile the world to verify that no proc of mine is taking more time than one tick but it's hard to get accurate statistics on the fly like that.

Edit: I think I narrowed down the problem:

The left and right keys show and hide the screen object. The up and down keys switch between a normal view (client is centered on the mob) and an offset view (client is set 32 pixels above the mob).

When the view is offset 32 pixels and the screen object is being shown the display lags severely. You might need to adjust world.tick_lag to make the problem more apparent.

It appears to be important that client.pixel_y is set twice in the same tick, first it's set to pixel_y then to pixel_y + 32. If you just set it once (to either pixel_y or pixel_y+32) then there is no slowdown.

It seems like changing pixel_y causes DS to redraw the screen. This is why it only happened when jumping in my game - only changing pixel_x means one refresh per tick. Changing pixel_y invoked another refresh so it was doing twice as much work (which is consistent with the constant factor decrease in performance).
Any idea on this? I seem to have it reduced to a simple enough situation that clearly the only difference is the presence of a screen object and it has big performance implications.
I will test this out tomorrow and see what's going on.
I noticed that when I'm running ( a .NET based image editor) on my computer the performance increases for seemingly all of my games. I'm wondering if the .NET framework has something to do with the handling of different coding languages and runtimes, mainly C# which (I assume) is what the Byond core is comprised from or at least is very close to.

As a result, while is open and the .NET framework is chugging away, dreamseekers performance seems to boost, not by a lot but enough that I noticed it easily. Not really a main focal point of the current issue, but I would like to look into this more if you'd like me to.
Tom wrote:
I will test this out tomorrow and see what's going on.

Any word on this? Have you been able to reproduce it?
I played with your demo but haven't been able to reproduce the problem yet. I'll play with tick_lag to see. Your comments make sense, though, and I think we can isolate this issue and hopefully put a patch in for 480 (which will be out as soon as we get back to the software).
Tom wrote:
I played with your demo but haven't been able to reproduce the problem yet. I'll play with tick_lag to see.

In the video the demo runs at 100 fps. When I press up (which offsets the client's eye) there is a very noticeable slowdown. If I switch the demo to 20 fps (not shown in the video) there is not a noticeable difference in performance when I press up.

It's also possible that it could be something specific to my graphics settings. I can provide more information if it's needed.

I think we can isolate this issue and hopefully put a patch in for 480 (which will be out as soon as we get back to the software).

That's good to hear.
Thanks. I'll do a more thorough test shortly and let you know if I can reproduce the problem.
I tested this quite a bit. On my machine, there isn't a noticeable difference. When I switch to software mode rendering, the performance slows down, but it's across the board (you should let me know if you are running hw or sw rendering just the same).

At any rate, I don't think we have to reproduce this visually to figure out what's up. The lag is almost certainly extra drawing and that's something we can track, and then it's a matter of trying to optimize it. Even if there is overhead due to the screen objects, it shouldn't be an order of magnitude more like you're seeing.
I'm using software. I'll check it out on my hardware based graphics downstairs when I get the chance. unfortunately that computer has about half the cpu speed of this one, so, as a result, I'm not expecting much of a difference, I'll check it out anyways though.

If it turns out to be an issue stemming from how the graphics controllers emulate the image on the screen then it may simply end up as just some slight mods to how the graphics are displayed.

perhaps a new option for dream seeker under the display so it'll run with lesser graphics but faster speed? I dunno, I'll have to see how it runs on an HW based render first.
I've been using hardware rendering.
I just changed to hardware rendering using a Galaxy Geforce 8400. The issue isn't as bad but it's still there. =\
I found a fix for the issue as FA reported it with his demo. I believe that takes care of this report, but if issues pop up in the future a new report should be filed with a new demo.
Page: 1 2