Constrain Attribute Alternatives
micma
Member Posts: 66
Hey GS Community!
I am creating an endless runner with a custom display for the score. (What I mean by custom display is a score display using images of numbers I have created myself). The code looks like this:
Constrain Attribute: self.Image To: floor(game.score%self.div)/(self.div/10)
The self.div is basically the place of the number*10
So the Ones place's div is 10
10's place is 100
etc..
Every time the score goes to update (every 0.5 seconds), the game has a sudden (but only momentary) lag spike.
I'm pretty sure this is caused by the constraining of the score, but I don't know of any other alternatives to constraining. (Maybe looping, but I am still not very good at using GameSalad's loop feature)
Any Suggestions will be much appreciated 
Thanks,
Micma
Edit: The game is currently only 7.9 MB in the Creator.
Comments
I'd first establish for certain whether this is causing the issue. You can switch off the Constrain behaviour by clicking on the little 'on' button, if the 'lag spike™' still happens you know it's not the constrain behaviour, if it stops then it is likely being caused by the constrain behaviour.
The Change Attribute behaviour should work.
I have now checked and it is for sure the constrain attribute function.
I just tried this and it is still there.
Good suggestion though.
So, we definitely know it's the Constrain behaviour that is causing the issue.
Ok, so you changed the Constrain Attribute behaviour for a Change Attribute behaviour and the problem remains, yet you are sure it is caused by the Constrain Attribute behaviour ?
Ok. Basically it is narrowed down to "I know that it is being caused by the updating of the score." It is the same whether it is constrain or change (every 0.5 seconds)... Would changing the images to .png be any more helpful, or maybe making them a lower res? right now they are 500 ppi (Same as everything else in my game... for the most part).
Hmm...one thing I don't understand. You say you are using constrain, but at the same time, the score updates only every 0.5 seconds? How is that. Constrain doesn't/shouldn't have a interval like that, it is updating with every frame.
Yep, makes sense, sounds like it's a general issue to do with how you have the score working.
Any more helpful than what ?
A resolution value is meaningless by itself, a 8,000ppi file could be tiny while a 7ppi file could be enormous - 500ppi doesn't say anything other than how many pixels are in each inch. A bit like describing a street by saying there is a car every 4 metres (4cpm) and then asking someone to tell you how many cars are in the street using only this information !
1 point is added to the attribute game.score every 0.5 seconds... but my custom font numbers are constrained... hence they are going to change every 0.5 seconds.
What I mean by telling you the ppi is that I'm thinking that maybe because the image is a higher resolution, the file size is larger and is thus causing the game to slow down.
@micma -- but you don't measure resolution of an image on screen by ppi, simply by pixels. What are the pixel dimensions of your images?
@pHghost 31x29
That's tiny. Definitely not higher resolution.
You shouldn't be having problems due to size with those. They will be around 2kb in size each, right?
This is going off topic a little, not related to your main question, but . . .
I'm a great believer in efficiency, keeping things as simple and as stripped down as possible, here self.time (or game.time) is directly related to game.score, game.score is twice the value of self.time - so I'd be tempted to just use self.time/2 instead of having an additional attribute (game.score) and the rules and timers to make it track self.time . . . .
You could dump all that unnecessary intermediate stuff and just have:
floor((self.time/2)%self.div)/(self.div/10)
The actual file sizes are 244x313. They are just scaled way down to fit into the small space of an iPhone. The file sizes are around 25kb each.
So wait, the image resolution is 244x313 pixels, but it is on a 29x31 size actor? Is that correct? That would definitely be asking more memory than if you optimize it.
Always aim to have the image file exactly 2x the size of the actor, if you are publishing for Apple retina devices, for the most optimized performance.
Higher than what ? Like I say resolution, by itself, doesn't say anything useful.
Larger than what ? All these things, 'larger' or 'ppi' or 'is PNG more helpful' . . . keep inviting (for me at least) a 'larger than what', 'higher than what', 'is PNG more helpful than what' . . . and so on.
Maybe I'm not the right person for these kinds of questions, I need cold hard facts !
For example 'I am using XXXX, would YYYY be better?' rather than 'would YYYY be better?', to which I can only say would YYYY be better than what ?
Good luck with the issue, hope you sort it out.
@Socks -- that would only work if it was adding a point every 0.5 seconds of the full runtime, but if you have menus, etc. it wouldn't really be practical, right? Or is there an optimal way to use game.time in those situations?
Ok I will try this out. It makes sense.
@Socks Haha! I get what you are saying. I will definitely let you know if I get more definite facts. Thanks for your help though!
All things being equal . . . .
If the idea of using self.time (or game.time) directly would fail due to menu use (and so on), then the current system would fail due to menu use (and so on) as it directly tracks self.time (or game.time) - they are, as described ('1 point is added to the attribute game.score every 0.5 seconds...'), essentially the same thing, the same value scale (albeit one is always twice as large as the other), going up at the same rate.
Not 100% sure what that means !?
Did it help?
I ended up just having to use one of GS's fonts in a display text function. The game I was talking about is actually being submitted to apple right now. Thanks for the help!