Preloading sprites into Video Memory issues

Discussion and feedback on Construct 2

Post » Fri Nov 07, 2014 6:06 pm

Ah, maybe I was wrong - and it actually is probably more useful that way anyway. If you create an object at runtime then you might create it again later even after destroying it, so keeping its textures loaded helps prevent jank on the next creation.
Scirra Founder
B
402
S
238
G
89
Posts: 24,628
Reputation: 196,023

Post » Fri Nov 07, 2014 6:22 pm

Ashley wrote:Ah, maybe I was wrong - and it actually is probably more useful that way anyway. If you create an object at runtime then you might create it again later even after destroying it, so keeping its textures loaded helps prevent jank on the next creation.


Weeell not necessarily xD
Action to unload object would be really nice.

Scenario of how this could be useful. I was struggling with this for mobile games
You have a background made from 20 different objects and a lot of instances of them (tilemaps, tileddbg and sprites), and then on start of the layout you could simply paste all this objects into a Paster plugin and destroy/unload those objects because you don't need them anymore for this layout.

So instead of ending up with a bunch of different objects you have only one object that uses less memory and is easier to manipulate.

From my tests 1 sprite with few animations, each one have four frames with big images takes about 50mb of image memory.
After adding a Paster and pasting all of this sprites memory goes to about 60-65mb - Paster+current sprite loaded into a memory.

15mb or even 30mb instead of 50mb it's quite a lot for mobiles :)

Please consider adding an option to unload objects from memory, pretty please ^^
ImageImageImageImage
B
158
S
67
G
43
Posts: 2,603
Reputation: 36,003

Post » Sat Nov 22, 2014 9:29 am

Shinkan, i'm with you on this, we need more control over video memory and an unload sprite action.

I stopped coding with Construct 2 becos of this issue and the stuttering performance I got on both a high-end PC and Mobile.
B
34
S
5
G
1
Posts: 78
Reputation: 3,412

Post » Sat Nov 22, 2014 7:59 pm

I thought a big point of the "room" discussion was partly memory management....but if I recall Ashley didn't feel we need any memory management. Even suggested using multiple layouts among other things.

My issue is multiple layouts means forget making any open world or dynamically created games.

We simply need 2 system event/action to do two things:
Unload any unused sprites/textures.
Unload specific sprites/textures. It can delete all instances as well.

On a similar note, if we can unload textures we should be able to pre-load them as well.

Label it an advanced feature. Warn people it is not advised to be used unless necessary. Tell people misuse could break games. But it is honestly something we need.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Sun Nov 23, 2014 10:31 pm

It's worth remembering some of the tests from the jerkiness thread (I think) which demonstrate that there are overheads associated with creating objects in addition to the video memory used. The conclusion there was reusing sprites was far more efficient than creating and destroying them.
A big fan of JavaScript.
B
76
S
20
G
76
Posts: 2,284
Reputation: 47,552

Post » Sun Nov 23, 2014 11:15 pm

Colludium wrote:It's worth remembering some of the tests from the jerkiness thread (I think) which demonstrate that there are overheads associated with creating objects in addition to the video memory used. The conclusion there was reusing sprites was far more efficient than creating and destroying them.


Yes, that is true and you should alway recycle your objects if you can. But sometimes you need only "one use" objects. And if that kind of object been used by player or whatever it will not show anymore in current layout. So there is no need to keep it in memory.

Like in my background example. I want some objects only for few ticks and after that they are not needed anymore. I don't really care about jerkiness on start of the layout because level is creating at this specific moment.
ImageImageImageImage
B
158
S
67
G
43
Posts: 2,603
Reputation: 36,003

Post » Sun Nov 23, 2014 11:16 pm

I liked the background example, very neat.

Edit to add: The creation and distruction of the same object type during runtime sometimes caused variations in dt so it would misalign with vsync, causing occasional frame drops or partial draws. My point about recycling is that, unless you are memory constrained (mobile, & like your example @shinkan) there is something to be said for holding reusable game objects like bullets in stasis outside the layout, and only bring them into play at the appropriate time. I agree that this has no bearing on single use objects and I didn't mean to confuse matters.
A big fan of JavaScript.
B
76
S
20
G
76
Posts: 2,284
Reputation: 47,552

Post » Mon Nov 24, 2014 1:00 am

@Colludium
ahh. I see what you meant and Yes that is true as well.
ImageImageImageImage
B
158
S
67
G
43
Posts: 2,603
Reputation: 36,003

Post » Mon Nov 24, 2014 1:51 am

Colludium wrote:I liked the background example, very neat.

Edit to add: The creation and distruction of the same object type during runtime sometimes caused variations in dt so it would misalign with vsync, causing occasional frame drops or partial draws. My point about recycling is that, unless you are memory constrained (mobile, & like your example @shinkan) there is something to be said for holding reusable game objects like bullets in stasis outside the layout, and only bring them into play at the appropriate time. I agree that this has no bearing on single use objects and I didn't mean to confuse matters.


This can work wonders if you have a lot of bullets flying around (or any other small objects). Explicit recycling of bullets cut my CPU usage drastically. However, I think it depends on how many objects you are dealing with. I have up to 1500 bullets onscreen at once...were there only a couple hundred, the difference might not be so dramatic.
Don't lose your work. Backup your game with Dropbox.
B
44
S
10
G
10
Posts: 1,106
Reputation: 9,202

Post » Mon Nov 24, 2014 3:31 am

TiAm wrote:This can work wonders if you have a lot of bullets flying around (or any other small objects). Explicit recycling of bullets cut my CPU usage drastically. However, I think it depends on how many objects you are dealing with. I have up to 1500 bullets onscreen at once...were there only a couple hundred, the difference might not be so dramatic.


Could you help explain what you mean by this exactly? For example, what is the lifespan / timeline of a bullet exactly?

Thank you so so much
Made Cosmochoria - www.cosmochoria.com
Currently working on Slayaway Camp - www.slayawaycamp.com
B
27
S
8
G
3
Posts: 384
Reputation: 5,020

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: dop2000 and 4 guests