GPU intensive drawing lags screen dramatically

ID:1954623
 
Oct 4 2015, 12:59 pm
(See the best response by Super Saiyan X.)
I've run into this sort of roadblock with BYOND before, having tried to work with making things directly in softcode. I wanted to know if there were any tricks to shaving off some of the time BYOND needs to render things on screen.



The update loop is supposed to update at 30 FPS. Each of these is a 10x10 icon, whose icon_state and color are changed every tick (this is for benchmarking). I'm getting about 10-12 FPS in this example.

I think someone said something about the sprites needing to be re z-sorted every tick which contributes to the slow draw time. Any feedback would be appreciated.
Oct 4 2015, 1:09 pm
why not just use text mode
Oct 4 2015, 1:41 pm
SSX:
why not just use text mode

I'll be using graphics as well as on-screen DMI text, so text-mode won't be doable.
Oct 4 2015, 1:42 pm
You loop uses "sleep world.tick_lag" with world.fps = 30, right?
Oct 4 2015, 1:43 pm
Correct. Is there a more efficient way to go about doing this? The topmost procedure calls are essentially this:
proc/event_main()
    event_init()
    event_load()
    event_startup()
    while (app.running == true)
        event_update()
        sleep(world.tick_lag)
Oct 4 2015, 1:47 pm
Re-sorting is probably not the bottleneck. I would recommend you be sure to separate out DD and DS here, because you're likely incurring a penalty for the huge number of appearance changes every tick--and that would impact the server quite a lot too.

We're looking at what, 40x30 here? That's 1200 atoms being accessed and 1200 new appearances created every tick, with network traffic and memory allocation for each. That's going to have a dramatic impact on both ends. Since it's unlikely you're using more than 128 actual sprites, that's actually one of the kindest things your benchmark does, since at least those don't have to be created anew constantly--except in software mode.
Oct 4 2015, 1:59 pm
I tried it in both DD and DS to see how they compared:

In DreamSeeker, the updates were normally smooth with a few lockups. On my tablet the lockups are much more common and have a lot less FPS between them.

In DreamDaemon, the updates were extremely smooth, but after about a second completely lock up when connected via DreamSeeker. I checked the memory stats in DreamDaemon and I was pretty shocked at the results

Prototypes:
obj: 3576 (29)
mob: 3592 (1)
proc: 32144 (159)
str: 26630 (894)
appearance: 72967030 (350675) <-- This keeps increasing
id array: 32444 (293)
map: 13044 (40,30,1)
objects:
mobs: 128 (1)
objs: 115200 (1215)
datums: 234624 (3861)
lists: 13152 (9)


So it appears that appearances are indeed the issue which cause the lagging. I took out the color changing aspect to use primarily the sole icons, and the appearance value remained at a constant, low value thereafter. The framerate was smooth as well on both DreamSeeker and DreamDaemon. What sort of behavior yields more appearances besides using atom.color? Do pixel offsets have any impact?
Oct 4 2015, 2:02 pm
In response to Mr_Goober
Best response
Mr_Goober wrote:
I tried it in both DD and DS to see how they compared:

In DreamSeeker, the updates were normally smooth with a few lockups. On my tablet the lockups are much more common and have a lot less FPS between them.

In DreamDaemon, the updates were extremely smooth, but after about a second completely lock up when connected via DreamSeeker. I checked the memory stats in DreamDaemon and I was pretty shocked at the results

Prototypes:
obj: 3576 (29)
mob: 3592 (1)
proc: 32144 (159)
str: 26630 (894)
appearance: 72967030 (350675) <-- This keeps increasing
id array: 32444 (293)
map: 13044 (40,30,1)
objects:
mobs: 128 (1)
objs: 115200 (1215)
datums: 234624 (3861)
lists: 13152 (9)


So it appears that appearances are indeed the issue which cause the lagging. I took out the color changing aspect to use primarily the sole icons, and the appearance value remained at a constant, low value thereafter. The framerate was smooth as well on both DreamSeeker and DreamDaemon. What sort of behavior yields more appearances besides using atom.color? Do pixel offsets have any impact?

id:1863944

Oct 4 2015, 2:07 pm
Oh, this is very helpful. I thought something like that existed on the forums somewhere but I couldn't remember where. This is great. I'm guessing movable atoms mentioned in pixel offsets "handled specially" mean that it's omitted from adding new appearances, which is essentially what I was hoping for. I can work around this.