I've been wondering about the efficiency of this 'Always' condition. Seems that people can't agree on it. Some people say that it's as harmless as your average event. Some people say it slows the game like hell. Some say that it just doesn't work most of the time. So, what is this condition that sparked so much controversy?
Here's what I've understood so far...
It's like um... a timer, except that it runs every time the cycle goes through it. Some say that this would make it as harmless as any condition, but experimentation has seemed to prove otherwise. Even some of those FPG guys highly discouraged its use. However, some people say that it's harmless simply because the app checks it in every cycle... just like any other condition.
My theory... it IS harmless, but only if you don't put any actions with it. It takes little CPU power to process the condition. What makes it so devastating is that it actually does the actions in every cycle. That means, in every spare moment it has, it'll do what actions you put in the event. Simply destroying something in every cycle usually doesn't drag down the CPU that much, but it's bad when you stuff in lotsa actions with it, like visibility, alterable strings, positions, etc.
Then there's the comparison between the processing time between timers and the darn 'Always' thing. Yes, it does take more CPU power to calculate a timer over an 'Always' condition. However, the CPU only activates the actions it when the timer reaches the chosen time. Which means, the actions are done less often, making it not have to do as much work.
Yeah, I know, using the Always condition these days isn't as devastating as it used to be. Back then, during the days we were making games on 75 Mhz Pentium I's with 8 MB RAM... now that was different. You spoiled kids these days are going about with your 3 Ghz Pentium IV w/ 556 MB RAM. Of course you won't feel the effects. It's like a pin hitting a guy 40 feet tall.
Anyways, IMHO, the Always condition should be used as little as possible.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
19th June, 2003 at 05:54:54 -
People are crazy! The always doesn't slow your comp down, its the actions you put after it.
If you've ever done any C++ or VB, you'll know you can have loops. In VB to make a loop you add a timer and get the timer to run something every certain miliseconds. For an always command you set the miliseconds to 1. So every milisecond it checks that event.
Vb
if timer_time () then
do stuff here
end if
Doing that is no differant to checking if a button is being pressed. Because there is an in built code, constantly checking if a key is pressed and what key it was. So your hardly putting any more pressure by adding one more checker. It's the actions that matter, not the condition.
The MMF loop runs in increments of 2/100th's of a second. The "Always" condition is EXACTLY the same as the "Every 00''-02" condition or the "Every 00''-01" condition. All three of them run the event every 2/100th's of a second. It is just easier and faster to click "Always", so that's why it was put in.
the "Always" thing is good to use in groups if you use the group as a function.
"If Darl McBride was in charge, he'd probably make marriage unconstitutional too, since clearly it de-emphasizes the commercial nature of normal human interaction, and probably is a major impediment to the commercial growth of prostitution."
-- Linus Torvalds, December 5th 2003.
(Darl McBride is CEO of The SCO Group)
this place sucks but don't tell anyone, it's our little secret, ok?
Always, IMO, is your event for keeping your constants grouped.
You can use it to always make sure stuff is invisible, or moving faster than 100 speed, or like viewable weapons, so they are always set the position of the player.
The good thing is however, it's a low preference event, if what you'd call it. In other words, say you have a bullet and you want it invisible except for when it's Disappearing animation is play...it'll work if you simply do this
- Always
Set Bullet invisible
-Disappearing animtion of Bullet is playing
Set Bullet visible
So you can use other events to overwrite its effects...it's quite versitile really IMO. Although useless if combined with other events
MUGGUS
Come and annoy me more at
www.muggus69.tk STOUT ANGER!!!
Assault Andy: My dad and I had a discussion on the fact for the timers. It's not really the best way to do a loop, there are "For" loops and "Do While" loops in Visual Basic (though I never learned how to use them). Using those loops uses less objects and less memory.
LOL, back in the old days, using the condition really made a difference (especially when it comes to scrolling and calculations). I guess you guys don't even notice these days.
Personally, I never really did find MMF's always event running in exactly 2/100th's of a second. Back then, stuffing my events with it made it more like... once per half second . Replacing the Always event with 'every 4 centiseconds' always worked much more smoothly.
But yeah, like the hobo said, it doesn't really matter anymore. Comps these days go about 20 times faster than comps back in the days when it would be a problem. Heck, the slow rate was the reason that 'machine independent speed' option (now worthless) was made.
Still, this thing keeps bothering me every time I try to make a game. Maybe I'll ask the Clickteam guys about it someday.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
Well, due to curiosity, I actually decided to waste half an hour performing a little experiment. I took a blank frame, put the app on machine-independent speed, made the the program create an active object under two conditions:
1. Condition A
2. Timer is < 1 second
Condition A is set and changed to Always, once every 0.01 seconds, once every 0.02 seconds, once every 0.03 seconds, once every 0.04 seconds, and once every 0.05 seconds.
A counter was set up to count the number of active objects the program created in less than 1 second. The app was run 5 times. And before you asked, I closed all the other apps .
Now if you look at the results, you'll notice that the timer events are run more slowly. What this proves is that the every 0.02 condition is slower than the always condition. Why? Well, it's either one of two things:
- An MMF cycle is *less* than 1/50th of a second.
- The timer events use up more memory
However, the every 0.01/0.02 events don't seem to be running slowly enough to prove the first theory. Heck, the results of the experimentation on the every 0.01/0.02 conditions are more inconsistent compared to the other events. So, this shows some strain (albiet minor ones) on the system resources.
So, overall, it shows that it's the timer events that use up more memory, which proves that you all were right and I was wrong all these years. However, I still stand by my ideas that most games would still use less resources if people used the 'Every 0.04 seconds' condition instead of the 'Always' condition.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
Muz: Wow, that's useful. You should post it as an article.
As for VB Loops, there are five I know of- Do While, Do Until, Do-Loop Until, Do-Loop While, and For.
The always statement must be most simple, less cpu and memory intensive you can imagine.
When you for example check for colision, the cpu has to calcualte a lot to see if theres collision. If you compare two number the cpu has to evaluate the numbers (fast and simple too).
If we look at it programming wise using java in this example the events can be listed as a list of if statements:
public null listOfEvents() {
if Common.collision( ObjectA, ObjectB ) {
Common.Sound.play( boom.wav );
}
if Common.Timer.equalOrGreaterThan( timeStampA, 0.02 ) {
Common.Sound.play( boom.wav );
timeStampA = Common.currentTime();
}
if true {
Common.Sound.play( boom.wav );
}
}
Ok, lets take it bit by bit.
The first if statement checks to see if two objects collide. The code that check this is the method Collision. How is does this is out of topic, but it will take some time as the position of the objects must be evaluated as well as the size and what pixels are solid (if non solid pixels of the two objects collide the objects really havent collided yet).
When this happens a sound is played.
The other two if statements also play a sound when they become true.
On to the next. It is an every some time event. At the beginning the game saves the current time in a variabel called timeStampA (done elsewhere in the code not seen). The method equalOrGreaterThan checks if the current time and the timeStampA has a difference equal or greater than 0.02 seconds. If its true the sound is played and the timeStampA is updated to the new current time so the event becomes true again in no less than 0.02 seconds.
This is not as advanced as collision. Basically the difference is found this way currentTime-timeStampA=X if X => 0.02 its true.
So its a bit calculation and a boolean operation (are X equal to or greater than 0.02?)
The last event is always.
The if statement says:
if true
This is the java way but other programlanguages will have similar posibilities. Its a simple boolean operation thats always true so the event is always true. You cannot do a more simple operation in the cpu really. And its only one small operation.
If you want to really save cpu time, the always event could even be done without an event so the code becomes:
The sound is played every time the events are checked just as its supposed to without even checking anything!!! Speaking about cpu saving!!!
So to sum it up. If Clickteam made the always event cpu and memory saving (something like Ive shown) the always statement is the simplest event you can make in your game.
Its NOT the event thats slow, but it may be your actions that are.
If you do a trindazillion (imaginary large number ) actions in the always event, of course the game will be slow
Well... like my experimentation results have shown, the always condition runs everything faster than every other condition. If you put a calculation action under the condition, your program will be calculating more often than say.. an every 0.04 condition.
Disclaimer: Any sarcasm in my posts will not be mentioned as that would ruin the purpose. It is assumed that the reader is intelligent enough to tell the difference between what is sarcasm and what is not.
Well, if you guys wan't to go into it programming wise, it is as simple as a small BASIC program.
Think of the LOOPs as always conditions, and what is in between the DO and the LOOP statements are actions.
DO
LOOP
is faster than
DO
PRINT "HELLO"
LOOP
In particular cases where you would use the PRINT command to output all calculations while testing a chess "tri" algorithm for example, you will notice a large difference in speed as to not printing calculations to the screen.
Hope this helps!
Life is a rave. You enjoy it while its here, but forget it when its gone.
Death Reaper X font colorredbDarran Baker/b 1984-2006/font
Registered 02/07/2002
Points 1454
1st July, 2003 at 11:46:03 -
Lol I use TGF but there's never been a game when I haven't used ALWAYS I think.
I've never experienced any slowdown unlesss you stupidly put always "play x.wav" by mistake...not good
Assault Andy Administrator
I make other people create vaporware
Registered 29/07/2002
Points 5686
2nd July, 2003 at 07:32:04 -
Yea, i never find it slows my games down, unless it creates lots of object without destroying them..... Or the deadly sound thing that Death Reaper X said... *YeEcH*!
the always condition is NOT the fastest cause when i make "shadowtrails" with semitransparent objects the every 00.00.00 condition creates more objects than the always... but every 00.00.02 should create just as many but it doesnt!
Beware of life ...so far noone have survived it.......
Daniel[Crazy_Productions], I said the always condition is the less cpu and memory using one. Every uses more processing and memory power.
I said nothing about what condition creates more objects. But I may have an idea why you get different results.
If you use the always condition to create 1 object like a black box a random place you should get 50 boxes in 1 second since the event list is run 50 times a second (once every 0.02 seconds).
If you use every 00.00.02 seconds you should get the same number of objects IF the every is precise.
If you use every 00.00.00 you should get more objects. MMF may handle this by calculating how many times the given time happens in 0.02 seconds. 00.00.00 is not a real time so MMF may round it to the smallest time it can handle. This may be 0.01 seconds. If this is true every 00.00.00 should get you 100 objects in a second IF the every is precise and handled this way.
So it is for sure, that always is the most precise 00.00.02 condition IF the computer can run the game fast enough.
In my experience, the always condition would work fast. But using it repeatedly over and over in difrent conditions, things didnt WORK as good. I dont remember performance issues. I dont doubt that the every .01 second condition is more comp intensive, but it sure does work better then always. But to notice the difrence, you gotta have complex stuff going on.
I have 1 always, right under the Start Of Level condition. It holds tons of friggen actions, and then for everything else, I have everys. And theres alot! Works for me, on a 900 mhz pent 3 256 ram.
Lets see if anybody can explain why they have the NEVER condition. Since if you tell it to never do somthing, the code that tells it TO do it, overrides. (I know the awnser of course)
We are the music makers, we are the dreamers of dreams...
Advertisement
Post Reply
.
) actions in the always event, of course the game will be slow 
