Hey there, I just had this idea and it’s probably terrible, but it seems like it would sure help me.
I complain 24/7 about the problem with logic and physics tics being reliant on the frame-rate of the engine, and have an idea for a workaround: as the title proclaims, “logic-based physics”. Basically, my idea is to use python to create really simple, fake physics (similar to that of a side-scroller or Pokemon games) that can always work at the same speed no matter the frame-rate.
However the idea may be simple, I am having trouble understanding how to do it. Since bullet is entirely disabled, I can’t use rays, nor are there collision bounds or and form of collision for that matter.
Gravity is easy enough:
from bge import logic, render
scene = logic.getCurrentScene()
def tic():
fps = logic.getAverageFrameRate()
fps = 1 if fps < 1 else fps
logic.tic = 1 / fps
def gravity(g):
for o in scene.objects:
if "g" in o == True:
o.worldPosition.z -= g * logic.tic
But then how on earth would I be able to do collision? In pixel-based engines, you can check the pixel next to the object to see if it will “collide” with the next pixel, however that isn’t possible with 3D application as far as I am aware, and would require using camera rays, therefore eliminating the point of simplicity and also reducing performance significantly.
2d.
Let’s say your physics bounds are circles (simplest).
Then you would check the distance to every obj, if one is too close, push away based on the distance vector.
But that is factorial complexity.
You would chunkifiy the world, like a checkerboard .
( if coordinates x,y = 29, 67 , then the chunk would be = ( 0, 2 ) if the chunk size is 32)
You would have to have every object registering in what chunk they are every frame to a dictionary.
That way you would only have to check the distance to every object in the 9 surrounding chunks.
Now imagine this in 3d and complex shapes.
This is where you realize, that maybe this isn’t the most rewarding idea.
^ I’d also like to know why you wish so much to unhinge the rendering frame rate; I think 60 should be okay for most people at the moment.
As to your actual issue, if you really want to do all physics yourself, go with Bullet, turn gravity off, and set objects you want to handle yourself to Ghost. You’ll still have raycasts and collision checking when you need it.
Ok yeah it seems pretty stupid now… Way too much work for little reward. Plus, doing all that calculation for every object through Python would lag heck a lot now that I think about it.
Thanks for the suggestions nonetheless
@SolarLune: The issue is that I despise playing with a 60fps lock (vsync) because of the weird additional latency it adds – it almost feels like a smoothing transition, which isn’t great for accuracy – especially noticeable with first person games. The second reason is that for anyone who is playing the game at 30fps, I don’t want the game to run at half the speed or have any variation simply due to a lag spike or something. If you try running a decently demanding Blender game on an APU or Intel Integrated graphics, you’ll see how frustrating it is playing a game where you move at the pace of a grandmother using a walker.
As to your suggestion, the problem there is that the physics engine would be running at the locked 60fps while game input is at a much higher frequency, still resulting in varying physics calculation.
Honestly, I think that’s just a super miniscule thing that few people notice. Like, unless you’re developing your game for a professional hardcore audience or an e-sports league, I think it’s safe to leave that out.
And to be kind of a jerk, if you ARE developing a game like that, Blender isn’t the engine you should be using. =P
True, however I have devices in the house incapable of running the simplest games at 60fps+ (like a single core celeron laptop from 2005 :no:). But for games that require to run at a steady pace in order to determine the difficulty, because of reaction times, it is really unfair for someone who wants to run at 144Hz to have to play the game at more than double the pace.
Program your game so that it is framerate independant. Instead of using 60 tics to mark off a second, use the time module. Instead of using applyForce, set the linear velocity based on the mass, time etc.
I’ve got a branch / patch that makes some heydays on this. It still doesn’t handle interpolating tender frames, which would be important when rendering slower than the simulation update rate
The bge is designed to run at the desired frame rate ad much as it can. It even skips rendering up to 4 frames to keep the fps.
If you have devices that still produce lags, you should either work on your game to reduce the processing time of a frame or exclude them from your target audience.
It makes nit much sense to run a game that has rwaktime physics, but you can’t see it because of the lags.
The synchronisation allows you to run your game with the same speed at any device. Nethertheless, there is a minimum requirement to meet. It is up to you what it is.
