@pHghost said:
But what Socks says about the Display Text behavior is interesting, wouldn't think it would be such a drain. It all probably comes down to the fact that the rendering isn't native. Even though current generation iPhones are way ahead of iPhone 4 in terms of performance and the effects might not be that visible anymore, it doesn't change the fact that the processing drain is still there!
From what I remember the display text behaviour is behaving like a constrain with similar performance hits.
People complaining about fuzzy fonts always confuses me. I've used the built-in fonts extensively in games in the past and tested on iPhone 4, 5, 6, 6+ and iPad and everything looked great in each case. I guess it comes down to how you make use of them.
There are games where using pre-made graphics to show text is doable and makes sense and might be the better option even if proper custom fonts were available, but there are definitely circumstances where that just wouldn't be a viable option.
@pHghost said:
You mention the two as related, but seemingly separate.
He had that covered with the "therefore".
Support for Spriter would be well appreciated, though, as well as Tiled.
Tile support would be amazing, making huge use of it in a current project. That said, linking the two together isn't that difficult if you plan your workflow in advance.
@Armelline said:
He had that covered with the "therefore".
'Therefore' links the two, but doesn't define them as one and the same.
In what way will animation actually be better with sprite sheets vs. the current system? Is there something specific the current system doesn't allow you to do, which a sprite sheet would?
@pHghost said:
In what way will animation actually be better with sprite sheets vs. the current system? Is there something specific the current system doesn't allow you to do, which a sprite sheet would?
Holy crap you're unnecessarily pedantic. And wrong, which makes it worse. What he said was entirely valid.
With bitmap font support comes sprite sheet support and therefore better animation support.
He's saying with bitmap font support comes sprite sheet support. Since we'd be getting sprite sheet support we'd necessarily be getting better animation support, as sprite sheets aid with animation and would make it easier and therefore animation would be better supported.
If you're honestly arguing that animation sheet support wouldn't improve GameSalad's animation capability then I don't know what planet you're living on. Sprite sheets would, for example, save lots of time that currently needs to be spent splitting existing sprite sheets into individual actors, they'd reduce the clutter in the images list, they'd improve memory usage.
Sprite sheets undeniably means better animation support.
Perhaps take some time to education yourself before dismissing someone's statement:
@Socks Nothing changes, if one method is more efficient for a single score - it is also more efficient for multiple scores.
That might be, or most probably is, but you forget how many actors you might need for a game thats quite big. Lets say I want to show the player 16 different scores/values in a statistic menu which should be able to scroll, during the gameplay the main score, coins, and items collected. Then when game over the score, the highscore, coins, and ofcorse they are displayed in a different place then during the gameplay. Every score has a max to 10.000, which is 5 digits per score. Multiply that by 22 and you need to have 110 actors just to display some scores! Then there is the problem when you want to make a design change, you might need to move some score actors around as well. It's not that it's impossible, it's just incredibly time consuming. Simple tasks like these should not be complex in software that wants to be good for beginners.
@The_Gamesalad_Guru Yes I have watched your videos, they're very good, but really basic and for beginners. a few weeks ago there was a discussion about the use of conditions. Apparently it's more efficient to put separate rules into eachother with only one condition per rule, rather then putting 2 or more conditions in one rule to trigger an event. These things are not mentioned anywhere, and it would be very helpful for the more advanced users to know whats going on under the hood to make sure they do everything as efficient as possible. You also mentioned you made some very complex games that always run at 60 fps, you made me curious;)
I have a system for naming image assets to keep everything tidy, but sometimes the image count gets crazy high, quite true.
Your edit doesn't make it seem any more like you actually read what I said. In fact, it compounds that impression that you didn't. And doesn't stop you being any more wrong. In fact, it makes you even more wrong.
Impressive.
You cannot simply pick one example given and go "Aha! So this example is the sum of your argument! All of your premises and your conclusion are to be found within it!" That's not how reading, or understanding, works.
@Armelline said:
Your edit doesn't make it seem any more like you actually read what I said. In fact, it compounds that impression that you didn't. And doesn't stop you being any more wrong. In fact, it makes you even more wrong.
I wasn't responding to your post, but to @tmann, who said:
Easier management and application by an order of some magnitude.
@Armelline said:
Holy crap you're unnecessarily pedantic. And wrong, which makes it worse. What he said was entirely valid.
Pedantic in what way? What you quoted was two of my questions. Is there a problem with asking questions? I am genuinely interested in the benefits sprite sheets would bring.
@pHghost said:
I am genuinely interested in the benefits sprite sheets would bring.
And I told you them. I even (edited in a) link to a video explaining some of the under-the-hood benefits.
The pedantry I referred to was specifically:
You mention the two as related, but seemingly separate. sprite sheet (i.e. better animation) support would be a clearer formulation. Anyway, point taken.
I was just pointing out that you were wrong both in your nitpicking of how he worded his statement, as well as your overall point.
@Armelline said:
And I told you them. I even (edited in a) link to a video explaining some of the under-the-hood benefits.
Yes, I see the link to the video now. Thanks for that.
The rest of the post was unfortunately a rant seemingly trying to ridicule me. I really don't understand lately the amount of personal attacks on the forums.
I started writing my response to @tmann (which ended up underneath your post) before your reply was posted, and so didn't see it until quite a bit later, by which time you were bashing me for not reading your post properly, which hadn't appeared for me yet, so yes, I hadn't read it.
@Armelline said:
If you're honestly arguing that animation sheet support wouldn't improve GameSalad's animation capability then I don't know what planet you're living on. Sprite sheets would, for example, save lots of time that currently needs to be spent splitting existing sprite sheets into individual actors, they'd reduce the clutter in the images list, they'd improve memory usage.
No, I'm not arguing that, I was asking what benefits it would bring, since I haven't worked with spritesheets in the past and the GS animation system (when it wasn't broken) always worked well for me.
That said, I did consider all three things you mentioned before commenting initially.
I'm not sure I would agree with splitting existing sheets having to take up considerable time, all sprite software I use can export sprite sheets as well as image sequences, so that should be very straightforward (though I don't know what software you use, where it might be different).
It wouldn't necessarily help with memory usage since the spritesheets would be integrated into GS's megatextures anyway, with the new rendering system (which I also mentioned).
What is left is image asset management, which is why I felt that was what was the most important, since the other two seemed like non-issues to me.
@pHghost said:
The rest of the post was unfortunately a rant seemingly trying to ridicule me. I really don't understand lately the amount of personal attacks on the forums.
You picked on what someone said, I pointed out you were wrong. You seem more interested, in general, in arguing than in arguing a point. I don't intend it as a personal attack on your, only on what you're saying. I guess calling you overly pedantic could be construed as a personal attack, but you were being overly, and unnecessarily, pedantic.
There's not been a lot of personal attacks on the forums recently, just various members becoming less tolerant of some others. Most of the time I've seen someone cry "Personal attack!" there's been no personal attack. It happens every so often, though. Occasionally an argument results, civilised or not, and then things go back to normal. Hell, I started posting on these forums after years of lurking because I wanted to tell @The_Gamesalad_Guru exactly what I thought of something (or a few things) he'd said. We argued a bit, neither took it too personally, and we get on fine now.
Now you've actually made some points, I'll happily respond to them.
I'm not sure I would agree with splitting existing sheets having to take up considerable time, all sprite software I use can export sprite sheets as well as image sequences, so that should be very straightforward (though I don't know what software you use, where it might be different).
I use Photoshop. But it doesn't detract from the point that people can't be expected to have any specific software, and even opening the file in a 3rd party app and pressing "Export as single images" or whatever will take time.
It wouldn't necessarily help with memory usage since the spritesheets would be integrated into GS's megatextures anyway, with the new rendering system (which I also mentioned).
This is something only the GS guys can tell us. The two ideas are quite different, though. I'd be surprised if sprite sheets couldn't bring additional benefits for memory and performance.
What is left is image asset management, which is why I felt that was what was the most important, since the other two seemed like non-issues to me.
To me this is the least important. But dismissing the others as non-issues is, well, dismissive.
@Approw said:
You also mentioned you made some very complex games that always run at 60 fps, you made me curious;)
I would never release or give a customer a build that didn't run at those frame rates. I'll have to find that thread about the rules. To me it's about intergrated logic. Less is more as they say. I predesign my logic working through tons of iterations until I find the slimmest possible code.
I have a complex game built mostly around 4 main attributes and changes based all on the numbers held in those four attributes.
Here is an example with a user I helped today. He was asking about something he thought was lagging his game. He explained the concept he was using. I did a demo and showed that the concept didn't produce the lag. I sent him the sample, he modified it even further and wrote back that I was right it wasn't the cause. He had spent a month thinking this was the cause and looked for solutions and messing with it. Now this sent him looking and he found it was something else causing the lag. He is working to use another method to acomplish that task.
My point don't assume because something seems like it's the cause of you problems it is. As i develop my stuff I always spit it off to the viewer to chart the FPS. But the key is I alway prototype complex bits of logic and such. I don't use my main project as a place to do lots of experiments. I test out my systems in demo projects and refine them there and then proceed to write the logic in my main project. This way I know when a branch of logic is laggy as I have it isolated.
@Armelline said:
I don't intend it as a personal attack on your, only on what you're saying. I guess calling you overly pedantic could be construed as a personal attack, but you were being overly, and unnecessarily, pedantic.
I'm referring to personal attacks in general, not specifically related to myself. They seemed to have gone through the roof. Lots of threads where people are talking past each other and even openly insulting each other and swearing.
@Approw said:
Multiply that by 22 and you need to have 110 actors just to display some scores! Then there is the problem when you want to make a design change, you might need to move some score actors around as well.
This is not the case. Your point as a whole is valid - custom fonts is my number 1 feature request - but my way of doing custom fonts uses only the minimum number of actors needed to display the current score (spawning and destroying actors as required), and if you want to move it you just move the one actor you need to place on the scene.
Just because something's always been done one way doesn't mean it's the only or easiest or best way to do something.
Apparently it's more efficient to put separate rules into eachother with only one condition per rule, rather then putting 2 or more conditions in one rule to trigger an event.
These two things are not functionally the same, though, regardless of efficiency. So be careful.
@Approw said:
The_Gamesalad_Guru Yes I have watched your videos, they're very good, but really basic and for beginners. a few weeks ago there was a discussion about the use of conditions. Apparently it's more efficient to put separate rules into eachother with only one condition per rule, rather then putting 2 or more conditions in one rule to trigger an event.
The two conditions mentioned in that post did not work together efficiently therefore a logic fault. I use multiple conditions in rules a lot and don't have any problems.
@colander said:
The two conditions mentioned in that post did not work together efficiently therefore a logic fault. I use multiple conditions in rules a lot and don't have any problems.
99% of the time you can put two conditions in the same rule and it'll work fine and be as efficient as is needed. Very occasionally, splitting them will result in a worthwhile boost to performance, and very occasionally splitting them will result in the logic functioning differently.
If you've not had any problems, you've just not encountered one yet. Like when people claimed that GS must honour order of operation because they'd never had it not do so.
Oh I have had problems, what I mean is the rules in my games that have multiple conditions work efficiently because they are logically sound. When they aren't I nest them.
@colander said:
Oh I have had problems, what I mean is the rules in my games that have multiple conditions work efficiently because they are logically sound. When they aren't I nest them.
Ah, well then we're back to the point of "degrees" of efficiency. It was empirically demonstrated that nested can be more efficient than not nesting, but when you're talking a matter of tenths of milliseconds it really makes very little difference as long as the rest of your logic is sound.
@Approw said:
That might be, or most probably is, but you forget how many actors you might need for a game thats quite big. Lets say I want to show the player 16 different scores/values in a statistic menu which should be able to scroll, during the gameplay the main score, coins, and items collected. Then when game over the score, the highscore, coins, and ofcorse they are displayed in a different place then during the gameplay. Every score has a max to 10.000, which is 5 digits per score. Multiply that by 22 and you need to have 110 actors just to display some scores!
What I was saying was don't use 5 digits per score (for 00,000), that along with a change from Constrain Attribute to Change Attribute dramatically lessens the strain on the processor, much less (of course) than using 5 separate actors for each actor and even less (surprisingly) than using multiple Display Text behaviours.
Here is how I see this particular scenario . . . when using images as described in my orginal post:
16 different scores/values in a statistic menu - 32 actors (each showing up to 000 digits)
When game over the score - 2 actors (each showing up to 000 digits)
The highscore - 2 actors (each showing up to 000 digits)
Coins (let's say 1 actor showing up to 000 digits ?)
= 37 actors, all with lightweight (my '000' actors where coming in around 2-3kb ! So very small) images and simple change attribute rules (with conditions)
. . . . . . . . . . . . . . . . . . . .
. . . when using Display Text behaviours:
16 different scores/values in a statistic menu - 16 actors.
When game over the score - 1 actor.
The highscore - 1.
Coins - 1 actor.
= 19 actors, all with surprisingly processor heavy (don't ask me why, as I haven't got a clue!) Display Text behaviours -and with the same simple change attribute rules (with conditions)
. . . . . . . . . . . . . . . . . . . .
After running hours of my own OCD level iterations of tests with the express aim to disprove my initial findings that an image based system like this is less processor intensive, the result were fairly conclusive, I was unable to get the Display Text behaviour version to match the text based version, the image based version put a lot less strain on the processor (I forget the difference, but it was marked, something like being able to run 350 actors with an image based score but only 180 Display Text actors, before the frame rate collapsed) my initial finding, that just 6 Display Text behaviours (with additional constrains for position, size and rotation) dramatically impacted frame rate (and assuming this is a good indicator of processor strain) was borne out on all the follow up tests, as I've said elsewhere this might have been particular my situation, but I think that's unlikely as I stripped the project down to its basics.
@Approw said:
Then there is the problem when you want to make a design change, you might need to move some score actors around as well. It's not that it's impossible, it's just incredibly time consuming.
It's no more complex than moving a Display Text behaviour, well it's two actors instead of one, but no big deal, and even if you were making a score up from 10 actors this should be an issue as all you'd have to do is create a 'score' actor that you drag onto the scene wherever you want and it spawns the 10 'children' actor relative to itself, so if you wanted to use a 10 digit / 10 actor system, you'd simply need to move the parent actor wherever you wanted, but like I say it's far more efficient to pre-render 999 digits and only use 2 actors.
@Approw said:
Simple tasks like these should not be complex in software that wants to be good for beginners.
Ideally, yes, but I think for people new to this they are quite happy throwing stuff up in one of default fonts, if they advance beyond that the various custom font methods aren't overly complex, but I agree that in an ideal world custom fonts would be the better route.
@Socks, the "display text behaviour" is so resource intensive because it needs to allocate new memory and create a new image on the fly, comprising of the text or score to be displayed, every time the text value changes, and render it every frame.
This, opposed to the custom font method, where existing images are "just" rendered each frame.
@Hopscotch said:
Socks, the "display text behaviour" is so resource intensive because it needs to allocate memory, create a new image on the fly and then render it to the frame, comprising of the text or score to be displayed, every time the text value changes.
This, opposed to the custom font method, where existing images are "just" rendered each frame.
Ah! Thanks for the information, that makes sense, and additionally (I'm making a few assumptions here) as text is stored as vector information (so can be scaled to any size without quality loss) it needs to be rasterized as part of its rendering process ? Of course all this is irrelevant when you are just using a handful of text displays, but if you are already pushing the processor hard and squeezing every last drop of magic out of GameSalad then throwing another dozen Text Display behaviours in might push the target device over the edge !
EDIT - with a re-read of your post, I can see you've already factored in the rasterizing stage with "create a new image".
Comments
From what I remember the display text behaviour is behaving like a constrain with similar performance hits.
People complaining about fuzzy fonts always confuses me. I've used the built-in fonts extensively in games in the past and tested on iPhone 4, 5, 6, 6+ and iPad and everything looked great in each case. I guess it comes down to how you make use of them.
There are games where using pre-made graphics to show text is doable and makes sense and might be the better option even if proper custom fonts were available, but there are definitely circumstances where that just wouldn't be a viable option.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
You mention the two as related, but seemingly separate.
sprite sheet (i.e. better animation) support would be a clearer formulation. Anyway, point taken.
Though sprite sheets are more a way to store images (as are the new megatextures in GS) to optimize loading, rather than an animating system.
Support for Spriter would be well appreciated, though, as well as Tiled.
He had that covered with the "therefore".
Tile support would be amazing, making huge use of it in a current project. That said, linking the two together isn't that difficult if you plan your workflow in advance.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
'Therefore' links the two, but doesn't define them as one and the same.
In what way will animation actually be better with sprite sheets vs. the current system? Is there something specific the current system doesn't allow you to do, which a sprite sheet would?
Easier management and application by an order of some magnitude.
Holy crap you're unnecessarily pedantic. And wrong, which makes it worse. What he said was entirely valid.
He's saying with bitmap font support comes sprite sheet support. Since we'd be getting sprite sheet support we'd necessarily be getting better animation support, as sprite sheets aid with animation and would make it easier and therefore animation would be better supported.
If you're honestly arguing that animation sheet support wouldn't improve GameSalad's animation capability then I don't know what planet you're living on. Sprite sheets would, for example, save lots of time that currently needs to be spent splitting existing sprite sheets into individual actors, they'd reduce the clutter in the images list, they'd improve memory usage.
Sprite sheets undeniably means better animation support.
Perhaps take some time to education yourself before dismissing someone's statement:
https://www.codeandweb.com/what-is-a-sprite-sheet
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
So basically what you want is to simplify the management of your image assets. Makes absolute sense.
I have a system for naming image assets to keep everything tidy, but sometimes the image count gets crazy high, quite true.
Please take the time to actually read what I said. It appears you didn't bother.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
That might be, or most probably is, but you forget how many actors you might need for a game thats quite big. Lets say I want to show the player 16 different scores/values in a statistic menu which should be able to scroll, during the gameplay the main score, coins, and items collected. Then when game over the score, the highscore, coins, and ofcorse they are displayed in a different place then during the gameplay. Every score has a max to 10.000, which is 5 digits per score. Multiply that by 22 and you need to have 110 actors just to display some scores! Then there is the problem when you want to make a design change, you might need to move some score actors around as well. It's not that it's impossible, it's just incredibly time consuming. Simple tasks like these should not be complex in software that wants to be good for beginners.
@The_Gamesalad_Guru Yes I have watched your videos, they're very good, but really basic and for beginners. a few weeks ago there was a discussion about the use of conditions. Apparently it's more efficient to put separate rules into eachother with only one condition per rule, rather then putting 2 or more conditions in one rule to trigger an event. These things are not mentioned anywhere, and it would be very helpful for the more advanced users to know whats going on under the hood to make sure they do everything as efficient as possible. You also mentioned you made some very complex games that always run at 60 fps, you made me curious;)
Your edit doesn't make it seem any more like you actually read what I said. In fact, it compounds that impression that you didn't. And doesn't stop you being any more wrong. In fact, it makes you even more wrong.
Impressive.
You cannot simply pick one example given and go "Aha! So this example is the sum of your argument! All of your premises and your conclusion are to be found within it!" That's not how reading, or understanding, works.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I wasn't responding to your post, but to @tmann, who said:
Well he didn't say that either, so the points still stand.
A lot is covered by the emboldened words.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Pedantic in what way? What you quoted was two of my questions. Is there a problem with asking questions? I am genuinely interested in the benefits sprite sheets would bring.
And I told you them. I even (edited in a) link to a video explaining some of the under-the-hood benefits.
The pedantry I referred to was specifically:
I was just pointing out that you were wrong both in your nitpicking of how he worded his statement, as well as your overall point.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
Yes, I see the link to the video now. Thanks for that.
The rest of the post was unfortunately a rant seemingly trying to ridicule me. I really don't understand lately the amount of personal attacks on the forums.
I started writing my response to @tmann (which ended up underneath your post) before your reply was posted, and so didn't see it until quite a bit later, by which time you were bashing me for not reading your post properly, which hadn't appeared for me yet, so yes, I hadn't read it.
No, I'm not arguing that, I was asking what benefits it would bring, since I haven't worked with spritesheets in the past and the GS animation system (when it wasn't broken) always worked well for me.
That said, I did consider all three things you mentioned before commenting initially.
I'm not sure I would agree with splitting existing sheets having to take up considerable time, all sprite software I use can export sprite sheets as well as image sequences, so that should be very straightforward (though I don't know what software you use, where it might be different).
It wouldn't necessarily help with memory usage since the spritesheets would be integrated into GS's megatextures anyway, with the new rendering system (which I also mentioned).
What is left is image asset management, which is why I felt that was what was the most important, since the other two seemed like non-issues to me.
That was a very interesting video, thanks for sharing.
Yes, unfortunately I see it more and more often too.
You picked on what someone said, I pointed out you were wrong. You seem more interested, in general, in arguing than in arguing a point. I don't intend it as a personal attack on your, only on what you're saying. I guess calling you overly pedantic could be construed as a personal attack, but you were being overly, and unnecessarily, pedantic.
There's not been a lot of personal attacks on the forums recently, just various members becoming less tolerant of some others. Most of the time I've seen someone cry "Personal attack!" there's been no personal attack. It happens every so often, though. Occasionally an argument results, civilised or not, and then things go back to normal. Hell, I started posting on these forums after years of lurking because I wanted to tell @The_Gamesalad_Guru exactly what I thought of something (or a few things) he'd said. We argued a bit, neither took it too personally, and we get on fine now.
Now you've actually made some points, I'll happily respond to them.
I use Photoshop. But it doesn't detract from the point that people can't be expected to have any specific software, and even opening the file in a 3rd party app and pressing "Export as single images" or whatever will take time.
This is something only the GS guys can tell us. The two ideas are quite different, though. I'd be surprised if sprite sheets couldn't bring additional benefits for memory and performance.
To me this is the least important. But dismissing the others as non-issues is, well, dismissive.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I would never release or give a customer a build that didn't run at those frame rates. I'll have to find that thread about the rules. To me it's about intergrated logic. Less is more as they say. I predesign my logic working through tons of iterations until I find the slimmest possible code.
I have a complex game built mostly around 4 main attributes and changes based all on the numbers held in those four attributes.
Here is an example with a user I helped today. He was asking about something he thought was lagging his game. He explained the concept he was using. I did a demo and showed that the concept didn't produce the lag. I sent him the sample, he modified it even further and wrote back that I was right it wasn't the cause. He had spent a month thinking this was the cause and looked for solutions and messing with it. Now this sent him looking and he found it was something else causing the lag. He is working to use another method to acomplish that task.
My point don't assume because something seems like it's the cause of you problems it is. As i develop my stuff I always spit it off to the viewer to chart the FPS. But the key is I alway prototype complex bits of logic and such. I don't use my main project as a place to do lots of experiments. I test out my systems in demo projects and refine them there and then proceed to write the logic in my main project. This way I know when a branch of logic is laggy as I have it isolated.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
I'm referring to personal attacks in general, not specifically related to myself. They seemed to have gone through the roof. Lots of threads where people are talking past each other and even openly insulting each other and swearing.
This is not the case. Your point as a whole is valid - custom fonts is my number 1 feature request - but my way of doing custom fonts uses only the minimum number of actors needed to display the current score (spawning and destroying actors as required), and if you want to move it you just move the one actor you need to place on the scene.
Just because something's always been done one way doesn't mean it's the only or easiest or best way to do something.
These two things are not functionally the same, though, regardless of efficiency. So be careful.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
This is why much of this optimization stuff is a waste for the most part. Most people misunderstand the delicacy of doing such things.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
The two conditions mentioned in that post did not work together efficiently therefore a logic fault. I use multiple conditions in rules a lot and don't have any problems.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
99% of the time you can put two conditions in the same rule and it'll work fine and be as efficient as is needed. Very occasionally, splitting them will result in a worthwhile boost to performance, and very occasionally splitting them will result in the logic functioning differently.
If you've not had any problems, you've just not encountered one yet. Like when people claimed that GS must honour order of operation because they'd never had it not do so.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
I remember that thread..lol
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
Oh I have had problems, what I mean is the rules in my games that have multiple conditions work efficiently because they are logically sound. When they aren't I nest them.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
Ah, well then we're back to the point of "degrees" of efficiency. It was empirically demonstrated that nested can be more efficient than not nesting, but when you're talking a matter of tenths of milliseconds it really makes very little difference as long as the rest of your logic is sound.
Contact me for custom work - Expert GS developer with 15 years of GS experience - Skype: armelline.support
What I was saying was don't use 5 digits per score (for 00,000), that along with a change from Constrain Attribute to Change Attribute dramatically lessens the strain on the processor, much less (of course) than using 5 separate actors for each actor and even less (surprisingly) than using multiple Display Text behaviours.
Here is how I see this particular scenario . . . when using images as described in my orginal post:
16 different scores/values in a statistic menu - 32 actors (each showing up to 000 digits)
When game over the score - 2 actors (each showing up to 000 digits)
The highscore - 2 actors (each showing up to 000 digits)
Coins (let's say 1 actor showing up to 000 digits ?)
= 37 actors, all with lightweight (my '000' actors where coming in around 2-3kb ! So very small) images and simple change attribute rules (with conditions)
. . . . . . . . . . . . . . . . . . . .
. . . when using Display Text behaviours:
16 different scores/values in a statistic menu - 16 actors.
When game over the score - 1 actor.
The highscore - 1.
Coins - 1 actor.
= 19 actors, all with surprisingly processor heavy (don't ask me why, as I haven't got a clue!) Display Text behaviours -and with the same simple change attribute rules (with conditions)
. . . . . . . . . . . . . . . . . . . .
After running hours of my own OCD level iterations of tests with the express aim to disprove my initial findings that an image based system like this is less processor intensive, the result were fairly conclusive, I was unable to get the Display Text behaviour version to match the text based version, the image based version put a lot less strain on the processor (I forget the difference, but it was marked, something like being able to run 350 actors with an image based score but only 180 Display Text actors, before the frame rate collapsed) my initial finding, that just 6 Display Text behaviours (with additional constrains for position, size and rotation) dramatically impacted frame rate (and assuming this is a good indicator of processor strain) was borne out on all the follow up tests, as I've said elsewhere this might have been particular my situation, but I think that's unlikely as I stripped the project down to its basics.
It's no more complex than moving a Display Text behaviour, well it's two actors instead of one, but no big deal, and even if you were making a score up from 10 actors this should be an issue as all you'd have to do is create a 'score' actor that you drag onto the scene wherever you want and it spawns the 10 'children' actor relative to itself, so if you wanted to use a 10 digit / 10 actor system, you'd simply need to move the parent actor wherever you wanted, but like I say it's far more efficient to pre-render 999 digits and only use 2 actors.
Ideally, yes, but I think for people new to this they are quite happy throwing stuff up in one of default fonts, if they advance beyond that the various custom font methods aren't overly complex, but I agree that in an ideal world custom fonts would be the better route.
@Socks, the "display text behaviour" is so resource intensive because it needs to allocate new memory and create a new image on the fly, comprising of the text or score to be displayed, every time the text value changes, and render it every frame.
This, opposed to the custom font method, where existing images are "just" rendered each frame.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Ah! Thanks for the information, that makes sense, and additionally (I'm making a few assumptions here) as text is stored as vector information (so can be scaled to any size without quality loss) it needs to be rasterized as part of its rendering process ? Of course all this is irrelevant when you are just using a handful of text displays, but if you are already pushing the processor hard and squeezing every last drop of magic out of GameSalad then throwing another dozen Text Display behaviours in might push the target device over the edge !
EDIT - with a re-read of your post, I can see you've already factored in the rasterizing stage with "create a new image".