Hey Vakinox, sorry if I was a little rude, it just seems like you were acting like a broken record rather than really trying to learn something about loops. I know they can be tough to work with first when you can point to two different examples of loops and one seems to work but another doesn't. I totally understand your confusion. I guess it's just that I don't know how else to explain it. I mean a loop loops infinitely, and you are using Sphere functions which do things behind the scenes.
So, let's clarify a bit more.
while (true) {
QueuePersonCommand(...);
}
The reason why the thing above works
after the while loop breaks/ends has to do with the internal command queue. This is really only useful for queuing movement commands. It doesn't help you make a battle system (or at least one that doesn't run on the map engine). So, when the loop runs, it does what Jest just showed you:
QueuePersonCommand(...);
QueuePersonCommand(...);
QueuePersonCommand(...);
QueuePersonCommand(...);
QueuePersonCommand(...);
QueuePersonCommand(...);
QueuePersonCommand(...);
QueuePersonCommand(...);
QueuePersonCommand(...);
// ad infinitium
Now, when you break from the loop, and resume the map engine, and say you were using COMMAND_MOVE_EAST, then the sprite will start to 'chew up' the command queue and move:
sphere-sprite-move: COMMAND_MOVE_EAST;
sphere-sprite-move: COMMAND_MOVE_EAST;
sphere-sprite-move: COMMAND_MOVE_EAST;
sphere-sprite-move: COMMAND_MOVE_EAST;
sphere-sprite-move: COMMAND_MOVE_EAST;
sphere-sprite-move: COMMAND_MOVE_EAST;
sphere-sprite-move: COMMAND_MOVE_EAST;
sphere-sprite-move: COMMAND_MOVE_EAST;
sphere-sprite-move: COMMAND_MOVE_EAST;
sphere-sprite-move: COMMAND_MOVE_EAST;
That's why it seems to do nothing while the loop is running. It is queuing things up behind-the scenes and not until the map engine resumes control will it update the sprite.
Now, outside of the map engine, say in your battle system, you are getting these 'pauses' since you made the computer think forever. But it doesn't have to.
I already showed you the game loop philosophy, all you need to do is follow it:
var done;
function BattleSystem() {
done = false;
while (!done) { // the only while loop we need
// draw stuff
MyRender();
// update stuff
MyUpdate();
// FlipScreen
FlipScreen();
// Key Handling
while (AreKeysLeft()) {
switch(GetKey()) {
case KEY_ESCAPE: Exit(); break;
}
}
}
}
function MyUpdate() {
/** Put your battle system update logic here **/
}
function MyRender() {
/** Put your battle system render logic here **/
}
That means while it's thinking about things like who goes next, it can still draw stuff to screen. Now, I keep saying loops go on forever - that is only true if you don't give it a stopping condition. But game loops like the map engine or a battle system don't have a definite end. Sure a battle system ends when all enemies are dead, but it can't know that ahead of time. So it must loop forever, and only break when all enemies are dead - whenever that happens - or when you run away. The problem here is that since it is looping forever, waiting for enemies to die, it'll do nothing unless you giver it the ability to update controls and draw stuff to screen. That's why the game loop philosophy I posted above is so important. You need to manually handle rendering and key presses so it doesn't 'feel' like blocking code.
The MapEngine makes it easier on you with the help of SetUpdateScript and SetRenderScript. But inside your own game loop those SetUpdate/Render functions are meaningless, since they only work on the map engine. So you must handle that stuff manually. Again take a look at the code I posted above for handling your own custom game loops and I hope you can see how remarkably easy it is to make a battle system in that way. I should really post this as a tutorial on the wiki.
I might be getting a little bit frustrated here since I feel like I'm pointing out and explaining why the sky is blue and you are just not understanding. But I digress, it was also very hard for me to figure some of this stuff out and I've just gotten so use to working with these loops it's just a second nature for me to know how it's done. It'll click for you eventually.
I mean when you begin to realize you can do your own stuff outside of the map engine is when you'll realize the impact of 'blocking' code and how to minimize it. I struggled a long time to understand what the heck this 'blocking code' concept was. That was until I realized all code is blocking code, it's whether or not you update input and render stuff that makes it seem not so blocking. I think a good example of blocking code is in Bruce's Scenario library for Sphere. It deliberately blocks the map engine as it waits for other events to finish.
Also sometimes it's hard to tell when your code ends or begins when working with the map engine since so much is done for you. But once you get past these little things you'll begin to realize that you can have a lot of fun designing your own systems.
tl'dr: A while loop is not like a thread: it can't run thing simultaneously along with other things. I think I see what you were trying to do: use a loop to repeat an event over the map engine without blocking anything. I feel that you use the while loop as a way to 'loop' code as other stuff happens. But it doesn't work like that. SetUpdate/Render Scripts are already in a loop and will act accordingly. But a loop within those will block the map engine. Meaning, you'll have to manually handle input and graphics (which is not so bad).
Hey, take a look at your menu code. You'll notice it too has a kind of game loop structure in it like I showed you, you just never noticed it.