@Hymloe for anyone who hasn't written code it is difficult to understand. It sounds like your experience has been with programmers who are working with well written and structured code. This is what Graphine will be so we won't have to suffer this crap every time a change is made or a feature is added.
The more code is sliced into pieces/objects/classes that work to preform specific tasks the easier it is to maintain and add to. Conversely the more linear it is the harder it becomes to work with. Instead of working with a small section of code doing one task it can be a huge block of code doing multiple tasks making working with it a nightmare.
It is difficult to give you something you can relate it to. Think of an actor in one of your games with a bunch of rules and behaviours in it. It executes from top to bottom this is linear execution. Think of all your actors as objects when you have a bug in your game you can generally track it to one actor and work with the rules and behaviours in it until you solve it. Now imagine taking all the rules and behaviours in every actor in your game and sticking them in one actor. It would now be very hard to track down bugs. Now imagine you didn't write it it is someone else's game and they did a really bad job of it and that person made very few notes and the ones he made he wrote for himself not for others. This is not a great analogy but it gives you something to relate it to and a bit of an idea of what they could be facing.
Of course I or anyone else who doesn't work for GS can't know the actual state of the code. I can only surmise it must be pretty bloody awful if it hasn't been fixed after all these years and it takes forever to track down and fix bugs when they occur and they are doing a rewrite.
A lot of people using gamesalad are not going to switch to graphene. If they wanted to program a game engine then they would all ready have switch to other lua/gml engines which are well established and years in front. to be honest I don't know graphene is using lua for its code base as most people in high school use java Or java script. Even vb script would be easier to learn than lua.
If graphene can go into gamesalad mode with no coding then it's a perfect replacement and should be made available as soon as possible. Also let users compile projects locally and get rid of the publishing servers.
Gamesalad for me is a fantastic prototypeing tool. until we see better stability I can only show clients a prototype and then build in a different engine.
At the end of the day pro users are paying customers. Gamesalad should offer refunds to pro customers if they are not happy. I am a company so a license is tax deductible. To individuals 300 USD is a lot of money.
This is not a negative post. It's just my thoughts. if I was GS management Then I would stop graphene development and totally focus the whole team on the current gamesalad product. But as none of us work at gamesalad, we can only guess team politics and working environment. Also from experience, non-technical senior management would put more drive towards the end game rather than the current situation.
I would love to see a video blog of 'day in the life of the gamesad team'. It would give a good in site into the pressures you are under.
@colander your reasoning in a way sounds logical but basically what you are saying is that "the GameSalad software is so complex that issues with the software can't be fixed and we therefore need something else / Graphene". This whole reasoning falls a bit flat on it's stomach when it is very clear to everyone that new huge features are consantly added to the creator and engine [FireTV and Gamepad support being the latest ones]. Since new features can be added then of course existing feautures can be bug fixed too.
@MarcMySalad the only thing that makes sense is they are going to make money out of the promotion they are about to run for fire tv and need it to keep the lights on.
I am only guessing what is going on by what they do I don't know anything for sure. When this stuff keeps popping up and takes ages to fix it has to be the reason. At least it is the only logical conclusion I can come to especially after what dgackey said.
@Binary Computing said:
if I was GS management Then I would stop graphene development and totally focus the whole team on the current gamesalad product.
I think it's good that they are developing a software that is aiming for an even better experience than what GS is. It's probably a good decision to build a completley new engine from scratch, considering the amount of work the GS team has put into this engine and still haven't been able to get it working the way they want it to.
Of course they want us to be satisfied, and of course they can't keep everyone satisfied, but I think they are doing a great job trying.
To those seeing the memory crash: I need a sample game (or games) that have this problem, including instructions on how to reproduce it in the game. Making a simple game that switches back and forth between scenes while reading/writing tables does not show any memory leaks. Attach them to bug 709 or contact me with a link to your game.
I've also sent you a direct message with a link to my project, build up memory usage every level, that never gets cleaned up properly, causing it to crash after 5 or 6 missions (on iPad 2), and not many more on iPad 5 Air, etc.
If you want a simple one, focussed just on the issue, I think @Hopscotch has something.
But you could use mine as a test to see how effective any fixes you make are.
PhilipCCEncounter Bay, South AustraliaMemberPosts: 1,390
edited February 2015
@lycettebros said:
The pressure is building on Graphene.
The pressure is just building... on everyone. I have never seen so much angst and tension in a forum. Everybody is winding everyone else up.
Just reading this thread causes anxiety and creates stress. It is like going into a room where people are arguing and almost at the point of violence. Most unsettling.
I'd rather read some daily assurances from the GS team that things are progressing... and I'd like to see some optimism and enthusiasm from the membership giving them support.
What you think about and what you talk about determines outcomes.
I think it would benefit everyone to stop trawling through the past and preaching gloom & doom!
Having spent a lot of time this week analyzing the potential problem zones in GS, it is clear to me that the GS team know what they are doing and the different aspects of GS, which directly impact memory, are handled sensibly and (specially now with v0.13.3) work as expected under "normal" conditions.
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.
Stevej mentioned fonts. Maybe they have reasons to look into it, but from testing I have not noticed any strange impact on memory.
Images only have, and will continue to give problems, if they are used inefficiently. A mobile device has its limits, memory gets fragmented while swapping large images and at some point it jams up. This would apply to any development tool you may use. As we are using a high level tool, we don't have any control over how and when images get loaded and have to stick to a rule of thumb when calculating the asset footprint of a scene.
Sound is another potential issue. We need to be aware that all sound that might be called in a specific scene, will be loaded as the scene starts. This can cause increased loading times and be heavy on memory if your scene has many different conditional sounds.
As I said, as of v.0.13.3, all of these behave as expected in my opinion - under normal conditions.
How GS behaves when one pushes the memory limits, will be individual to the project. Added to the fact (as often stated by GS) that the GS code base is problematic, will lead the developers clutching at straws, trying to figure out what the problem is.
Surely there will be situations, where a certain combination of behaviors will cause unexpected results. We need to be more analytical about this, maybe find a different approach to achieve the same result, or at least be more specific when we assume it to be a bug. This will help the GS team solve it quickly and get on with implementing our long list of demands.
@Hopscotch said:
Here is to spreading some good news:
Having spent a lot of time this week analyzing the potential problem zones in GS, it is clear to me that the GS team know what they are doing and the different aspects of GS, which directly impact memory, are handled sensibly and (specially now with v0.13.3) work as expected under "normal" conditions.
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.
Stevej mentioned fonts. Maybe they have reasons to look into it, but from testing I have not noticed any strange impact on memory.
Images only have, and will continue to give problems, if they are used inefficiently. A mobile device has its limits, memory gets fragmented while swapping large images and at some point it jams up. This would apply to any development tool you may use. As we are using a high level tool, we don't have any control over how and when images get loaded and have to stick to a rule of thumb when calculating the asset footprint of a scene.
Sound is another potential issue. We need to be aware that all sound that might be called in a specific scene, will be loaded as the scene starts. This can cause increased loading times and be heavy on memory if your scene has many different conditional sounds.
As I said, as of v.0.13.3, all of these behave as expected in my opinion - under normal conditions.
How GS behaves when one pushes the memory limits, will be individual to the project. Added to the fact (as often stated by GS) that the GS code base is problematic, will lead the developers clutching at straws, trying to figure out what the problem is.
Surely there will be situations, where a certain combination of behaviors will cause unexpected results. We need to be more analytical about this, maybe find a different approach to achieve the same result, or at least be more specific when we assume it to be a bug. This will help the GS team solve it quickly and get on with implementing our long list of demands.
Sounds really promising. Thanks for going the extra mile on behalf of the users, @Hopscotch and I'm really looking forward to seeing the next build, and trying it out.
Unfortunately my project did not see any meaningful memory improvements when I tested it with 13.4. When I reviewed the memory usage with Instruments it shows that memory continues to build up, scene by scene, until the game crashes. None of the memory used in the previous scene is released when the new scene is loaded.
@viking said:
Unfortunately my project did not see any meaningful memory improvements when I tested it with 13.4. When I reviewed the memory usage with Instruments it shows that memory continues to build up, scene by scene, until the game crashes. None of the memory used in the previous scene is released when the new scene is loaded.
Maybe provide a link to the project via pm to @stevej who seems to be looking into these issues now?
I just started this investigation out of curiosity. There are obviously many people having problems, yet I was not seeing these memory issues in my own big projects. Being committed to GS for my own creative outlet, I wanted to understand, if and where I would run into similar problems. The findings have again confirmed to me that GS is a very capable development tool.
The priority given to certain features and bugs is not always to my liking, but then I am just one of many special snowflakes here, and we do have a committed GS team, actively expanding the potential of the engine.
Is anyone else having the issue where the loading wheel (custom or not) is not displaying? I have a few scenes that it takes just long enough to load that without that it looks like the game is frozen.
@Jeffm2 said:
Is anyone else having the issue where the loading wheel (custom or not) is not displaying? I have a few scenes that it takes just long enough to load that without that it looks like the game is frozen.
That's a known bug, we're looking into it. As an aside, are you seeing this on Android or iOS?
1) If you copy a big table to a smaller table, your memory will increase.
2) If you add a row or column to a table, your memory will increase.
3) If you set a table cell value to a value who's text representation is bigger than its current text representation, your memory will increase
Hopefully the first two are obvious. The 3rd may not be; currently all table data is stored as text, which means that 123456 takes up more memory than 123. I will be making some changes to the table code to store the data in its native format. This may actually result in an increase in your table memory, if you have a table with lots of small numbers, but it will make things consistent.
@stevej said:
That's a known bug, we're looking into it. As an aside, are you seeing this on Android or iOS?
@stevej I'm experiencing this problem as well, on iOS. Normally I wouldn't mind, but as @Jeffm2 mentioned it makes longer scene changes look like the game is frozen.
@stevej said:
BTW, some things to note for memory & tables:
1) If you copy a big table to a smaller table, your memory will increase.
2) If you add a row or column to a table, your memory will increase.
3) If you set a table cell value to a value who's text representation is bigger than its current text representation, your memory will increase
Hopefully the first two are obvious. The 3rd may not be; currently all table data is stored as text, which means that 123456 takes up more memory than 123. I will be making some changes to the table code to store the data in its native format. This may actually result in an increase in your table memory, if you have a table with lots of small numbers, but it will make things consistent.
Interesting. Is there a set memory usage for calling a string of text from a table (i.e. base+character displayed=x bytes? or maybe *2)
And how does it drop memory from text no longer displayed?
So lets say I am displaying text of a cell value of "hello this is sentence one"
Next I change a variable for row to +1
Now it says "Hello this is sentence two, which is greater then one"
Is it now using 25 more bytes (adding +1 for each character) then the previous, or is it keeping the last string in memory and adding the new one on top in it's entirety?
Also when you access a table for copying or something involving the whole table vs just a cell i'd assume the memory usage is lower for the second?
Its funny how fast it all calms down in here when a few fixes and GS responses appear...just gotta wait for the next release I guess for it to kick off again
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?
Comments
@Hymloe for anyone who hasn't written code it is difficult to understand. It sounds like your experience has been with programmers who are working with well written and structured code. This is what Graphine will be so we won't have to suffer this crap every time a change is made or a feature is added.
The more code is sliced into pieces/objects/classes that work to preform specific tasks the easier it is to maintain and add to. Conversely the more linear it is the harder it becomes to work with. Instead of working with a small section of code doing one task it can be a huge block of code doing multiple tasks making working with it a nightmare.
It is difficult to give you something you can relate it to. Think of an actor in one of your games with a bunch of rules and behaviours in it. It executes from top to bottom this is linear execution. Think of all your actors as objects when you have a bug in your game you can generally track it to one actor and work with the rules and behaviours in it until you solve it. Now imagine taking all the rules and behaviours in every actor in your game and sticking them in one actor. It would now be very hard to track down bugs. Now imagine you didn't write it it is someone else's game and they did a really bad job of it and that person made very few notes and the ones he made he wrote for himself not for others. This is not a great analogy but it gives you something to relate it to and a bit of an idea of what they could be facing.
Of course I or anyone else who doesn't work for GS can't know the actual state of the code. I can only surmise it must be pretty bloody awful if it hasn't been fixed after all these years and it takes forever to track down and fix bugs when they occur and they are doing a rewrite.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
A lot of people using gamesalad are not going to switch to graphene. If they wanted to program a game engine then they would all ready have switch to other lua/gml engines which are well established and years in front. to be honest I don't know graphene is using lua for its code base as most people in high school use java Or java script. Even vb script would be easier to learn than lua.
If graphene can go into gamesalad mode with no coding then it's a perfect replacement and should be made available as soon as possible. Also let users compile projects locally and get rid of the publishing servers.
Gamesalad for me is a fantastic prototypeing tool. until we see better stability I can only show clients a prototype and then build in a different engine.
At the end of the day pro users are paying customers. Gamesalad should offer refunds to pro customers if they are not happy. I am a company so a license is tax deductible. To individuals 300 USD is a lot of money.
This is not a negative post. It's just my thoughts. if I was GS management Then I would stop graphene development and totally focus the whole team on the current gamesalad product. But as none of us work at gamesalad, we can only guess team politics and working environment. Also from experience, non-technical senior management would put more drive towards the end game rather than the current situation.
I would love to see a video blog of 'day in the life of the gamesad team'. It would give a good in site into the pressures you are under.
@colander your reasoning in a way sounds logical but basically what you are saying is that "the GameSalad software is so complex that issues with the software can't be fixed and we therefore need something else / Graphene". This whole reasoning falls a bit flat on it's stomach when it is very clear to everyone that new huge features are consantly added to the creator and engine [FireTV and Gamepad support being the latest ones]. Since new features can be added then of course existing feautures can be bug fixed too.
@MarcMySalad the only thing that makes sense is they are going to make money out of the promotion they are about to run for fire tv and need it to keep the lights on.
I am only guessing what is going on by what they do I don't know anything for sure. When this stuff keeps popping up and takes ages to fix it has to be the reason. At least it is the only logical conclusion I can come to especially after what dgackey said.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
I think it's good that they are developing a software that is aiming for an even better experience than what GS is. It's probably a good decision to build a completley new engine from scratch, considering the amount of work the GS team has put into this engine and still haven't been able to get it working the way they want it to.
Of course they want us to be satisfied, and of course they can't keep everyone satisfied, but I think they are doing a great job trying.
To those seeing the memory crash: I need a sample game (or games) that have this problem, including instructions on how to reproduce it in the game. Making a simple game that switches back and forth between scenes while reading/writing tables does not show any memory leaks. Attach them to bug 709 or contact me with a link to your game.
@stevej, which version of GS are you focusing on?
I will take time to prepare another project specific to that version today, which isolates and illustrates the conditions.
I would like to know the version because 0.12 and 0.13 behave quite differently in this regard.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
We are focusing on 0.13 firetv build
Ok thanks, @BlackCloakGS
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
\o/
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.
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
You mention bug #709.
There is further memory related stuff here in Bug #729...
http://bugs.gamesalad.com/show_bug.cgi?id=729
I've also sent you a direct message with a link to my project, build up memory usage every level, that never gets cleaned up properly, causing it to crash after 5 or 6 missions (on iPad 2), and not many more on iPad 5 Air, etc.
@Hymloe is it a simple project or a full game project?
Mine is a full game project.
If you want a simple one, focussed just on the issue, I think @Hopscotch has something.
But you could use mine as a test to see how effective any fixes you make are.
The pressure is just building... on everyone. I have never seen so much angst and tension in a forum. Everybody is winding everyone else up.
Just reading this thread causes anxiety and creates stress. It is like going into a room where people are arguing and almost at the point of violence. Most unsettling.
I'd rather read some daily assurances from the GS team that things are progressing... and I'd like to see some optimism and enthusiasm from the membership giving them support.
What you think about and what you talk about determines outcomes.
I think it would benefit everyone to stop trawling through the past and preaching gloom & doom!
Here is to spreading some good news:
Having spent a lot of time this week analyzing the potential problem zones in GS, it is clear to me that the GS team know what they are doing and the different aspects of GS, which directly impact memory, are handled sensibly and (specially now with v0.13.3) work as expected under "normal" conditions.
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.
Stevej mentioned fonts. Maybe they have reasons to look into it, but from testing I have not noticed any strange impact on memory.
Images only have, and will continue to give problems, if they are used inefficiently. A mobile device has its limits, memory gets fragmented while swapping large images and at some point it jams up. This would apply to any development tool you may use. As we are using a high level tool, we don't have any control over how and when images get loaded and have to stick to a rule of thumb when calculating the asset footprint of a scene.
Sound is another potential issue. We need to be aware that all sound that might be called in a specific scene, will be loaded as the scene starts. This can cause increased loading times and be heavy on memory if your scene has many different conditional sounds.
As I said, as of v.0.13.3, all of these behave as expected in my opinion - under normal conditions.
How GS behaves when one pushes the memory limits, will be individual to the project. Added to the fact (as often stated by GS) that the GS code base is problematic, will lead the developers clutching at straws, trying to figure out what the problem is.
Surely there will be situations, where a certain combination of behaviors will cause unexpected results. We need to be more analytical about this, maybe find a different approach to achieve the same result, or at least be more specific when we assume it to be a bug. This will help the GS team solve it quickly and get on with implementing our long list of demands.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Sounds really promising. Thanks for going the extra mile on behalf of the users, @Hopscotch and I'm really looking forward to seeing the next build, and trying it out.
@hopscotch many thanks. Good to get things resolved quickly. Your help is really appreciated.
Unfortunately my project did not see any meaningful memory improvements when I tested it with 13.4. When I reviewed the memory usage with Instruments it shows that memory continues to build up, scene by scene, until the game crashes. None of the memory used in the previous scene is released when the new scene is loaded.
Maybe provide a link to the project via pm to @stevej who seems to be looking into these issues now?
@Binary Computing , @Hymloe , all credit to the GS Team.
I just started this investigation out of curiosity. There are obviously many people having problems, yet I was not seeing these memory issues in my own big projects. Being committed to GS for my own creative outlet, I wanted to understand, if and where I would run into similar problems. The findings have again confirmed to me that GS is a very capable development tool.
The priority given to certain features and bugs is not always to my liking, but then I am just one of many special snowflakes here, and we do have a committed GS team, actively expanding the potential of the engine.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Is anyone else having the issue where the loading wheel (custom or not) is not displaying? I have a few scenes that it takes just long enough to load that without that it looks like the game is frozen.
That's a known bug, we're looking into it. As an aside, are you seeing this on Android or iOS?
BTW, some things to note for memory & tables:
1) If you copy a big table to a smaller table, your memory will increase.
2) If you add a row or column to a table, your memory will increase.
3) If you set a table cell value to a value who's text representation is bigger than its current text representation, your memory will increase
Hopefully the first two are obvious. The 3rd may not be; currently all table data is stored as text, which means that 123456 takes up more memory than 123. I will be making some changes to the table code to store the data in its native format. This may actually result in an increase in your table memory, if you have a table with lots of small numbers, but it will make things consistent.
@stevej I'm experiencing this problem as well, on iOS. Normally I wouldn't mind, but as @Jeffm2 mentioned it makes longer scene changes look like the game is frozen.
POLAR ROLLOUT (New Line-Drawing Physics Puzzler!) - FREE Download
@stevej Its on IOS. Ok at least I know Im not taking crazy pills
Interesting. Is there a set memory usage for calling a string of text from a table (i.e. base+character displayed=x bytes? or maybe *2)
And how does it drop memory from text no longer displayed?
So lets say I am displaying text of a cell value of "hello this is sentence one"
Next I change a variable for row to +1
Now it says "Hello this is sentence two, which is greater then one"
Is it now using 25 more bytes (adding +1 for each character) then the previous, or is it keeping the last string in memory and adding the new one on top in it's entirety?
Also when you access a table for copying or something involving the whole table vs just a cell i'd assume the memory usage is lower for the second?
Guess I need to make some test projects...
Follow us: Twitter - Website
Its funny how fast it all calms down in here when a few fixes and GS responses appear...just gotta wait for the next release I guess for it to kick off again
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?