AllanR good idea, I thought the same thing, but how would I identify them? If I just pick all the objects with the boolean variable set, then I'll delete the originals and the duplicates.

I suppose I could store a list of UID's of all the originals, then delete everything with the boolean *except* the objects on this list! I just hate the idea of creating something only to destroy it right away.

Ashley that sounds like a good idea!

Fidasx Yes I'd obviously add a boolean, but the point is, recreate objects doesn't let you filter which instances are regenerated, it just regenerates them all.

the instance bank does look promising though, I'll look into it.

EDIT: Just looked into Instance bank, doesn't work because it requires loading all saved objects, not objects by region.

I looked into Grid Freezer too but it seems to be weirdly complicated, performance intensive, and doesn't preserve Z order.

Hi all,

I've made a wonderful optimization to Airscape by dividing up all the levels into a grid and destroying certain static objects which are too far away from the player, and using 'recreate initial objects' To bring them back when the player gets nearby again. All of these static objects are part of a family and so can be easily regenerated with the aforementioned action.

It works fantastically, however I've run into a fairly substantial issue and I was wondering if anyone could help out.

Airscape has a robust 'terrain motion' system where almost all the game objects can optionally be pinned to nodes that will move them in certain ways. Most of the static terrain instances that are subject to the optimization aren't pinned to nodes like this, but in most levels a few are. When using the create/destroy grid optimization, these pinned objects are destroyed/recreated - and when they are recreated, they are totally misaligned with their node and unpinned, since the initial state is reset.

Putting the nodes themselves in the family isn't an option, because they need to be operational even when the player is far away. Doing other sorts of fancy tricks won't work either - what happens when destroyed terrain is brought closer to the player by a node?

All I need is a way to exclude certain instances from the destroy/recreate process. Excluding them from being destroyed is easy, because I have full control over my method of destroying objects occupying a certain region. Excluding them from being recreated, however, is proving impossible as the 'recreate initial objects' action doesn't leave its loop exposed to the event sheet - it simply recreates all instances - and if those instances haven't been destroyed, it just creates another copy on top of them! If the action was instead 'recreate instance' I could do something with that - but as it stands, it does appear like there's no way to exclude certain instances from this action.

It's possible that I could create my own recreation function entirely, by storing valid objects in JSON format at start of layout (along with their coordinates) and recreating them as necessary, but this seems messy and expensive - I'd have to use the Nickname plugin to recreate objects by object type. Presumably for the 'recreate initial objects' action C2 does this internally, or something similar, but in a more efficient way.

Does anyone have a method that I could have missed? And does anyone thing that this is a feature worth looking at adding?

TiAm actual text objects.

Elliott Off the top of my head, the main advantage would be ease of use (don't need to manually put together a proper spritesheet and set character spacing etc). Other advantages would be lower graphics memory usage (presumably, although if it's pasting to super large textures this might be negated) and perhaps dynamic bolding/styling etc, as well as the fact that it's vector based so you can render large text without blurriness - although this can have bad implications as revealed by this very topic!

newt what do you mean? 60fps is 60fps and it will obviously be noticeable if scaling at any lower rate. Anyway that wasn't the cause of the problem.

Problem Description

It seems that Construct 2 (Or maybe just the browser itself) struggles to render very large text characters, with draw calls steadily increasing, eventually crashing the browser. In C2, this manifests when zooming in on a text object, and presumably also when text size is increased to very large values.

I'd wager that this isn't a problem that you'll be able to fix (I'm sure browser aren't design with super large text rendering in mind) however I think it would probably be a good idea to at least force the engine to stop rendering text when it's drawn over a certain size, to prevent very mysterious crash issues.

Attach a Capx

I can't seem to attach a file, here's a link: C2 text zoom bug

Description of Capx

Zooms in on a text object

Steps to Reproduce Bug

• Run the capx

Observed Result

Increasing draw calls, browser crash

Expected Result

Normal zooming

Affected Browsers

• Chrome: (YES)
• FireFox: (YES)
• Internet Explorer: (YES)

Operating System and Service Pack

Win 8.1 64bit

Construct 2 Version ID

r210

I figured it out!

It's the *text*!

Apparently if you zoom in too much when some text is on a zooming layer, the draw calls go absolutely bananas, and the browser will eventually crash! How nobody has run into this issue, I'll never know.

Thankfully I've been able to replicate it in a blank project and I'll be submitting a bug report.

Thanks for the suggestions everyone!

Edit: Here's a link to the bug report.

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.)

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!

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.