this is what i understand of the BGE so far: (please tell me if I have it wrong)
the game engine runs per defauld 60 logic tics per second and in every “tic” it waits till all the bricks and scripts are executed before it goes to the next “tic”.
my question is: can you change this for a given script so the script has more time to be executed?
for example: if you want that your script runs 10 times a second. and your script starts in the first “tic” it only slows down the engine if the script isn`t done in the sixth “tic”
Change the default “f:0” value in the sensor that triggers your script to “f:6”. Your script will run on every sixth logic tick.
60/6=10
That means your script will run 10 times every second.
thanks for the quick reply, but this was not the answer i was looking for
I did some test and got some strange result: I attached an always sensor and a mouse sensor to this script:
a = 1
while a != 1000000:
a += 1
with a trigger delay in the always sensor of 5 this runs smootly on my computer, but when i click my mouse the framerate drops to 30.
so the engine gives more time to scripts triggered by an always sensor with trigger delay, but not to a script triggered by an one time event like a mouse click.
maybe it has something to do by the fact that the mouse sensor let your script run twice (one True pulse and one False)?
how to solve this?
an other strange thing: when i detach the always sensor and set the mouse sensor to true level triggering with also a trigger delay of 5. holding the mousebutton gives an even worse framerate. this should give the same output as an always sensor right?
EDIT:
No the results can not be the same.
The “Always” sensor has 2 states ; 0 and 1. The script is triggered when state 0 changes to state 1.
The “Mouse” sensor, if used to detect a mouse click has 4 states ; 0,1,2,3.
0 - the sensor is not active
1 - the button is pressed
2 - you are holding the button
3 - the button is released
The script runs on state 1, then repeats on every tick while state 2 and then runs again on state 3.
The “f:” value sets a delay between button pressed (1) states.
mmm, let me reformulate my question:
atach an always sensor with True level triggering enabled to this script:
a = 1
while a != 1000000:
a += 1
without delay your framerate is very bad and when you make delay higher your framerate becomes better. but for me around a delay of 30 it doesn`t matter anymore and the framerate starts to shift between 60 and a lower value. looks like the engine has some kind of limit of how much tics can be used for a script. is there a way to change this limit? so you can run this script for example 1 time a second with a constant framerate of 60?
The frame rate is an average, so an abominably large logic step will skew the frame rate - such as iterating 100000 times. Whilst it appears to be a frame rate of 30, in your case, it is likely not really the case
As for setting the number of logic ticks per second, you don’t have that level of control, however you do have some control. In the world panel of blender 2.5 (make sure the render engine is set to blender game) there is a number control for how many logic steps per game frame (assuming the game can sustain a reasonable FPS with that value). So in regards to original question, yes you can run logic multiple times per game frame.
Yeno. The controller takes as much time as it needs. There is no break to make the BGE swithing to the next frame. It is up to the controller to stop processing. (Implementing an endless loop is not a good idea ;).)
If the over-all processing time for a frame is below 1/60s (that is reserved for the frame) the BGE waits until the 1/60s are exeeded before continuing the next frame.
If the frame’s processing time exceeds the 1/60s the frame rate drops. It does not matter why it exceeds the time limit. It can be anything in the game loop (logic, physics, render etc.).
Each triggered controller adds its processing time to the complete processing time:
If you trigger a slow controller, the frames processing time might exceed.
If you trigger a lot of controllers, the frames processing time .
You can influence the processing time by choosing reasonable configurations (for controllers):
trigger an controller only if required (see sensor settings)
exit an Python script/module as early as possible
avoid long loops
use actuators whenever possible (rather than Python controllers).
To answer your title question:
Yes, with multiple controllers.
In terms of performance - more processing time!
i don’t understand the synching between logic ticks and the actual render frame rate. won’t this cause jerks? if i do some animation with python for example and the logic ticks are 1/60th and the actual render frame rate is 1/75th or something like that?
You see it makes no sense to draw more pictures than the logic/physics can calculate ;). The output would just repeat the previous one.
In your example every 5th output image would be repeated to get 1/75 if it is rerendered. I doubt that this is done.
yes, but i don’t think i have any direct control over this? the render frame rate depends on a lot of things. so in some cases jerks or stuttering aren’t avoidable with the blender game engine?
i am not really getting this since in all other engines i worked with the script execution wasn’t coupled to physics but render frames.
Usually the rendering is the bottleneck. Which means if rendering is slow, the whole game slows down (including the logic and physics). If you drop a stone it would take longer (of real time) if the (rendering) frame rate is lower than expected. Playing with different speed is not that good for game play.
To avoid this effect in the BGE the physics and logic can run with the expected speed, while render is skipping frames. There is a limit. If the render is 5 times slower (default) logic and physics will wait for render.
This does not belong if the logic or physics are the bottleneck. In that case everything slows down.
thanks again for the replies, got a better idea of what`s going on now.
how would you guys implement for example a pathfinding script?
because that takes a lot of calculation to make a nice smooth path. probably more than the engine can handle in 1/60th of a second
and another idea: if you let a python script run next to your engine wich does the calculations for you will maybe not slow down the engine itself. the way i could see this happen for example is that the engine changes a text file and the python script sees the text file is changed, does some calculations and updates the text file. blender notice the changed file and opens it. opening and closing text files isn`t that good for the overal speed, is there an other way to cummunicate within the engine to other programs/scripts? (i know you can register a script but that way the engine will still wait for it to be executed before going along)
You can make pathfinding that it takes not that long, it depends a lot on the model the pathfinding is working on.
And you do not need to find a path all the time.
I would say pathfinding is a good candidate to run in a thread.
You can also split the processing in parts, that the calculation is limited for a period of time. If it couldn’t finish the processing contiinues with the following frame(s). There was a thread some weeks ago.
Logic and physics will usually (when they can do so without causing too much frame loss) run multiple times per render frame. You can set the number of times to run per render frame in the world panel on blender 2.5, just make sure the render engine is set to blender game.
Computer processors are serial, meaning they can only manage one thing at time. To solve this, a processor is broken down into processes. Each couple of milliseconds a new process is give some processor power, allowing you to run multiple programs. In the same sense a process can be broken into threads and each thread in the process is given some cpu time allowing you to essentially run two different bits of code along side of each other. You can google python threads, to find out how to set up threads in python, or threads in general for a better explanation of what they are.
"looks like the engine has some kind of limit of how much tics can be used for a script. "
Are you aware that there are allowed a certain number of “logic tics” per “game tic”. You see that next to “fps” it has “log” which “sets the maximum number of logic frame per game frame if graphics slows down the game…”.
This might have something to do with what you are try to find out.
In the world panel of blender 2.5 (make sure the render engine is set to blender game) there is a number control for how many logic steps per game frame (assuming the game can sustain a reasonable FPS with that value).
after reading this i think it works like that:
the physics engine needs at least 60 steps per second, otherwise the simulation gets unstable.
so if the render frame rate (i guess this is what gets called game frame rate in blender?) is over 60 fps then there will only be one physics/logic step per frame. if the frame rate is under 60 then there will be physics/logic substeps up to the setting “max”, so that at least 60 physics steps per second will be reached.
could this be the case? this would make sense to me since this way there wouldn’t be synching problems / jerks / stuttering. the only problem is very low frame rates but then the game isn’t very playable anyway.
If there were one physics time step per game frame, then time would slow down if the game engine couldn’t crank out the set number of game frames per second (60). Hence you can set it to allow more than one physics timestep per gameframe.
The physics is what decides whether it appears in slow motion or not – the game fames per sec is only nominal (i.e in practice your script might slow it to less than 60).
To get time passing at the right rate, you could try to set one logic timestep and physics timestep per game step, and bake the physics to ipo, and the play it outside the game engine at 60 frames per second.
You can see from all of the BGE videos on youtube, that blender can’t get time passing at the right rate in the game engine, because they all seem to be in slow motion.