ID:1294769
 
BYOND Version:499
Operating System:Windows 7 Pro 64-bit
Web Browser:Firefox 21.0
Applies to:Dream Seeker
Status: Open

Issue hasn't been assigned a status value.
Descriptive Problem Summary:
When I place an animated atom on the map, the CPU usage spikes significantly. The number of these animated atoms seems to make no difference, so long as there's at least one. The world is running in hardware drawing mode.

The Dream Seeker's function profiler indicates that this CPU usage is not from my code. My testing narrowed it down to happening only when animated icons are being displayed.


Numbered Steps to Reproduce Problem:
Create a 5x40 icon. Animate it however you please, with 10 frames and loops only once. Give an atom this icon and place it on a 100x100 map. Anywhere on the map. Only one.

Alternatively, you can make a 5x5 icon and animate it by changing the pixel offsets at runtime. My testing yielded the same results: Significantly increased CPU usage by dreamseeker and framerate drops.

Code Snippet (if applicable) to Reproduce Problem:
//The isometric world parameters are:
world

fps = 25

view = "22x26"

icon_size = 40

map_format = ISOMETRIC_MAP


Expected Results:
The world is running smoothly with no CPU spikes or framerate drops.

Actual Results:
The CPU usage of dreamseeker goes up significantly and the framerate is low enough that the game becomes unplayable.

Does the problem occur:
Every time? Or how often?
Every Time
In other games?
Haven't tested, but other users have supported this anecdotally
In other user accounts?
Haven't tested; I think this is irrelevant
On other computers?
Yes. It happens consistently on other computers.

When does the problem NOT occur?
When there are no animations currently being drawn.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit http://www.byond.com/download/build to download old versions for testing.)
I don't think so.

Workarounds:
None known.

Examples/Demos:
http://files.byondhome.com/D4RK354B3R/Apprentice.zip

Generate the maze, "summon a wisp", and WSAD for movement.
I will test your demo, but I tried the example project (100x100 iso map, single animated 5x40, code you provided) and it didn't use up any noticeable CPU for me. Just to be on the same page, when you run that exact situation what happens exactly?
When I run your demo (which is beautiful BTW), the cpu sits at about 4% steady-state and goes up to 7% when moving, which isn't ideal but doesn't seem nearly as bad as you are getting. I don't detect any problems aside from slight jerkyness with the lighting, but that may just be the code or the inefficiencies of our movement system. I wonder if something else is interfering.
This is very bizarre, because among the people I have tested this demo with, about 90% of them reported similar CPU usage to what I was experiencing. Only a handful of people with high end computers reported lowish CPU usage.

The framerate drop and CPU usage problems get worse when the camera nears the center of the generated 100x100 maze, but improves when the camera nears the edges of the map.

The jerkiness of the lighting is inherent to the lighting system; Brightness is not being computed per pixel. Instead, pixel brightness is interpolated between the computed brightness for each turf vertex. I think it's unrelated to the CPU usage problems.

Perhaps my conclusion about isometric animations being the cause of this problem is wrong. If that's the case, I have no idea what may be causing the CPU usage problems for me and the others who've tested the demo.
I can confirm massive CPU spikes with the demo above latest version of BYOND.
Trying out this demo, I found that after generating the maze and before summoning the wisp I was averaging about 33% CPU usage. After summoning the wisp, it jumped up to about 45% average.
In response to Tom
Tom wrote:
I will test your demo, but I tried the example project (100x100 iso map, single animated 5x40, code you provided) and it didn't use up any noticeable CPU for me. Just to be on the same page, when you run that exact situation what happens exactly?

When I run this scenario, I get 4% CPU usage. I guess my diagnosis for the cause of this problem is wrong.
I'll play with it more and see what I can find. Maybe I didn't walk around enough.
D4RK3 also sent me a copy of this that uses top down mode instead. It demonstrates an even more dramatic effect (15% to 42%, average) than the isometric version. Profiling shows that the only proc being called constantly (wispDust's Tick) is still averaging 0.0s CPU time. I have a 2.5GHz Core 2 Duo for what it's worth.
I'm not sure if it is entirely fair to directly compare the isometric version to the topdown version.
There are a number of things in the topdown version that don't work the same as they do in the isometric version, like the lighting system and the view-size and the displayed number of atoms.
I still don't think that the lighting system is related to the problem, but in the isometric version, there are two overlays for every wall object (one for each face), and in the topdown version there is only one overlay for each wall object (one for the south-face).
If the lighting system does play a part in this problem, though, the lower number of overlays being displayed does explain why Audeuro is getting less CPU usage.
Here are some interesting statistics I got on my Core 2 Duo. These were all taken with the mob standing still:
CPU Percentages:

At edge: 6%

Towards center: 20%

At edge with wisp: 20%

Towards center with wisp: 40%

At edge with maze generated: 8%

Towards center with maze generated: 35%

At edge with wisp and maze: 47%

Towards center with wisp and maze: 50%

I noticed that with both the wisp and the maze, the game completely freezes for about 15 seconds, but the CPU doesn't go down when I'm able to move again. The fact that the CPU is higher at the center of the map, than the edge seems very strange to me. Anyway, all I can think of is raising the sleep() delays of any infinite loops in your code, and making sure they use spawn() when necessary.

I hope this gets figured out. I hate to see nice looking games lagging.
I walked around for a while and I'm not seeing any of these issues. Can someone maybe construct a simpler demo with some source code?
In response to Tom
This might be a silly question, does anyone have use graphics hardware turned on?

I didn't and I had these large spikes.
I am testing with hardware on. That would definitely be good to know re. other users.. I'll try it off and see. It would make a lot of sense if this were a software mode issue since the gpu is doing the rendering in hardware. Should be fixable I think once we can reproduce it.
D4RK3 and I were both using hardware mode.
Personally, Mine would jump between 9-11, I however have really high specs 8 core 3.10 ghz, 16gb ram so that is probably why. Very interesting concept though, hopefully things can be worked out!
I tried the demo, repeated the steps and found that the cpu jumped to 40 making the whole game lock up for me.

edit: oddly running the game a second time only locks up for about 2 minutes after summoning a wisp then the game returns to its normal speed.
In response to Multiverse7
Multiverse7 wrote:
I noticed that with both the wisp and the maze, the game completely freezes for about 15 seconds, but the CPU doesn't go down when I'm able to move again. The fact that the CPU is higher at the center of the map, than the edge seems very strange to me. Anyway, all I can think of is raising the sleep() delays of any infinite loops in your code, and making sure they use spawn() when necessary.
I hope this gets figured out. I hate to see nice looking games lagging.

There is only one infinite loop in the game: the main logic loop. All it does is call the Tick() for active atoms in the game, like the wisp and the player. However, all profiler results indicate that the execution of Tick() for just about all of these takes a negligible amount of CPU time.

Increasing the delay in the sleep() for this main logic loop has almost no effect upon improving the CPU usage of the game.
You may see improved behavior for this in 499.1195. I did a little trimming of the icon list before any sorting to hopefully help a little, removing any blank and unclickable icons that might simply be using up unnecessary cycles. That said, I think the sheer number of icons being displayed is the crux of the problem. A 40x40 icon size means near the center of the map, it's trying to draw in excess of 3000 when the map has been generated. And that's with purging anything out of view.
Played the demo. Slowed down my computer.
Page: 1 2