@Hopscotch have you tried the 0.13.5 build?
you wrote "Tables, was the only aspect which under heavy load was showing problems to me in the past (v12 and before), completely broken in v0.13.2.
As of v.0.13.3 tables are looking stable."
So 0.12.20 has memory leakage, as confirmed by many, as does 0.13.2
On this page stevej wrote "It's looking like the FireTV/0.13.3 build doesn't have this issue. I will continue to investigate the nightly/0.13.2 (0.14.x) build."
and
"So it looks like tables aren't actually the issue, it appears to be the text to image code. I'm having our graphics programmer take a look at it." @stevej in which build do you think that the above will be fixed?
Now in the thread for rc 0.13.5 it says:
"Reverted garbage collection fixes for Creator. Memory usage and performance should be the same as 0.12.20."
If it's based on 0.12.20 and not 0.13.3 then it is likely to have memory leakage too.
@Hymloe said:
Looking forward to getting my hands on a build with this stuff in it, so I can test it with my project. It's not actually in a released build yet is it?
Have you had any response in regards to any GS programmer looking into the projects that you have provided for investating the memory leakage?
@MarcMySalad , I have not had a chance to run v0.13.5 through the tests. Other priorities kept me from putting the hours in it will take. I am hoping to look at it tonight, EU time.
@Hopscotch said:
MarcMySalad , I have not had a chance to run v0.13.5 through the tests. Other priorities kept me from putting the hours in it will take.
The amount of memory the table takes up has nothing to do with what's displayed. A table that takes X amount of memory will still take X amount of memory whether you display the data or not. There is a bug we've found in the current dirty build where the memory used to display text is never being freed, but that's separate from any table issues.
@stevej said:
The amount of memory the table takes up has nothing to do with what's displayed. A table that takes X amount of memory will still take X amount of memory whether you display the data or not. There is a bug we've found in the current dirty build where the memory used to display text is never being freed, but that's separate from any table issues.
So all tables are loaded into ram every scene or just when called by any table function?
@MarcMySalad said:
Have you had any response in regards to any GS programmer looking into the projects that you have provided for investigating the memory leakage?
I haven't had any specific communications with the GS team, no. I've been chatting to @Hopscotch and he has a copy of my project, which I think he may have tested against some new GS. I'm not too sure.
@stevej said:
The amount of memory the table takes up has nothing to do with what's displayed. A table that takes X amount of memory will still take X amount of memory whether you display the data or not. There is a bug we've found in the current dirty build where the memory used to display text is never being freed, but that's separate from any table issues.
Which GS release will the table fixes go into? When will it be available?
Would you be able to give a semi-detailed description of the fixes at some point? Even if it's just a post here on this thread. It'd be good to know what operations were triggering the problem, and what changes and fixes went in.
If possible, it'd also be great to hear a few more tips and explanations of "things to look out for with tables". Like, what will cause them to use up more memory? Any other specifics about how GS handles tables, etc. Any gotchas, or common mis-uses of tables, or behaviours that don't work well with table cells, or whatever.
That'd be really helpful. Keen to check it out, as this might revive my project that I've been unable to work on.
Looks like we plugged the leak in 0.14 that Hopscotch and others have been seeing. This should affect any projects that change the image being applied to an actor (this includes text that changes). Essentially, some of the memory used to create the previous texture wasn't being freed when the new texture was created. The fix should be included in the next nightly build.
@Hymloe said:
Which GS release will the table fixes go into? When will it be available?
Would you be able to give a semi-detailed description of the fixes at some point? Even if it's just a post here on this thread. It'd be good to know what operations were triggering the problem, and what changes and fixes went in.
If possible, it'd also be great to hear a few more tips and explanations of "things to look out for with tables". Like, what will cause them to use up more memory? Any other specifics about how GS handles tables, etc. Any gotchas, or common mis-uses of tables, or behaviours that don't work well with table cells, or whatever.
That'd be really helpful. Keen to check it out, as this might revive my project that I've been unable to work on.
@stevej said:
Looks like we plugged the leak in 0.14 that Hopscotch and others have been seeing. This should affect any projects that change the image being applied to an actor (this includes text that changes). Essentially, some of the memory used to create the previous texture wasn't being freed when the new texture was created. The fix should be included in the next nightly build.
Just to clarify... do you mean... "any project that changes the image of an actor, at any time, in any way"? Or specific ways of changing the image? Like, changing it to a table cell value? Or using a specific behaviour?
And what do you mean, "This includes text that changes". Changes in what way? Do you mean a "Display Text" behaviour, where the text changes, to say, another attribute value such as a score or timer value, or a table cell value, or...?
@Hymloe said:
Just to clarify... do you mean... "any project that changes the image of an actor, at any time, in any way"? Or specific ways of changing the image? Like, changing it to a table cell value? Or using a specific behaviour?
And what do you mean, "This includes text that changes". Changes in what way? Do you mean a "Display Text" behaviour, where the text changes, to say, another attribute value such as a score or timer value, or a table cell value, or...?
When you use a Display Text behavior, every time that behavior is run (which is generally once a frame), the engine tests the text to see if it's different from the last time (frame) it checked. If it is, it takes that text and creates a bitmap from it, using the font, color, etc parameters your gave, and applies that texture to the actor.
So let's say you have an attribute that you're incrementing from 1 to 100, and you're using Display Text to show the attribute value. As the game runs, the engine will generate 100 textures, one for each time the attribute changes. Of course, as it generates one it's supposed to delete the previous one, so the amount of memory should approximately be constant (it will actually grow slightly, as the texture space needed to display a "100" is bigger than the space needed to display "1").
@stevej said:
So let's say you have an attribute that you're incrementing from 1 to 100, and you're using Display Text to show the attribute value. As the game runs, the engine will generate 100 textures, one for each time the attribute changes. Of course, as it generates one it's supposed to delete the previous one, so the amount of memory should approximately be constant (it will actually grow slightly, as the texture space needed to display a "100" is bigger than the space needed to display "1").
Thanks Steve, great to know. So that issue should be fixed in the upcoming build?
And what were the details for the Image issue you mentioned?
@Hymloe said:
And what were the details for the Image issue you mentioned?
If you use the Change Image behavior, you may run into the same issue as with text. This may also apply to the Animate behavior, if you don't have Preload Art checked.
@stevej said:
If you use the Change Image behavior, you may run into the same issue as with text. This may also apply to the Animate behavior, if you don't have Preload Art checked.
Also, I've never really figured this out...
What does "Preload Art" actually do? What effect does this have?
When are the images loaded, and how are they handled differently, if Preload Art is checked or not? Why would you use Preload Art, and why wouldn't you not use it?
What's the general rule? Check it, or don't check it, for your average image in a game project?
@stevej thanks for the info above. What time frame are we talking about in regards to when the next 0.14 build will be released that include the critical display text / images fixes you mentioned above?
@MarcMySalad , I had a chance to look at the 0.13.6 build and it looks good. GS is still looking into some issues but its better than it has ever been.
Even displaying a continuously growing string of randomized text has its expected spikes as it builds new bitmaps, but cleans up after itself. (The spikes are zoomed in, i.e. small in relation to memory use)
@Hymloe said:
Also, I've never really figured this out...
What does "Preload Art" actually do? What effect does this have?
When are the images loaded, and how are they handled differently, if Preload Art is
checked or not? Why would you use Preload Art, and why wouldn't you not use it?
What's the general rule? Check it, or don't check it, for your average image in a game project?
Preload art (on by default for every actor) loads the image of the actor into RAM when the app loads. If you have it on for all actors and you have lots of images then it will make the initial loading very slow and might crash your app too if the combined memory usage of all your images combined with the overhead of the GS engine is greater than (roughly) device RAM divided by 2.
You can calculate the RAM usage for every single image in your project by the formula width x height x 4 / 1024 = the amount of device RAM in KB that the image in question will require.
Modern devices load images fast so with that in mind there is no real advantage with using preload art at all in my opinion. On the other hand you probably have to use preload art on for actors with animations right now (as a potential workaround) based on the info from @stevej above (which was very interesting info and something I will have to look into in my projects - that display text/image/preload-for-animations memory leak bug is a real nasty one that in all likelihood explains a thing or two for bigger projects so really looking forward to a fix for that in 0.14)
Comments
@Hopscotch have you tried the 0.13.5 build?
you wrote "Tables, was the only aspect which under heavy load was showing problems to me in the past (v12 and before), completely broken in v0.13.2.
As of v.0.13.3 tables are looking stable."
So 0.12.20 has memory leakage, as confirmed by many, as does 0.13.2
On this page stevej wrote "It's looking like the FireTV/0.13.3 build doesn't have this issue. I will continue to investigate the nightly/0.13.2 (0.14.x) build."
and
"So it looks like tables aren't actually the issue, it appears to be the text to image code. I'm having our graphics programmer take a look at it."
@stevej in which build do you think that the above will be fixed?
Now in the thread for rc 0.13.5 it says:
"Reverted garbage collection fixes for Creator. Memory usage and performance should be the same as 0.12.20."
If it's based on 0.12.20 and not 0.13.3 then it is likely to have memory leakage too.
Have you had any response in regards to any GS programmer looking into the projects that you have provided for investating the memory leakage?
@MarcMySalad , I have not had a chance to run v0.13.5 through the tests. Other priorities kept me from putting the hours in it will take. I am hoping to look at it tonight, EU time.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Understandable
Much appreciated
The amount of memory the table takes up has nothing to do with what's displayed. A table that takes X amount of memory will still take X amount of memory whether you display the data or not. There is a bug we've found in the current dirty build where the memory used to display text is never being freed, but that's separate from any table issues.
So all tables are loaded into ram every scene or just when called by any table function?
Also are we talking about ram or ROM here...
Follow us: Twitter - Website
I haven't had any specific communications with the GS team, no. I've been chatting to @Hopscotch and he has a copy of my project, which I think he may have tested against some new GS. I'm not too sure.
Hi @stevej
Which GS release will the table fixes go into? When will it be available?
Would you be able to give a semi-detailed description of the fixes at some point? Even if it's just a post here on this thread. It'd be good to know what operations were triggering the problem, and what changes and fixes went in.
If possible, it'd also be great to hear a few more tips and explanations of "things to look out for with tables". Like, what will cause them to use up more memory? Any other specifics about how GS handles tables, etc. Any gotchas, or common mis-uses of tables, or behaviours that don't work well with table cells, or whatever.
That'd be really helpful. Keen to check it out, as this might revive my project that I've been unable to work on.
Cheers.
@stevej
But just the info about the fixes that went in will do just fine!
Looks like we plugged the leak in 0.14 that Hopscotch and others have been seeing. This should affect any projects that change the image being applied to an actor (this includes text that changes). Essentially, some of the memory used to create the previous texture wasn't being freed when the new texture was created. The fix should be included in the next nightly build.
0.14 as in this build?
http://forums.gamesalad.com/discussion/comment/523091#Comment_523091
Tables are global. They're loaded into memory (RAM) when your game starts and stay there for the entire time your game is running.
Table fixes should be 0.14.
Just to clarify... do you mean... "any project that changes the image of an actor, at any time, in any way"? Or specific ways of changing the image? Like, changing it to a table cell value? Or using a specific behaviour?
And what do you mean, "This includes text that changes". Changes in what way? Do you mean a "Display Text" behaviour, where the text changes, to say, another attribute value such as a score or timer value, or a table cell value, or...?
As in, nightly 0.14?
Or Mac Creator Release Candidate 0.14?
Or Dodecahedronix Mandlebrot 0.14?
I get confused by all the version numbers.
When you use a Display Text behavior, every time that behavior is run (which is generally once a frame), the engine tests the text to see if it's different from the last time (frame) it checked. If it is, it takes that text and creates a bitmap from it, using the font, color, etc parameters your gave, and applies that texture to the actor.
So let's say you have an attribute that you're incrementing from 1 to 100, and you're using Display Text to show the attribute value. As the game runs, the engine will generate 100 textures, one for each time the attribute changes. Of course, as it generates one it's supposed to delete the previous one, so the amount of memory should approximately be constant (it will actually grow slightly, as the texture space needed to display a "100" is bigger than the space needed to display "1").
Thanks Steve, great to know. So that issue should be fixed in the upcoming build?
And what were the details for the Image issue you mentioned?
If you use the Change Image behavior, you may run into the same issue as with text. This may also apply to the Animate behavior, if you don't have Preload Art checked.
And if I change an image using the "Change Attribute" behaviour, is that different? Does that not experience the same issue?
And will that issue be fixed in that next release you're talking about?
Also, I've never really figured this out...
What does "Preload Art" actually do? What effect does this have?
When are the images loaded, and how are they handled differently, if Preload Art is checked or not? Why would you use Preload Art, and why wouldn't you not use it?
What's the general rule? Check it, or don't check it, for your average image in a game project?
Thanks, that's actually very useful information.
Follow us: Twitter - Website
@stevej thanks for the info above. What time frame are we talking about in regards to when the next 0.14 build will be released that include the critical display text / images fixes you mentioned above?
@MarcMySalad , I had a chance to look at the 0.13.6 build and it looks good. GS is still looking into some issues but its better than it has ever been.
Even displaying a continuously growing string of randomized text has its expected spikes as it builds new bitmaps, but cleans up after itself. (The spikes are zoomed in, i.e. small in relation to memory use)
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Preload art (on by default for every actor) loads the image of the actor into RAM when the app loads. If you have it on for all actors and you have lots of images then it will make the initial loading very slow and might crash your app too if the combined memory usage of all your images combined with the overhead of the GS engine is greater than (roughly) device RAM divided by 2.
You can calculate the RAM usage for every single image in your project by the formula width x height x 4 / 1024 = the amount of device RAM in KB that the image in question will require.
Modern devices load images fast so with that in mind there is no real advantage with using preload art at all in my opinion. On the other hand you probably have to use preload art on for actors with animations right now (as a potential workaround) based on the info from @stevej above (which was very interesting info and something I will have to look into in my projects - that display text/image/preload-for-animations memory leak bug is a real nasty one that in all likelihood explains a thing or two for bigger projects so really looking forward to a fix for that in 0.14)
Thanks!
@stevej does it help to destroy all actors before changing a scene? Any update on your findings in regards to memory leaks?