The Daily Click ::. Forums ::. General Chat ::. Philosophical/Scientific debate The mysterious "Always" condition...
 

Post Reply  Post Oekaki 
 

Posted By Message

Muz



Registered
  14/02/2002
Points
  6499

VIP MemberI'm on a BoatI am an April FoolHonored Admin Alumnus
19th June, 2003 at 04:58:27 -

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.

Image

Assault Andy

Administrator
I make other people create vaporware

Registered
  29/07/2002
Points
  5686

Game of the Week WinnerVIP Member360 OwnerGOTM JUNE - 2009 - WINNER!GOTM FEB - 2010 - WINNER!	I donated an open source project
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.

-Andy


 
Creator of Faerie Solitaire:
http://www.create-games.com/download.asp?id=7792
Also creator of ZDay20 and Dungeon Dash.
http://www.Jigxor.com
http://twitter.com/JigxorAndy

Mr Saturn



Registered
  14/05/2002
Points
  357
19th June, 2003 at 12:15:44 -

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.

 
n/a

Mr Saturn



Registered
  14/05/2002
Points
  357
19th June, 2003 at 12:18:51 -

By the way, here is a good article about how the MMF engine works: http://www.clickteam.com/English/GTM/GTM4.htm

 
n/a

Aali [Crazy_Productions]



Registered
  13/10/2002
Points
  843
19th June, 2003 at 13:09:38 -

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?

Muggus

Possibly Insane

Registered
  31/07/2002
Points
  2958
20th June, 2003 at 07:53:35 -

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!!!

RapidFlash

Savior of the Universe

Registered
  14/05/2002
Points
  2712
20th June, 2003 at 21:15:34 -

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.

 
http://www.klik-me.com

Muz



Registered
  14/02/2002
Points
  6499

VIP MemberI'm on a BoatI am an April FoolHonored Admin Alumnus
21st June, 2003 at 09:41:59 -

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.

Image

Shen

Possibly Insane

Registered
  14/05/2002
Points
  3497
21st June, 2003 at 09:49:16 -

Always is run every MMF tick, about 50 times per second. And it's the actions that slow it down, yes, but you rarely notice.

 
gone fishin'

Muz



Registered
  14/02/2002
Points
  6499

VIP MemberI'm on a BoatI am an April FoolHonored Admin Alumnus
24th June, 2003 at 08:09:39 -

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 .

So the results are...
always 51, 51, 51, 51, 51
0.01 50, 49, 50, 50, 50
0.02 48, 49, 48, 48, 48
0.03 33, 33, 33, 33, 33
0.04 24, 24, 24, 24, 24
0.05 19, 19, 19, 19, 19


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.

Image

RapidFlash

Savior of the Universe

Registered
  14/05/2002
Points
  2712
24th June, 2003 at 09:23:11 -

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.

 
http://www.klik-me.com

Cybermaze



Registered
  03/04/2003
Points
  853
24th June, 2003 at 14:43:08 -

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:

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();
}
Common.Sound.play( boom.wav );
}

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

 
If you knew, I would have to kill you...

Muz



Registered
  14/02/2002
Points
  6499

VIP MemberI'm on a BoatI am an April FoolHonored Admin Alumnus
27th June, 2003 at 19:47:47 -

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.

Image

nev`



Registered
  26/06/2003
Points
  61
29th June, 2003 at 00:56:57 -

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



 
Rah.
   

Post Reply



 



Advertisement

Worth A Click