[SOLVED] Draw calls can skyrocket when zooming, crashing...

Hey all,

I've been running into some really weird behaviour in Airscape recently. One of the visual effects involves zooming in very rapidly. I've noticed that on occasion, this rapid zooming can cause *incredible* lag spikes and recently I've heard reports of the entire game crashing during these zooming sections!

I've recently been doing some testing, and it's a very weird issue. Here are some of the things I've noticed:

• it happens very infrequently, and repeating the zooming process under the same conditions can either reproduce the problem, or work perfectly fine.

-When it does happen, the profile measurement for CPU 'draw calls' skyrockets, eventually reading as >100% of the CPU just used in draw calls.

-I've checked and double checked, and I'm not doing anything dumb like accidentally spawning hundreds of objects while zooming. It's definitely the zoom that causes it.

-It only seems to happen when zooming *quickly*. Slow zooms won't cause the issue.

-It only happens on a certain layout of the game (the map screen). Rapid zooming in other levels has never caused a problem.

-I can't find a reliable repro, no matter what I do. I do know it seems to happen more often when the GPU is already struggling.

Basically, I'm asking if anyone has any idea what could be causing something like this? It's driving me up the wall and it's a high-priority issue as it's crashing the game for a lot of users. What on earth could cause the draw calls to skyrocket all of a sudden like this, and so unreliably?

I wonder what's different about *that* layout? Captain Zero relies heavily on zooming with many layers going on, so I'd be interested to know as well. Keep us posted if you figure out anything else!

i cant help but im curious, is there a tilemap involved?

i had similiar failures but always thought of bad hardware or drivers, but most "weird & non good to reproduce" failures i had with tilemaps involved.

— afaik there's nothing too special about the layout. I've tried enabing/disabling layers but since it's so infrequent to reproduce it wasn't very helpful.

fldr no tilemaps.

sqiddster

My guess:

Every time the game zooms, in or out, the engine is checking each object to see if it's on screen or not so it knows to whether to draw said object.

If you have lots of objects, this can be an issue. Zooming in/out really fast is calling drawing checks on top of each other(guesswork).

You could try snapping to a certain scale? So the engine doing the on-screen check once?

*notes, i could be completely wrong about all of this XD.

It's surprising and a little disconcerting if layout zooms can make games crash on some machines (I am using a few as well....). Have you the ability to count how many objects are on screen at the approx times of the crashes and if that number changes greatly? My total guess would be a GPU instantaneous bottle neck as the number of objects to render goes up (zoom out) - although there could be something to — 's guess, I -er- guess! I find it hard to imagine a CPU bottleneck... so I'm guessing that the users who experienced this were celeron or i3 users with weak GPUs that could not cope with running a single thread nw.js and all of that scaling maths.

Does the map layout use any unique to that layout 3rd party plugins or webgl effects?

tomsstudio not a bad guess. But why does this only happen when zooming quickly? Shouldn't scrolling present the same problem? (it doesn't).

Colludium - the crash happens when zooming *in* so the number of objects on screen can only be getting *smaller*!

I've managed to recreate the problem multiple times on my super powerful gaming PC (only when using the integrated GPU though)

How many times a second does a scale need to be called?

Does it matter which browser is used?

newt 60, for a smooth zoom. And does 'calling a zoom' have some kind of performance implication that I'm unaware of?

Prominent haven't checked but the game is only designed to run in Chrome.

What is your full screen scaling setting and is the game full screen when this happens? Does it happen in a letterbox integer scale window? I'm imagining that this could be to do with an added GPU burden of having to find detail in previously small sprite images - perhaps the problem is here in how small (shrunk on screen) textures are handled before zooming in...??

How are you changing the zoom value?

If you are changing it via some equation, perhaps you should try rounding to the nearest hundredth decimal place.

It might be that the value is getting some strange number that is causing the crash, so you could try rounding it, and also clamping it.

Colludium I've seen most results at high resolutions which may well stress the GPU. I'm not sure I follow about how small textures are handled though. Is there any precedent for this being an issue?

Prominent I's using an equation, yes. Basically layerscale = layerscale * some_acel_value ^ dt.

I could try rounding it, but that's really weird if it's the case? Again, is there any precedent for something like this?

I really appreciate the suggestions everyone!

Try it without the delta time.

Just tried both rounding and doing it without dt, still crashed.

Here's a video of the crash in action. Note how long the video goes after frames have stopped showing up!

(Oh, and you might think the white particle has something to do with it but the results are the same with that disabled.)