Re: Newb Needing Help With Classes In BGT
Well, if you were checking dozens of active objects at once in such a for loop, and even more so if you were calling some heavily calculating methods on them rather than just simply comparing a couple variables in an if statement, it might become somewhat processor intensive, but believe me that it's probably the easiest approach to reliably managing several different objects of the same class and even several different classes at the same time.
I'm doing this myself with 3 classes, one of them is allowed to have up to 60 active instances at the most at one moment, and the other two classes can have 20 each. I'm doing this on each iteration of the main game loop, calling the act method of each instance of each class through this for loop because all of them have to do something continuously, and I'm not getting any lag or processor overheat at all so far.
One of the main reasons why it's not as performance intensive as you might expect without t rying it yourself is that the example array of trampolines as Omar declared it is in fact an array of object handles, if you noticed. That means that on each iteration of the for loop, the program will only be looking at the specified place in memory where the given object is stored, rather than creating an all new unique local copy of the exact same object just for the purposes of this single check in the for loop, if this makes sense.
Another very important thing which doesn't seem to be described in enough detail in the BGT tutorials is correct usage of the wait function. Never ever use it in such iterative loops where you need to quickly glance through an entire array of objects of a certain type to see if they are doing something or in a certain state as quickly as possible. In these situations, you need the instruction to be carried out immediately. The wait function should only be used in the main loop, and only once, for 5 milliseconds only, which is probably the best compromise between execution speed and CPU usage. For looping through an array of object handles should theoretically take even less than 5 milliseconds on every iteration in most cases, which is never noticeable for the player and it doesn't start using the processor hardly enough and long enough for it to notice any difference either, if you see what I mean.
A very useful concept which is heavily used in mainstream games, which would probably improve performance of most current BGT games a lot, and which I myself still have to learn and adapt even though I've heard a lot about it and like it in principle, is called frames per second (FPS). Basically, you set up a global timer for the main loop which will only perform all the needed instructions if a certain amount of time has elapsed. Otherwise, the contents of the loop will be just skipped and the next iteration will be invoked (continue), until the required time has elapsed. If you say, for example, that you
r game is running at a rate of 60 FPS, which means that the game should act 60 times a second, you check:
if (frame.elapsed >= 1000/60)
{
frame.restart();
// Main loop goes here.
}
else
{
continue;
}
A little trick I'm currently using in the game I'm working on right now is that I know that the player is always faster than anything else in the game. I intercept keyboard input on every iteration of the main loop but I invoke all my for loops for classes only if (player.movement.elapsed >= player.speed).
Hope this helps,
Lukas
_______________________________________________ Audiogames-reflector mailing list Audiogames-reflector@sabahattin-gucukoglu.com https://sabahattin-gucukoglu.com/cgi-bin/mailman/listinfo/audiogames-reflector
