Hello everyone,

Coming from C2, I refrained to use the SetColor effect on my (numerous) spritefonts since I noticed it was quite taxing on the CPU. In general I used as little effects as possible to run on older configurations.

Now I see in C3 you can Set the Color directly as an Appearance action. I read it is more like 'Tint' than 'SetColor' but for spritefonts it's perfect.

Is it costly in terms of performance to use this feature ?

In my case I can have hundreds of spritefonts visible at the same time, either black or greyed. The text is always a figure from 0 to 9 and I used to have the two colors in my spritefont sheet with 0-9 being the black numbers and A-J being the grey numbers as a workaround to save on CPU. Setting the color the new way would definitely be a more flexible way to do it.

My second question is unrelated and is regarding Picking.

Would you say this :

is much more efficient than this ?

I used to do it the second way but I recently realized that grouping all the different checks in one single Picking could maybe be more efficient since every Sprites would need to only be checked and picked once. Do you think that's true ?

Thanks for your opinion :)

Have a nice day

I did, but the memory won't decrease back so much, plus that means giving up on the performance improvements Ashley said were linked to bigger spritesheets :x

But if this lack of flexibility is voluntary I'll be moving on and I won't bother you with more questions.

What about the absence of automatic purge at layout restart though ? I can't help but think it contradicts the manual.

Thank you again Ashley for your quick answers :)

1) Spritesheeting

Ok so this spritesheeting is normal behavior... I don't question its general usefulness, but it feels kinda counterproductive in certain instances, especially when it groups objects that are never meant to appear together. Sometimes the algorithm doesn't have a choice to do so I understand, but still.

For example in my project I used to have a sprite with 100 frames of 800x800 (reprensenting a whopping 300mb by itself), but since there would always only be one that'd be used per layout I splitted it in a hundred sprites 800x800 instead.

With the spritesheeting this optimization is diminished since the game needs to load at least a spritesheet each time, which represents 4 sprites (3 being useless).

It's probably not feasible, but since we can consult the Spritesheets it would be great to be allowed to isolate one or more sprites, effectively saying : "these must not be grouped with other sprites". That would save a lot of image memory and enable anyone to build their own Performance/Memory Scale sort of.

Maybe it's not that big a deal on desktop, although it probably depends on the project, but I suppose for mobile it wouldn't be negligible?

2) No purge at new layout

I read and re-read the layout-by-layout memory management page, and the simple test I produced directly contradicts it. Supposedly :

When the layout ends, all images that are loaded but not used on the next layout are released from memory.

If an object is not placed in the layout view, but events create it at runtime, its images are not pre-loaded.

In the example I linked, after you've created sprites through events that bump the memory usage from 2mb to 34mb, restarting the layout should purge the memory back to 2mb since they are not on the next layout. And it's not the case, it stays at 34mb and memory must be purged manually :x

Investigating a little more I think I bumped into the problem, and to me it seems reaaaaaally severe.

Here is a test case for both C2 and C3 :

https://www.mediafire.com/file/b3ij98kz87g6luq/ConstructMemoryProblemCase.7z/file

In each of the projects, I have 8 sprites of the size 800px*800px.

In C2

If you create these sprites on an empty layer one by one, the memory progressively increases. From base 6.6mb to 9mb to 11.5mb etc... That's around 2.5mb per sprite added.

If you restart the layout, the memory is purged and you go back down to 6.6mn.

In C3

• C3 groups the sprites into spritesheets of 2048*2048, and these can hold 4 sprites of 800px*800px at a time. Clicking Tools >> View Spritesheets you can see Sprites 1 to 4 are together and 5 to 8 are together.
• if you create sprite1 on an empty layer the memory increases by a massive amount, from 2mb to 18mb right away!
• try to create sprite2 and... the memory doesn't budge.
• try to create sprite5 (which is on the second spritesheet) and the memory jumps again to 34mb.

==> conclusion : C3 loads the ENTIRE spritesheet containing a needed sprite, even if the other sprites inside are not needed. That's a massive waste of memory if you ask me!

Even trying to unload unused memory manually won't change this memory load.

It is a very big problem and I really don't think it's intentional.

• Another problem : If you restart the layout... the memory stays the same even though the sprites are not here anymore ! You have to manually purge the memory using the system action "Unload Unused Images from Memory".

==> memory is not automatically purged on start of layout!

This to me seems like another very big problem that didn't exist in C2.

I hope I'm doing something wrong because these would be fundamental problems for the image memory management system, wouldn't they? I reproduced the case easily with a basic project, so that convinced me the problems I first encountered weren't related to the fact I was trying to convert a pretty big project from C2 to C3.

Thanks in advance for your opinions on the matter. If I need to write a bug ticket, I can, just tell me.

Thank you Ashley. If you don't think it is alarming then I won't dig too much into it. I'll test my game again on older configurations and see if the performance/memory tradeoff is problematic or not :)

Oh, right, that's swiping. I did offer you a classic desktop scroll bar that you need to click.

I kept clicking on your own scrollbar thinking that it was completely broken x)

Glad you're satisfied by ReallyBasic's solution then.

Hey everyone,

I'm converting a C2 project to C3 and I've solved most of the little bugs it created. However I've noticed the (estimated) image memory used you can see in the NW.js debugger has inflated by 50% in the process. I noticed the Runtime used also impacts this value.

Here is the debugger from C2 : 194.4mb

Here is the debugger from C3 (with C2 runtime) : 243.9mb

Finally here is the debugger from C3 (with C3 runtime) : 313.4mb

Is it a known issue or should I a file a bug report ?

Mobile is not a primary target platform but I plan to release the game there in the future, so memory issues can be a big deal.

I've found this report that's kinda similar but the problem was apparently spritesheets being sometimes bigger than 2048*2048 and there's no object in my project that's even close to being 2048 pixels wide.

github.com/Scirra/Construct-3-bugs/issues/2094

Thanks in advance for your opinions :)

Here's how I'd do it :)

https://www.mediafire.com/file/j1dw83h8w21n5j1/ScrollBar.c3p/file

- I didn't alter how you parametered the bar on start of layout

- the collision box of your BrowserSliderMainPart was broken

- you had problems with Touch.Y because it gives a position on the whole layout. What you want is the position relative to the BrowserUI layer, so you need to use the following expression instead : Touch.Y("browserUI")

- You need to define a value "scrollpercentage" between 0 and 1. When the bar is at the top, this value = 0, when it's at the bottom, this value = 1. To get this you compare Touch.Y("browserUI") with 189 (the minimum) and 1080-scrollbar.height (the maximum)

(the "padding" is here so that wherever you click on the scrollbar it won't move right away, it waits for you to actually move)

- you can move the scrollbar accordingly

- you can also scroll to (0,scrollpercentage*layoutheight)

Hope this helps :D