variable=variable & case switch

[DST]

I've noticed a couple errors going around that I'd like to help clarify for people.

The first one is people using y=y+variable, or variable=variable+1;

Please stop doing this. You are telling the computer that variable=variable? The computer already knew that. Variable=variable before you even typed anything. Anything always equals itself.

The correct way is variable+=1; You can use any math function in that. Variable*=.95; Even variable/=.95; or y*=-.5;

Everything you tell the computer to do takes a bit of cpu to perform; That's why we tell you to stay away from if if you can. that's why we tell you to use timers or other events instead of draw actor. Draw actor checks every frame. Imagine that...telling the computer that y=y 30 times a second. It eats up cpu fast, yet accomplishes nothing.

The second is using textNumber as a variable. This is bad for many reasons, one being that if you want to change it for a certain purpose, and yet display it at the same time, the display becomes meaningless. What's more, you can't use it to make advanced functions, which you will be using if you are ever making a full, commercial quality game. You also can't save textNumber. Its like trying to build a house out of paint.

Another is people using 'if' when its not necessary. One thing i see are people using multiple ifs to make a mickey-moused case switch.

if (powerlevel==1){do this};
if (powerlevel==2){do this};

The correct way is
switch(powerlevel){
case 0:
do this;
break;
case 1:
do this;
break;}

When using if's like that, the computer will check every single if to see if any are correct; but with a case switch, it begins the switch already knowing the variable; once a case is true, it ignores the rest of the cases.

And also using if to make a mathematical adjustment is silly.

if (canjump==1){yvelocity-=8;canjump=0;}

The correct way here is
yvelocity-=8*canjump;
canjump=0;

Actions are applied to the frame they are triggered in; in the above example, yvelocity will perform its function with the current canjump, it will be applied to the frame, and the player will move upward, THEN canjump will become 0.

Lastly, don't create more actors or more variables when you don't need to. Use cloneindex and integer arrays.
A prime example is with text actors displaying variables; don't make a separate text actor for health, gold, etc.
Instead, clone the actor, and use a case switch:

switch(cloneindex){
case 0:
textNumber=player.hp;
break;
case 1:
textNumber=player.gold;
break;
case 2:
textNumber=player.time;
break;
}

Now all your display variables are in one action. You don't have to go chasing around to find what's what.

I hope this helps someone.

[Fuzzy]

I'm going to agree with most of what you said.

But I'm also gonna correct you on a few things!

The first one is people using y=y+variable, or variable=variable+1;

Please stop doing this. You are telling the computer that variable=variable? The computer already knew that. Variable=variable before you even typed anything. Anything always equals itself.

No, this is a perfectly correct and valid way to do this. The only reason we use the short hand version is to save typing. To the compiler they should be identical. But it pays to be as precise to the compiler as possible, and in that case, use var=var+someval;

I'll tell you why, and I'll prove it.

Why? think of it like this: you are telling the compiler "thisvalue.. is equal to itself plus thatvalue. [thisvalue] = [thisvalue+thatvalue]. You are not wasting many cycles. its just the same as saying thisvalue = thatvalue + anothervalue. it looks self referential, but it isnt. Saying thisvalue+= is just shorthand for that very thing.

I'll get to the proof right after this!

You can use any math function in that. Variable*=.95; Even variable/=.95; or y*=-.5;

Bad DST. Perhaps DXT is posting for you? I know it works, but thou shall not exclude a zero before a decimal place. Bad form Peter, as they say in Peter Pan. Good programmers add a zero if its less than 1. Always.

Why? Because if you do this...

Code: Select all

 fuzzy=.9

and you accidently erase/exclude the = or something silly you get an error that can be very nasty to find.

Code: Select all

fuzzy.9

looks just like a clone number. You'll look past it a million times! Its very much like using a singular = in a comparison. As well, the period is used for other things in programming, so you might get legal code, but not the effect you are looking for. For example, in linux, a hidden filename is prefixed with a period. so .56fuzzy would make a hidden file! Dont do it. Add that zero.

on to the proof, right?

In this programs global code you will find some vars. Set the number of tests lower if you do a complicated test.

In the two functions below that, I have indicated where you may insert code to test. currently it compares var=var+1 against va++ each 10 million times.

Run the program in GE and press the test buttons. They will set the start time in seconds and when its done, the finals. Then do the other test.. you may have to wait for them to finish. Only do one at a time. Give it time, its probably not frozen. For example, the first test takes 12 seconds on my machine, a core 2 at 3.0 ghz. Reduce the number of tests in global code if you are much slower, or be prepared to wait!

My results: over 10 million operations, using var++ is faster than var=var+1 by only 2 seconds. Statistically, its not an issue for games.

[Freddy]

Interesting, I never knew that the way you wrote your codes affected the performance of the game, but I guess it makes alot of sense.
Btw, could anyone explain to me the switch case function? I never really understood it.

[DST]

'switch' is the function. Then your variable is in parenthesis. switch(variable){}; This allows multiple comparisons. You could almost thing of it as a group of if statements.

The difference between switch and if, is that with swith, the comparison occurs inside the {}, instead of inside the ().

switch(variable){
case 0: //basically means 'if variable ==0'
do this:
break; //is equivalent to the ending } in an if statement.
case 1: //if variable==1
do this;
break;
} //ends the switch

The only punctuation you have to remember is that the case x: ends with a colon, and the break; ends with a semicolon.
You can exclude cases if you want, you could start at case 1 and leave case 0 out. Cases aren't as useful for large integers that have no smaller possibilities. For instance, if a variable never dips below 99, a case switch wouldn't be so good there.

A switch is best used in a situation where only one instance of the variable is being acted upon; that if you switch (level), level is only one number at a time, and all whole integers. You're either on level one, or level two.
But many things are like that. Canjump, PlayerFaceDirection, Attackmode, Cloneindex...these things are only one integer at a time.


hmm....25% fuzzy....2 seconds is 25% of 8 seconds. I'm sure your next arguement would be that all 8 seconds were caused by that one type of situation, which would be unlikely in a normal game. And I would respond: so is that 25%.

so if a player had a lot of actors doing that in a draw actor several times, you might realistically end up with 4000 of these operations pers second, at the very most. Still, if you write it my way, its the cpu of only 3000 of those.


It might not be statistically important. It is backwoods stumpjumping logic though.

[Bee-Ant]

When i first time knew about code, i used var=var+1; it because that code written in caveman tutorial and documentation. And now,when i advanced enough, i use var+=1;
You shouldnt force other ppl to use that code DST. Let them learn and choose...sooner or later,they'll know wheres better.it just a process of growing,let them grow naturally.

[DST]

Yes Bee, i guess i do go overboard sometimes. The reason is that....

DST is going to make games. DST is going to make games for a living. DST will let nothing stand in his way. DST wants to see other people become successful at it, too.

If you are making games simply for fun, then by all means, do it however you want.

switch(professionalism){
case 0:
do whatever;
break;
case 1:
save every bit of your time and your cpu time you possibly can to make the absolute best finished product;
break;
}

switch(fun){
case 0:
do something else;
break;
case 1:
keep making games;
break;
}

[Bee-Ant]

you wanna make them sucesful?oh come on..you're too care to other ppl.are you sure they care you too?If you cant let anyone stand on your way,why you want make them succesful anyway?

Code: Select all

void dst()
{
   int care;
   for(care=0;care<99;care++)
   {
      //do nothing
   }
}

[DST]

Cause no man is an island.

Everything i know about programming i learned from the ppl in this forum!

[Freddy]

I dunno, I just kinda like the var = var + 1; over the var+=1;
I don't mind the extra 2.7 seconds it takes to type it out...

Btw, thanks for the explination -- DSTscore = DSTscore + 1;

[Fuzzy]

You have to remember that what I wrote for testing includes CPU time for setting up and executing the function wrapper too. Thats why it took 12 seconds to do it 10 million times. When i just inject the test code straight into the actors, it becomes 2 seconds total time for both of the tests and it still includes the loop time!. For example, if we consider that the for() line is really about four separate instructions, then the tested code is only 1/5 that 2 seconds, or 0.4 seconds of the total. Meaning that optimization would be better focused on the loop.

Unfortunately it would be very tricky to eliminate that loop so that we can get a closer result. Injecting straight code shows me that the two functions have some difference in speed, even though the only difference is in the name!

Considering that GE is at least partially an interpreted byte code language, thats pretty darn fast!

[edit]
I've repeated the tested code 10 times in the body of the actors script and reduced the tests by 1/10th. This resulted in a new time of only 1 second to do 10 million additions. Total time taken by the test code.. 0.2 of 1 second, or about 12 milliseconds. Since the shortest possible timer in GE is 12 milliseconds, I think i hit the limit.

I'm going to try 100 now..

ok. Changing to 100 operations in the code and only 100 thousand repeats doesnt improve the speed any; its still at 1 second to do them all. I could improve my test machine by using milliseconds instead. Maybe I will do that and test all the GE functions and build a chart of their speeds?

[DST]

Maybe I will do that and test all the GE functions and build a chart of their speeds?

That sounds like a great idea!