Slow motion

#1 Vedat, there is a way to control the frame rates in the scene editor -- click on any empty area of the scene in the scene view and then goto the edit tab -- in there, you will find a section called "Scene Management" (or something like that) where you can hard set the frame rates.

Now, I don't know if hard-setting the frame rate slows down your code or your AI logic, I believe it most likely just prevents the engine from rendering at 200fps (if set to 30fps for example) so any of your schedules that are set to run at increments of 50-200ms or whatever, will still run when they are told to run ... however, you may not see the affects of the code until the next frame is posted to the video card.

The best approach for debugging the code would be to have it print out to the console statistic data, or use the network debugging available in Torsion and set break points ... if printing to the console, you can review the console.log file at your own pace after the game is done running ... and identify what went wrong -- I usually use special print statements such as'

**** DEBUG START
VarX: Value
VarY: Value
method(param1, param2)
VarZ: Value
**** DEBUG STOP

This allows me to quickly jump to my debug spots ... and review the variables I was question, as well as any methods that were called ... I naturally type 'echo', 'warn' or 'error' statements at the start of all my new functions ... especially when I know i'll need to debug them, and i sometimes wrap them with a:

if($debug) echo(....);

and I create a $debug at the start of the script in main.cs or game.cs and toggle it on or off

Depending on the length of my source, I sometimes check the value of $debug to see if it's greater then or less then a certain value (verbosity levels basically) ... and sometimes, I check to see if it equals a specific value such as "breakpoint1" ... where I can set $debug to "breakpoint1" and it will only print out stuff with

if($debug $= "breakpoint1") echo(....)

Hope this helps.

#2 David, in v1.1.3, in scene integration, it is possible to set FPS. However this section is removed in v1.5. Also there are commands to arrange FPS in v1.1.3 like setScenePhysicsTargetFPS(%FPS) but these commands are "unknown" in v1.5.

I really appreciated the suggestions for debugging. Thank you very much. Actually, this is not a real bug but a visual detail that I want to check. That is why I find it easier to slow down the game and see it myself instead of echoing. Is it really impossible to play with the FPS in v1.5? Should I switch back to v1.1.3?

#3 Oh wow, I never even bothered looking for that stuff in 1.5 -- your right, it is missing.

And I never really needed the feature, so I never bothered checking the actual details behind Scene Integration options ... your right, it doesn't have a 'force to be' option, it's just a target option ....


As for detailing a visual thing, another suggestion might be to use something like FRAPS or Camtasia Studio (demo available) to record the screen ... and then play it back frame by frame in video software ... this way you can identify the visual quirk and hopefully resolve it ...

#4 Ok David. I'll try Camtasia. Thanks.

#5 With camtasia, you can actually save the video with a set framerate, such as like 5fps ... however, it does a 'frame skip' thing ...

if you use video editting software, you can actually tell it to 'stretch' the video so you see every frame ... but each frame lasts for say 200ms (5fps) ...

just use some good judgement ...

#6 To slow the game (but only the game, FPS stay the same), modify the variable $timescale (1.0 being normal speed and 0.0 being pause).

#7 Thank you Benjamin. Setting $timescale does the thing.

#8 One question:

its there in TorqueScript a function that acts like a delay function in C++?... like say im runnin somethin like this:

for(%i=1; %i<10; %i++)
{
    //some code here
    ...
    delay(30);  //in miliseconds
}

i ask this, because, the only way im doin it right now,its using schedule, but it doesnt suffice my needs, since everytime i use it, i have to run the entire function, but sometimes i just need some wasted time b4 continuing doin somethin.

#9 I'm also wondering about something like a delay() or sleep() command, would be really useful and I wouldn't need to stack a bunch of schedules.

#10 And the problem on scheduling too much (eg. schedules outta control), is that if you doit the wrong way, the system will CRAWL like you've never seen it b4... so, im still wondering if theres such thing like a delay or even an sleep function.

#11 I far as I know there is no delay or sleep or something like that in TGB. Schedules are all we have. Don't waste your time searching in the documentation. I already did and I'm taking pills everyday to get rid of that headache.

#12 Torque does not utilize a "delay/sleep" mechanism for TorqueScript (nor for c++)--while it is an effective design style for some types of games, in general the overhead is much less efficient than the design style used within Torque.

Schedules in themselves are extremely lightweight in overhead: whenever you post a schedule, you are simply adding a (very lightweight) SimEvent to be posted to the event queue for later processing.

Quote:
I'm also wondering about something like a delay() or sleep() command, would be really useful and I wouldn't need to stack a bunch of schedules.

While this style ("sleep") of event flow control appears "easier" at first glance, it is not very scaleable, as the overhead required isn't as trivial as the scripter would think.

Quote:
And the problem on scheduling too much (eg. schedules outta control), is that if you doit the wrong way, the system will CRAWL like you've never seen it b4... so, im still wondering if theres such thing like a delay or even an sleep function.

If you're design/implementation is crawling with use of schedules, then it would absolutely not work at all with sleep/delay. I would suggest that you take a fresh look at what you are actually trying to accomplish, and probably refactor your design to make more use of already existing events that occur within the simulation. One of the first things to look at would be breaking up your functionality implementation into more modulare and "single task" oriented structures.

Quote:
i ask this, because, the only way im doin it right now,its using schedule, but it doesnt suffice my needs, since everytime i use it, i have to run the entire function, but sometimes i just need some wasted time b4 continuing doin somethin.

Please don't take this as being disrespectful, but if your function is accomplishing so many things that "running the entire function" is bothersome to you, then your function is almost certainly trying to do too much as it is. Good programming practices would indicate that you should make your implementation more modular.

For those that think "sleep/delay" is more powerful than a direct ability to schedule, I'd suggest you think about what a delay/sleep is actually doing. It is actually less powerful to the developer to only be able to stop execution of a specific function at a specific point, and then continue execution at a later time, and it is also commonly much less efficient because standard sleep/delay implementations will pulse every single object in your simulation every single "sleep interval", and check to see if there is a pending sleep on that particular object currently.

With the Torque method of being able to schedule events yourself, you not only remove the necessity of polling every single object in your simulation simply to determine what sleep states are pending, but you also gain much more direct control over the event and execution flow of your objects. Instead of simply being able to "continue" a previously started execution flow, you can do anything you wish.

Again, please don't take this as disrespectful--I'm not trying to pick on anyone specifically, but let's take the following code into consideration:

for(%i=1; %i<10; %i++)
{
    //some code here
    ...
    delay(30);  //in miliseconds
}

Assumption: this code is within a callback handler, and is executed on a particular instantiation of an object (it's within a namespace function).

Observations:

--putting a delay, or even a schedule (which is more lightweight in overhead) within any sort of loop is almost certainly not something you should be doing commonly within a project.

Let's assume for a moment that Torque does allow the delay statement above, and see what type of performance overhead we might have. Let's further assume that the delay capability is implemented in a non-polling manner, and simply posts an event to the simulation to "resume execution at a certain point", instead of the more standard implementation in other languages of setting up a requirement for polling every object in the game, every timeTick.

--what is the purpose of the delay? That's the root question here.

--what does that delay statement actually do?

This requires some analysis of what's going on in the first place. As my first assumption indicates, this code is probably within an event callback handler, so first we need to assess what the frequency of the callback itself is, for an object. Let's be generous and say that the event this callback handler operates upon only happens every 5 seconds (a very rare frequency--most events happen at the millisecond range).

----every 5 seconds, you run a loop with 10 iterations. Within that loop, you create 10 new execution stacks for every object this code applies to, which do nothing except say "don't do anything with this object until my timer expires". In an event driven simulation, that's almost nonsensical--if we truly want a "timeout" for this object, then we should simply track a state on the object, and in the appropriate callback handlers check the state before doing anything to the object--no schedules, no delays, just "disable" the object for a short period of time.

(cont)

#13 Taking a very big step back from this low level, one of the key factors in successful Torque development that I think many might be missing is that Torque is an event driven application. From user input events, to timing events (physics ticks, scene refreshes), to, collision events, to network events, all of the TorqueScript you write should be with the perspective of "events are occurring within my simulation, how should I respond to them?".

The very concept of "stall reaction to reaching a particular line of code until a future period, then resume" is almost antithetical to an event driven simulation--in an event driven simulation, you want to react and respond to events provided to you, and if necessary store states that may modify/adjust how you react to future states--but you shouldn't in many cases try to take control of your objects for extended periods of time.

Finally, I want to re-iterate that having the ability to directly schedule is actually more powerful than only having the ability to "delay execution of a portion of a script function". If you prefer analogies, it's roughly parallel to having the choices when driving a car of "push the petal and (only) accelerate to full speed" vs "apply pressure to the pedal, and increase the fuel available to the engine to have smooth acceleration.

The first gives you two options: no speed, full speed, while the second allows you to do anything you wish (regarding speed at least) given an understanding of the system.

#14 Another thing to note is that Torque is not multi-threaded when processing script. If your function stalls for 500 milliseconds then *nothing* runs for that length of time. That means events and callbacks are being stacked up as your code sits twiddling it's thumbs.

When I need to delay in a function I just schedule another function and pass it the object. For example, in a platformer, bumping a block to shoot out a coin. The function shoots the coin and then schedule, with a delay, a function to fade the coin away. The coin pops out, hits it's peak and then fades out. Also, if a block has five coins I schedule their pop about 50 milliseconds apart. The first one is immediate and I add 50ms to each subsequent pop. And the pop call schedules the fade. What I get is five coins popping out one after another and they all fade one after another.

#15 Ok ok... i got it.
i guess its all a matter of redesignin some of the functions.

i was just lettin you know that if you let the schedule command to get outta control, the system will CRAWL in no time (it happened to me twice, but fixed it right away).. but with the given info, i guess its all a matter of thinkin in another way of implementin certain functions.

oh... and one thing, for me its pretty clear (even b4 you posted, Stephen), that you need to split up certain functions to make them mor readable and modular... aand i try to comply to that all the time... so, we're cool.

#16 Sorry for going OT even more, but this is what I do right now. I use a function that keeps scheduling itself, checking for commands that direct it's flow. So instead of "sleeping" my function waits for the next code to execute. The thing is, I need to move my character towards an enemy, stop at the enemy, play an attack animation, make a dramatic pause (or slow motion;), maybe a few particle effects, shake the screen, then move him back to his space. I don't think that's really possible without some sort of "timeline" going on behind the scenes..( is it?). It sure makes things easier for me, however inefficient it may be. This method works reasonably well for my turn based game, but if there is a better way to go about this I'd like to know.

EDIT: To clarify, my function does eventually stop scheduling itself at the end of the sequence of commands... it doesn't run the whole time the game is running.

#17 Well, once you get an hand of it, schedule is really better than wait for gameplay mechanics.
But there's one area where it's a nightmare : non-playable cutscenes. Where there's no events going, but only scheduled things, it quickly become a total mess.