Hello everyone, and sorry for the following wall of text! Also, forgive me if my english is flawed (and feel free to correct me!). It’s not my natural language, and I’m getting really sleepy right now
I’m kinda new to programming, game development, and the BGE, and I have a few questions:
Under the World panel, there’s the physics ticrate slider. In the BGE API, there are also the functions “logic.setLogicTicrate()” and “logic.setPhysicsTicrate()”. So, regarding all this…
I see this ticrate governs the maximum rendered FPS. So if I happen to have a 120Hz screen (which I don’t), I would have to up the ticrate accordingly. Why is this? Most commercial games seem to be able to render 120FPS just fine. Do they run at 120Hz ticrate? Am I doing something wrong and don’t actually have to up the ticrate?
What would happen if my logic took more than the ticrate time-frame? Would the game drop frames, or would it slow down? (I bet it’s the second one!)
If the game does slows down… I want my game to be able to run at 120FPS, in case someone happens to have a 120Hz screen. But 1/120 = 8.3ms. As I’m new to game development, I have no idea if that’s enough to run on most PCs.
How do you think I should handle this? Make the game always run at 120Hz, attempt to make it work at both 60Hz and 120Hz, lock it at 60Hz and leave those (not so) poor 120Hz screen owners with a game that’s capped to 60FPS? Would 240Hz also be acceptable, just in case? o.o (I don’t really believe 1/240=4.16ms would be enough, but lol)
What if the logic finishes on time, but the physics lag? Would the game drop frames, or slow down?
The slider on the GUI actually sets the LOGIC ticrate, right? I’m asking because I’ve studied lightly the Bullet manual, and it says that Bullet runs on a fixed ticrate (default is 50Hz), and the logic bricks run faster if I turn (slide?) this slider up.
So if I want do change the logic ticrate in-game, I should use “logic.setLogicTicrate()”. Am I right?
I was quite surprised when I saw there’s a “setCcdMode(int)” somewhere on the BGE API! Now… how do I use it?
How useful would this actually be? I’m assuming it can be quite a performance hog.
And this one is out of pure nerd curiosity: How does a raycast work? Does the engine actually trace a ray from source to target? That seems way too heavy, but I can’t think of another way
Thank you in advance, and sorry for the quite lengthy post!
The tic rate is the rate that the entire game runs at(assuming you have “use frame rate” ticked, otherwise, the framerate will be as high as your comp can manage). If the game itself only runs at 60 logic/physics cycles per second, then there’s no way for it to output 120 visual FPS. If your logic takes longer than the tic rate frame time, the whole game will slow down. However, if rendering, not logic, is the bottleneck, then the game won’t necessarily slow down(assuming you set the max physics and logic steps to a value higher than 1- I always use 5).
It should be easily possible to run a tic rate of 120 on an average PC, but you’d need to keep the logic and physics usage relatively light. You should probably handle it by setting the tic rate to 120. If someone doesn’t have a 120Hz monitor, the visual FPS will be capped at 60, but the tic rate should remain at 120.
If the logic finishes on time, but the physics lag, I think the whole game slows down. I might be wrong on this, but I think logic and physics are basically tied together (but then why would they have separate settings for Max steps? Hmm…).
I believe the slider controls the logic as well as the physics tic rate. I’m not sure about setting it via Python…
Now, I have no clue about CCD. I’ve never used it, never even knew it existed.
And yes, raycast does work by casting a ray. As far as performance goes, computing a ray intersection is almost nothing compared to doing collision detection between two polygonal meshes.
I bet you monitor refresh rate and your game FPS doesn’t sync.
And I bet your game won’t do each frame in exactly the same time difference.
Basically you get like
Frame 1: takes 5ms
Frame 2: takes 6ms
Frame 3: takes 4ms
…
Your monitor probably doesn’t care. It just refreshes the screen constantly and switches to the new buffer to show when it gets.
So you monitor has constant refresh of 8.3ms Every 8.3ms you see a new view.
What I’m saying: You won’t care for the Hz of the output device.
Normally you let your game run frame independent. Just when you get below 60FPS you try to improve to at least reach that goal. That rate is currently the value people feel smooth with.
If you want higher FPS you might wanna consider switching the engine because lots of optimization is still left here.
Most (non-casual) games don’t run at 120FPS. You can be glad if you get around 60FPS.
Or your hardware is just better the everyones.
The BGE runs linear. So yes, of anything needs more time to calculate something the other following things will have to wait. The frames go down. E.g. 1 logic calc , 3 physic calcs, 1 logic calc, 3 physic calcs, 1 logic calc, … –– straight linearity –– nothing parallel.
You could try multi-threading. At least some of your heavy time consuming scripts could work on another CPU and so wont decrease your FPS. Maybe.
Target a minimum FPS of 60 for smooth gameplay. On slow paced games e.g. puzzle, rts, tbs, …, you could even lower it e.g. around 30.
A FPS lock isn’t nice in games. There is VSync. Enable it to have a synchronization at about 60FPS. But don’t build games that depend on those 60FPS.
Don’t know how raycast is implemented here. But what you can do:
use the scenegraph to filter objects that are to far away
Thank you both for your answers, they were really helpful!
So I’ll try keeping the ticrate at 120Hz. I will make sure the scripts can be easily adapted to 60Hz, just in case.
About CCD physics, I’ve tried many different ints, and it seems to do nothing at all. I guess it doesn’t really do anything… and I can’t find anything when I search for Bullet-specific information
@@Urfoex
Wait, so I can multithread my scripts? I read somewhere that Blender would crash if I tried O.o
And about the FPS, I know I won’t usually care for the output device’s refresh rate. What I was asking was if using a higher ticrate was a nice idea, and how do most other games manage higher FPS. Because, as you said, I thought the framerate would be indepedant of the rest, since many other games allow huge FPS, yet the BGE is by default locked to 60FPS, because it’s default ticrate is 60Hz. Meh, I’ll figure it out, eventually…
Well, theoretically, multithreaded logic could be possible if you handle it entirely via Python (BGE has no built-in multithreading capabilities), but I don’t know if it would work in practice(BGE might crash, etc). And anyway, Python’s threading capabilities are inefficient due to the global interpreter lock (GIL), and the only way around this would be to call libraries of compiled c or c++ code from a Python script.
This is just a thought, but you may be able to use Cython to help you with that. Cython compiles Python down to C or C++, and I think Cython compiled scripts can run without the GIL, as long as they only operate on C types, not Python objects. But, see, now this is some really complicated stuff. Way over my head. Unless you’re a very experienced programmer, I wouldn’t recommend attempting multithreading.
Now, about the framerate, if you want the potential to go over 60fps, then you’ll need to up the tic rate as well. You can’t have a visual framerate that’s higher than the physics tic rate, it’s an impossibility. I think some game engines can actually dynamically up the physics tic rate when there are spare CPU cycles, allowing for unbounded frame rates, but with BGE, the tic rate is static by default, and altering it WILL change the speed of some things(which is unfortunate).
Very experienced programmer? I wish (really), but I’m currently a n00b, and I have no experience what-so-ever with parallel computing. I’ll still look that up, though.
And this probably doesn’t apply to the logic, but I’ve read on the Bullet manual that it’s meant to run at a constant ticrate (default and recommended is 50Hz), interpolating frames if higher framerates are needed. Not that it helps…
