Timers and spawning for sure and Animate behavior needs work too it really sucks too have the behaviors and yet I'm having to use work arounds to get the desired effect, as for loading times not a big deal with me.
@BBEnk Can you give more details about the issues you're having with the Animate behavior?
Hope you don't mind me chiming in here . . .
There are several very basic problems with the animate behaviour (besides it's lack of basic functionality), for instance importing image sequences and placing them in the animate panel results in the sequence losing its order (there is a workaround for this), another one would be the arbitrary frame rates, see my write up here ('clouds/Tynan' is an old forum user name of mine):
@CodeWizard you know in my unexperienced coding mind seems like a quick way to say 'Hiya! I'm here', is to have the option of putting the particle behavior behind the actor....right now it's infront. if there was a way we could check a box that says infront or behind actor...man that would be brilliant lol.
Well said, show us what your wand can do LOL
My preference is with spawning performance and RAM usage, honestly I don't know what is the problem with timers? they work as expected and they don't hurt performance as they used to do a year ago.
Roy.
tenrdrmerMember, Sous Chef, Senior Sous-ChefPosts: 9,934
Oh...and Custom Fonts..if we could only import the fonts we want instead of having to use images for everything...I would personally fly to Texas and give you a Caribbean Styled bear hug, free of charge.
Haha man this needs to be priority number one just to make him buy the plane ticket. Lol.
On a side note I would love to have that feature as well.
Load times would be my number 1 optimizing issue though.
I don't mind you chiming in at all. I just had a look at the animate behavior code. One problem jumps right out at me:
The animate behavior does a little work every frame of your game. First off, it keeps track of the last time it advanced animation frames. It does so by tracking a variable called "_timeOfLastFrame." Each simulation frame of the game uses that variable to compute elapsed time. Once that elapsed time exceeds the time per frame of your animation, the frame number is advanced.
Here's what it looks like in Lua:
local elapsedTime = self._animationTime.time - self._timeOfLastFrame
if elapsedTime >= self:timePerFrame() then
self._timeOfLastFrame = self._animationTime.time
self:nextFrame()
end
Looks good on the surface. However, there are two potential issues here:
1. Losing time. Because the _timeOfLastFrame is set to "now" any extra time is lost. This can cause frame jitter.
2. If the overall framerate is inconsistent (especially slower than your animation's target rate) then frames will be lost.
Here's how I generally implement these things:
while ElapsedTime >= TimePerFrame do
self:nextFrame()
ElapsedTime = ElapsedTime - TimePerFrame
end
This makes sure that the frame is updated properly based on any simulation case. It also accounts for lost time between frames. I'll make a note of this and see about getting that fixed.
(EDIT: Thanks for the help on marking up code on the forums, @tenrdrmer)
I'm wondering if some of the loading time gripes are because there is not a "transitions" behavior, or function for change scene. Some people don't bother manually setting them up which means you're staring at a screen with only a unchangeable wheel graphic and a frozen version of whatever was occuring, and that makes it seem like it's taking FOREVER.
I'll make a note of this and see about getting that fixed.
Well ! I can't hope to begin to understand half the stuff you know about, but I'm just glad you know this stuff !! )
The thing that confused me about the issue was that rather than there being a universal offset - let's imagine all the frame rates ran at 5 fps slower than their stated rates - [so 10fps ran at 5fps // 30fps ran at 25fps, etc] or perhaps a 'ratio-offset' (is that even a phrase!) so that everything, for instance, ran at half the stated speed [so 10fps ran at 5fps // 30fps ran at 15fps, etc], I could get my head around that but it was the distinct pattern and grouping of frame rates that had me confused, for instance frame rates from 21fps to 29fps all running at 20.1fps, and 20fps running 3.6fps slower than 21fps ?
This suggested to me that it wasn't simply the result of a universal process such as lost time, anyhow like I say I haven't got a clue about how any of the programming side works, it's all witchcraft and magic to me.
@Socks The thing about lost time is that it's not always consistent. Because the frame rate of your app fluctuates based on how much work is done per frame. So, lost time manifests in odd ways. No doubt.
gyroscopeI am here.Member, Sous Chef, PROPosts: 6,598
edited March 2013
For interest, @CodeWizard, could this (and all other Timer aspects) be based on the device clock rather than time based on game frame rate? Then surely no time would be "lost"...
(Sorry if this question is pulling the thread off-track...) :ar!
@BBEnk Can you give more details about the issues you're having with the Animate behavior?
I'm not sure about what all you said above meant, but thats probably the problem I'm having,lol.
But, I have a animated figure with 19 frames that I need him to walk smoothly but look quickly so he doesn't look like he's sliding on the ground. I actually made a test that runs my players 19 frames in the animate behavior at 30 fps but thats look to slow so not good. I found a simple solution just using a timer set at ever 0 seconds and two change attributes to animate the 19 frames its actually fast enough to get the effect I want but with no adjustment faster but works. The fastest way I found was using the interpolate to animate the player its veyr fast can get the speed I want at 0.05 seconds so I have a little adjustment there up and down but requires more code to make work but works. I even used some of the fastloop test other user have posted on here and they work good too but most of the time adjustments from 0.01 to 0.02 was harsh.
One note when using these other methods you don't have to worrier about how the images are imported has @socks mentioned.
@Socks The thing about lost time is that it's not always consistent. Because the frame rate of your app fluctuates based on how much work is done per frame. So, lost time manifests in odd ways. No doubt.
That's what confused me, it was consistent and repeatable, for example the frame-rate groups (e.g: 21-29fps) repeatedly and consistently stuck together, on runs of a few seconds, a few hours, on a desktop computer, in preview on an iPad, an iPhone and an iPod, on different days even ! 21-29fps was (and still is) always 20.1 fps ! 8-X
Anyhow I don't pretend to understand the underlying spookiness of coding I'm just glad you are getting stuck into all this kind of stuff.
. . . obviously each progressively faster frame rate should follow the red line, it does a reasonably good job up until frame 13 where things get weird.
Anyhow I don't want to make this thread all about the screwy animation frame rates so I'll leave it there, but again, cheers for looking into this stuff.
Place them in the animate behaviour where the frames become:
1, 2, 3, 4, 5, 6 . . . etc
It doesn't matter what order they are placed in the animate behaviour, they could be out of order and they will still register as 1, 2, 3, 4, 5, 6 . . . etc. Swap 2 and 6 around and they will simply rename themselves so it still reads 1, 2, 3, 4, 5, 6 . . . etc, this isn't really much use to anyone, it also makes the issue of imported image sequences losing their order that much harder to sort out (without the above workaround).
If the animate behaviour simply displayed the file names (Jump A104, Jump A105, Jump A106 . . . ) it would be much more useful.
tenrdrmerMember, Sous Chef, Senior Sous-ChefPosts: 9,934
edited March 2013
@CodeWizard to post code you don't want the forum to read as code
place it all between a couple of these </ code>
Just don't place a space after that last forward slash
Might not help with your formatting though. idk its worth a shot I guess
So far my only issue is loading times and loading times between scenes. That would make my life so much easier and one major thing I won't have to worry about.
Also welcome good to see your initial attuitude towards GS.
tenrdrmerMember, Sous Chef, Senior Sous-ChefPosts: 9,934
BTW earlier today in this thread is the first time I have ever seen someone at GameSalad get technical about the super secret code behind the GameSalad Creator and Engine. At least without a weeks worth of checking back and forth between several GS admins to make sure they are not releasing to much public information.
That is an amazing breath of fresh air. Thank you sir. You are scholarly and a Gentleman. ^:)^
Comments
✮ FREE TEMPLATES, ANIMATIONS ✮ ✮ GAME PRO MARKET BUY & SELL ✮
Can you give more details about the issues you're having with the Animate behavior?
There are several very basic problems with the animate behaviour (besides it's lack of basic functionality), for instance importing image sequences and placing them in the animate panel results in the sequence losing its order (there is a workaround for this), another one would be the arbitrary frame rates, see my write up here ('clouds/Tynan' is an old forum user name of mine):
http://forums.gamesalad.com/discussion/40335/gss-animate-is-screwed/p1
My preference is with spawning performance and RAM usage, honestly I don't know what is the problem with timers? they work as expected and they don't hurt performance as they used to do a year ago.
Roy.
On a side note I would love to have that feature as well.
Load times would be my number 1 optimizing issue though.
Chakku
I don't mind you chiming in at all. I just had a look at the animate behavior code. One problem jumps right out at me:
The animate behavior does a little work every frame of your game. First off, it keeps track of the last time it advanced animation frames. It does so by tracking a variable called "_timeOfLastFrame." Each simulation frame of the game uses that variable to compute elapsed time. Once that elapsed time exceeds the time per frame of your animation, the frame number is advanced.
Here's what it looks like in Lua:
local elapsedTime = self._animationTime.time - self._timeOfLastFrame if elapsedTime >= self:timePerFrame() then self._timeOfLastFrame = self._animationTime.time self:nextFrame() endLooks good on the surface. However, there are two potential issues here:
1. Losing time. Because the _timeOfLastFrame is set to "now" any extra time is lost. This can cause frame jitter.
2. If the overall framerate is inconsistent (especially slower than your animation's target rate) then frames will be lost.
Here's how I generally implement these things:
while ElapsedTime >= TimePerFrame do self:nextFrame() ElapsedTime = ElapsedTime - TimePerFrame endThis makes sure that the frame is updated properly based on any simulation case. It also accounts for lost time between frames. I'll make a note of this and see about getting that fixed.
(EDIT: Thanks for the help on marking up code on the forums, @tenrdrmer)
Making games for 22 years has that effect on you.
Really looking forward to what you deliver Sir!
The thing that confused me about the issue was that rather than there being a universal offset - let's imagine all the frame rates ran at 5 fps slower than their stated rates - [so 10fps ran at 5fps // 30fps ran at 25fps, etc] or perhaps a 'ratio-offset' (is that even a phrase!) so that everything, for instance, ran at half the stated speed [so 10fps ran at 5fps // 30fps ran at 15fps, etc], I could get my head around that but it was the distinct pattern and grouping of frame rates that had me confused, for instance frame rates from 21fps to 29fps all running at 20.1fps, and 20fps running 3.6fps slower than 21fps ?
This suggested to me that it wasn't simply the result of a universal process such as lost time, anyhow like I say I haven't got a clue about how any of the programming side works, it's all witchcraft and magic to me.
(too much ?
The thing about lost time is that it's not always consistent. Because the frame rate of your app fluctuates based on how much work is done per frame. So, lost time manifests in odd ways. No doubt.
For interest, @CodeWizard, could this (and all other Timer aspects) be based on the device clock rather than time based on game frame rate? Then surely no time would be "lost"...
(Sorry if this question is pulling the thread off-track...) :ar!
""You are in a maze of twisty passages, all alike." - Zork temp domain http://spidergriffin.wix.com/alphaghostapps
But, I have a animated figure with 19 frames that I need him to walk smoothly but look quickly so he doesn't look like he's sliding on the ground.
I actually made a test that runs my players 19 frames in the animate behavior at 30 fps but thats look to slow so not good.
I found a simple solution just using a timer set at ever 0 seconds and two change attributes to animate the 19 frames its actually fast enough to get the effect I want but with no adjustment faster but works.
The fastest way I found was using the interpolate to animate the player its veyr fast can get the speed I want at 0.05 seconds so I have a little adjustment there up and down but requires more code to make work but works.
I even used some of the fastloop test other user have posted on here and they work good too but most of the time adjustments from 0.01 to 0.02 was harsh.
One note when using these other methods you don't have to worrier about how the images are imported has @socks mentioned.
That's what confused me, it was consistent and repeatable, for example the frame-rate groups (e.g: 21-29fps) repeatedly and consistently stuck together, on runs of a few seconds, a few hours, on a desktop computer, in preview on an iPad, an iPhone and an iPod, on different days even !
Anyhow I don't pretend to understand the underlying spookiness of coding I'm just glad you are getting stuck into all this kind of stuff.
That sounds like the engine is doing some odd throttling of the frame rate at a higher level. I'll check that out too.
(hope it makes sense !)
http://oi39.tinypic.com/s3d2s6.jpg
. . . obviously each progressively faster frame rate should follow the red line, it does a reasonably good job up until frame 13 where things get weird.
Anyhow I don't want to make this thread all about the screwy animation frame rates so I'll leave it there, but again, cheers for looking into this stuff.
There is a workaround for imported image sequences losing their order when used with the animation behaviour:
Second to last post in this thread:
http://forums.gamesalad.com/discussion/54434/which-is-easier-replace-animations-or-copy-rules
. . . . . . .
Also with the animation panel it would be really useful to have the individual frames honour the file names.
At the moment you might import an image sequence like this:
Jump A104, Jump A105, Jump A106, Jump A107, Jump A108, Jump A109 . . . etc
Place them in the animate behaviour where the frames become:
1, 2, 3, 4, 5, 6 . . . etc
It doesn't matter what order they are placed in the animate behaviour, they could be out of order and they will still register as 1, 2, 3, 4, 5, 6 . . . etc. Swap 2 and 6 around and they will simply rename themselves so it still reads 1, 2, 3, 4, 5, 6 . . . etc, this isn't really much use to anyone, it also makes the issue of imported image sequences losing their order that much harder to sort out (without the above workaround).
If the animate behaviour simply displayed the file names (Jump A104, Jump A105, Jump A106 . . . ) it would be much more useful.
place it all between a couple of these </ code>Just don't place a space after that last forward slash Might not help with your formatting though. idk its worth a shot I guessAlso welcome good to see your initial attuitude towards GS.
Guru Video Channel | Lost Oasis Games | FRYING BACON STUDIOS
- Thomas
That is an amazing breath of fresh air. Thank you sir. You are scholarly and a Gentleman. ^:)^
Well, timers are based off of the system clock. It's just how the code deals with elapsed time that can cause problems.
I'm not giving away any secrets here.