Making an actor fade in and out
So I've actually done this using timers but it's really messy and code heavy.
The second try I've done looks like this:
'Timer - every 10 seconds
Rule - If self.alpha = 0
Timer - every .1 seconds
change self.alpha to self.alpha + .01
otherwise
change self.alpha to self.alpha - .01
But it doesn't work, and I can't figure out why not. Halp!
The second try I've done looks like this:
'Timer - every 10 seconds
Rule - If self.alpha = 0
Timer - every .1 seconds
change self.alpha to self.alpha + .01
otherwise
change self.alpha to self.alpha - .01
But it doesn't work, and I can't figure out why not. Halp!
Comments
Timer every 1 seconds
change attribute self.fade to self.fade*-1
Rule - When self.fade = 1
timer every 0.1 seconds
Change self.alpha to self.alpha-0.1
Rule - when self.fade= -1
timer every 0.1 seconds
Change self.alpha to self.alpha+0.1
nevermind been working on this all day... I feel really stupid I asked a question like that haha
self.alpha=0
rule 1:
when game.fadeIn=true (or use any switch activation mechanism you desire)
...timer:
.....every .15 seconds (or whatever value you desire)
.....self.alpha=self.alpha+.1 (or whatever value you desire)
rule 2: (separate rule outside of rule 1)
when self.alpha >= .95 (use a slightly lower value)
...game.fadeIn=false
...self.alpha=1 (failsafe override)
reverse the values to fade out...but when I fade out...I usually add a "destroy actor" behavior at the end if I don't need it anymore.
This method should be more efficient as it only uses 1 timer and the timer only runs when activated.
TIP: keep the timer second step value as high as possible to reduce processor demands. The settings above seem to be optimal for FPS speed vs. quality of fade.
play with the little run to completion box
Create real attribute self.faderate
'Timer - every .5 seconds
change self.alpha to self.alpha + self.faderate
Rule - If self.alpha = 0
change attribute self.faderate to .1
Rule - If self.alpha = 0
change attribute self.faderate to -.1'
Ideally I would like to create a solution that uses only standard attributes so I can easily c/p to other actors.
Why am I on public wifi? I'll have you know I'm on my roommate's ethernet lol. I just like to be efficient in my posts
I recommend you use them in my logic sequence above as it is the most overhead efficient fade switch that I have been able to build myself and I have found a better one elsewhere yet.
Its super simple and super efficient and only activates the timer when needed.
Thanks!
homeless.......
But I still don't get it!
Timer every 10 seconds
.Rule if self.alpha <= 0
..Timer for 10 seconds
...Timer every .1 seconds
.... Change self.alpha to self.alpha+.1
.Rule if self.alpha >= .95
..Timer for 10 seconds
...Timer every .1 seconds
.... Change self.alpha to self.alpha-.1
This is convenient because it uses self.alpha as the switching variable. This means I can c/p this to any actor and it will work without having to dick around with repairing attribute links. Now my question is which of the solutions posted here are most optimal? I'd like to hear from synthesis especially since he seems fairly knowledgeable on optimization.
You have 5 timers when you only need 1...especially since you have everything inside a timer.
Use the rules to switch 1 timer on and off. The rules will only fire when they are switched to. It is a more sophisticated way to do it...and maybe requires a little more thought...but it is more optimized.
Example:
Why do you have a .1 timer inside a 10 timer. This means that there will be 100 calculations to execute the fade...WAY TO Many and the gamer won't notice that level of subtlety.
If you want a 10 second fade...then use a .5 second timer in side a rule that when alpha = 1 (or 0)...shut the timer off. Then put that rule inside an "activation" rule.
There you have 1 timer with 2 rules...and it does the same thing your 3 timers and 1 rule does. My solution is MORE OPTIMIZED!
If you want it to add up or subtract down, put a = otherwise rule in there. Then you will have 2 timers in the sequence...but only one will fire depending on the alpha direction switch.
TIP: NEVER let a timer run when it is not necessary to do so.
I think my original solution (at least the logic of it) still is the best way to go. USE RULES...NOT TIMERS!
Also...if you want it to oscillate...which is what I believe you are trying to do with the Every 10 sec. timer, Run your oscillation timer in a separate routine. So every 10 seconds...rule...if alpha = 1...self.FadeOut=true...otherwise self.FadeOut=false (fadeIn)....executeFade=true. Then use that first boolean to tells the fade routine to fade in or fade out and second routine executes the fade.
This sequence assumes you begin at alpha = 0.
necessary self attributes:
fadeIN = true
fadeStep = 0.1
fadeUp = true
executeFade = false
resetFadeLoop = false
rule1: When executeFade=true (can be triggered by changing the default or by a game switch)
sub-rule 1A: when fadeUp = true
...timer: every .25 seconds:
........self.alpha = self.alpha + fadeStep
...sub-rule 1AA: when self.alpha >= 0.95
......self.alpha = 1 (force override)
......resetFadeLoop = true (activate reset routine)
......executeFade = false (turns this routine off)
otherwise (fadeUp = false)
...timer: every .25 seconds: (the .25 seconds with a .1 alpha step makes for a 2.5 second fade effect)
........self.alpha = self.alpha - fadeStep
...sub-rule 1AB: when self.alpha <= 0.05
......self.alpha = 0
......resetFadeLoop = true
......executeFade = false
rule2: When resetFadeLoop = true
...sub-rule 2A: when self.alpha = 1
.......fadeUp = false otherwise fadeUp = true
timer: after 5 seconds (a reset delay if desired...or remove the timer element for continuous oscillation)
executeFade=true (reactivates the fade routine)
resetFadeLoop=false (turns this routine off)
you might place this entire parallel routine inside a game activation switch to only make it run when the game desires it to (for example if your player's X and/or Y in in a different part of the map and can't even see it)
This sort of routine will work for anything that oscillates in your game...such as gears turning, things scaling up and down...or whatever.
I haven't actually tested the sequence above so it might need tweaking...but the conceptual logic is there. use that routine and you will be WELL OPTIMIZED.
NOW....if any of you out there read this and it helps you out...thank me by going and test driving my new Bumper Derby X-Treme game and give me some constructive feedback
a really convenient link to BDX: http://gamesalad.com/forums/topic.php?id=4376
I see what you are doing in your second post, here's my revised solution based on your advise. I basically created a mechanical switch instead of using a timer.
create game.fade = .1
actor
.rule when any condition
.self.alpha <= 0
.self.alpha >= 1
..change game.fade to game.fade*-1
timer every .5
change self.alpha to self.alpha+game.fade
So only one game attribute, one timer and one rule
I apologize, I haven't much coding background. I taught myself BASIC in high school and that's about it until I started using GS a month ago. So while I understand code logic, I'm still learning a lot about what optimization really means.
The point of my rambling was to suggest to use rules instead of timers (or other processor heavy behaviors). Use your switch values to control the actor more. Keep the actor only working on one task at a time. The less you make the actor "think" or "multi-task" the better your game will work and the better your optimization will become.
Good Luck!
game.fade = .2
actor
.rule when any condition
.self.alpha <= 0
.self.alpha >= 1
..change game.fade to game.fade*-1
..timer after 5 sec
...timer every .1
...change self.alpha to self.alpha+game.fade
This solution only runs the fade timer for .5 seconds, and only runs 5 calculations to execute the fade. I checked to see if the fade timer keeps running by creating a spawn dummy actor behavior every time the self.alpha+game.fade was executed. Once the actor disappeared it stopped spawning dummy actors, so I assume that means the "Every .1" timer had stopped. Is this a correct way to test this?
Instead...run a separate 5 second timer inside an activation switch that then activates a switch to run the .1 timer. Sure its more rules...but for GS...this is more efficient. Only 1 timer running at a time. your solutions above has 1 timer executing another timer....1timer+1timer=2timers which means extra processing. Having rule switches will force only 1 timer to run at a time allowing you to run an extra timer somewhere else in your game.
Forget about how many executions it takes...that is irrelevant...so long as they are sequenced well. However...using multi-timers instead of extra rules is wasteful on processing demands.
SOLUTION:
Pull your second timer out into a separate rule. Then replace it with a timer switch for the new rule. Then in the 2nd rule...run your loop.
Then in a 3rd separate rule...
do this:
when alpha=myTargetAmount and when myNewRule1switchToRule3=true
shut my .1 timer off (rule 2)
restart my 5 second timer (rule 1).
myNewRule1switchToRule3=false. (this could be the first thing Rule 1 does too).
This third timer will need a trigger switch also (as described above) to force it to only run after rule 1 is done and rule 2 is done.
This subtle difference forces only one timer at a time to run. Logic like this will make your game work 100% of the time with no misfires (so far it does for me). Before...I tried to be efficient like you are doing...but the game was buggy as hell and was killing the processor. Going with a more sequential approach has proven to be MUCH more reliable and my game doesn't crash (as often
My first tip is read my other posts. I have lots of stuff already out there that I have written in the last couple of weeks.
The biggest tip I can give you is make sure the game is sequential and that no single actor is doing more than one thing at a time. This will give your firing mechanisms much more reliability.
Second best tip...Go through every single actor rule by rule and look for ANYTHING that you can pull out or do more simply. If you can replace a rule with a simple expression...do it.
For example...I had rule for the joystick location...left or right side of the screen.
Before I said if game.joystickLocation = 0 then self.position.X=70
otherwise...self.position.X = 400
I change this to a change attribute...which does the same thing and eliminates a rule.
example:
self.position.X = 70+(game.joystickLocation*330)
see...if the location is on the left...it places a 0 in the expression and results as 70...otherwise the answer is 400. Pretty slick huh?
I found lots of places I could do stuff like this. You will too. Just gotta spend about a week combing through stuff. It took me about 3 times of going through every actor and looking for a simpler and more sequential way to accomplish the same logic intentions. After about a good solid week...my game was a ton more optimized and I saved about 30% on my processor demands.
If you are running over 25 FPS on an iPhone 3G...then you game isn't good enough for the big time (IMO) and needs more depth.
[EDIT]
If you are running 60 fps with a app file at 20MB...either you have 200 scenes or your graphics are NOT optimized. Is everything 8 bit that doesn't have transparency? If not...make it so (unless your app is a Lite version of Photoshop for iPhone or a modern art gallery). Is all your audio optimized? If not...make it so (unless its a HI-Def audio soundboard app). You should be much lighter than that...unless you have like 400 levels of puzzle wonder. If you are a fast moving action-physics game (like my BDX) then I want to know your amazing secret of how you are getting a 20MB app running at 40-60fps.
Images - Pretty much everone is going to need transparency to some degree, i suppose there are a few backround sky's and other images i could change, lush!
Audio - How do i best optimize that? So far, all i've got is i've purchased as stereo wav files in 44.8? from istock, dragged it into GS and let that convert it. I've read a lot about .caf being better as it isnt compressed but isnt that a bigger file size?
So far i went through all my scenes and all my actors and changed any non moving bits to not moveable, dont know if that really helps but read it somewhere.
Do you have any idea what 30-40 fps on a 3gs would roughly be on a 3g and would it be acceptable?
Not everything needs transparency...or at least 24 bit transparency. I mean come on...do you really have 20MB of transparency images? If so...better redesign your game a little bit or reduce the image load and reuse some of your graphics.
HOLY CRAP. WAV FILES? OMG....you really need to compress that stuff. There are tons of posts on audio optimization. Read some of those. We have had trouble with caf files ourselves but other don't...we use optimized mp3 files and they seem to work fine. Audio coding software is out there from Free to $400. You get what you pay for.
Do the same for graphics. If they are invisible...uncheck the visible tick. Also make sure the physics values are 0 for anything that doesn't use physics...otherwise I believe they get loaded into the game physics engine = bad for optimization.
No idea...don't have a 3GS...don't need it. We test on 3G and an iPod. My guess is you will crash a 3G. Our threshold for gameplay acceptability is around 18 FPS on average. However we are working to get BDX over 20 with no crashing. Currently we run out of RAM on one of the game modes and the phone force quits. Still trying to reach our threshold target...its a work in progress...and the game salad game engine isn't leaving us much room to work in.
For you...strive for 18-23 FPS on a 3G. Everything else will do much better than that.
As I said...if you are trying to do this to make money...you better pay attention to the details and make it work on a 3G. If you are just having fun playing with GS...ignore everything in this thread and go have fun.
most of my scenes have multiple layers so will need to be transparent, as well as the actors that overlap them but yes there are some i could take that out of. Making the un-seen invisible is something i will do, does set its opacity to 0 work in the same way? im guessing it will still check so need to make them all invisible.
Good tip on the physics part as well, oh how im in for a rough ride optimizing this project. haha.
Wav files, i know, i know, they are bad but i thought that was the point of GS converting them for you, am i missing something here? What format would you suggest which is going to be less obtrusive on my device? I've read quite a bit on the audio optimization but some people go proper deep and it just goes flying over my head, i guess im kinda asking, which is the best to use when thinking about the device its going to be played on?
I am a hobbyist, i always had a dream as a kid to make a game but after not applying myself i soon found out that i was never gonna be able to do it ... until GS that is. I have a full time job in IT support so this has been my side project but i have worked very hard on it for many hours spanning across 2 months now. I usually squeeze an hour in before work, sometimes a couple of hours at work and 4 nights during the week i probably spend another 4-6 hours on it so i am trying to make it professional and am trying to pay attention to all the details. My problem will be, as im new to GS, i could of done things a lot better from an optimizing point of view if i was better skilled, nearly everything works how i would want it to work but i feel if i was making this in 6 months time, it would probably have a lot better code logic! I guess that why people say dont make your dream game 1st. haha. I have made a few other apps but this is my 1st real game but alas, im very proud of it so far and its nearing completion and i just cant wait to get it out there.
I do appreciate you taking the time to respond with all your insights, knowledge and tips, thanks.
Oh if i look at the package contents of my game project its currently at;
27mb pictures
5mb screenshots (do these get removed from the final build?)
3mb audio
Thats file sizes on disk though, it reports at exactly 20mb from within GS
Use 8 bit whenever possible. The alpha = 0 does not prevent the images to be loaded into the renderer and use RAM space. Only the visible switch does that and it can not be changed. The images are either in or out in terms of processing. Even if alpha = 0...it might as well be 1 as far as the processor is concerned.
RE: Audio
Optimize the audio as best as you can BEFORE import. This will lighten the load on GS. We use MP3 files at quality as low as possible without ruining the sample. This will take some trial and error. My business partner does our audio so I don't know the details on it. But others do.
As far as time...we have been working for over 10 months on XCode based apps. GS has shrunk dev time by 75% for us. 6 months part time isn't bad for a game. I have been working for 4 weeks on BDX (about 16 hours a day...6 days a week) and its still only 50% complete. Development takes time...but it sounds like you are on the right track.
My suggestion is that you really work HARD at trying to get that image load down. Its killing your app performance (for the 3G). Your audio load isn't too bad...but that will improve with compression.
Do you use the viewer...which gives you RAM use and FPS readings. A 3G has about 40MB of RAM available. If you are over 35 on your 3GS...you may have big problem on a 3G.
Looking forward to a test drive down the road!
Good Luck.
If you are running 85 MB...you will crash an iPod too. They only hold about 45-50mB of available free RAM.
You really need to downsize. Remember...this is mobile device game development...not CPU platforms. That is the challenge you face.
Cool games aren't hard to do. Cool games on a little mobile device...that is a different story.
fadeSpeed = 100
constrain attribute: self.alpha = abs(sin(game.time * fadeSpeed))
I think I still win on the Optimization front though.
But your solution is much more elegant!!! You win on cleverness.