hello again,
i've noticed that my small zge-creations run at an absurdly high framerate (framecounter counts ~1300 fps), probably as fast as they can, and hug 50% of my cpus processing power (the other half is only safe because of single-thread-on-double-core-issues, i guess). it would be nice to be able and set an upper limit to how fast they try to go. my laptop is threatening to melt, really ;)
is there a sensible way to limit the framerate inside zge (apart from forcing the graphics card to vsync or running fullscreen)? i can't seem to find any options/expressions dealing with the render engine on that level ...
How to limit the framerate?
Moderator: Moderators
Hi,
There is no such feature at the moment but I agree that it is a problem and that it should be fixed. A "LimitFrameRateToVSync" checkbox on the App object perhaps.
It runs full speed right now which is useful when testing out performance to see if your framerate drops, but not really necessary in most cases. And yes you get 50% because of dual core. The audio-synth runs in separate thread but does usually do not take much cpu-time. I also use a laptop so I'm aware of the melting-problem
We'll look into this. Meanwhile your best option is to force vsync in you graphics driver as you suggest.
/Ville
There is no such feature at the moment but I agree that it is a problem and that it should be fixed. A "LimitFrameRateToVSync" checkbox on the App object perhaps.
It runs full speed right now which is useful when testing out performance to see if your framerate drops, but not really necessary in most cases. And yes you get 50% because of dual core. The audio-synth runs in separate thread but does usually do not take much cpu-time. I also use a laptop so I'm aware of the melting-problem
We'll look into this. Meanwhile your best option is to force vsync in you graphics driver as you suggest.
/Ville
another thought i had: instead of syncing the framerate to the monitors refresh rate, it could be cool to specify a 'max framerate' - if, for example, there are some collision detections running which would be nice to update more often than 60 times per second, but less than 1300 times ...
even cooler would be the feature to decouple the OnUpdate-intervals from the OnRender-intervals, so that rendering only occurs at the vertical refresh rate, while updating is done as fast as specified in 'max framerate' ...
i understand that this must be quite challenging; but this is just loud thinking - i really don't have any 'use case' in mind for this :)
even cooler would be the feature to decouple the OnUpdate-intervals from the OnRender-intervals, so that rendering only occurs at the vertical refresh rate, while updating is done as fast as specified in 'max framerate' ...
i understand that this must be quite challenging; but this is just loud thinking - i really don't have any 'use case' in mind for this :)
Hi diki,
Even though you're only mentioning the collision situation merely as example, step based physics and collision checking is outdated and concidered bad practice in most cases. Developers these days extrude the bounding mesh of a object over the velocity direction vector with a extend of the velocity, and use that mesh for collisions checking. Then on true, the polygon level routines are then executed.
I've attached is a image representing a spherical bounding object starting at position -6 travelling at 2 units per interval. Using step based collisions the ball could just fly through the vertical white wall, while this is never possible when using extruded bounding objects.
Anyway, just for your information
K
Even though you're only mentioning the collision situation merely as example, step based physics and collision checking is outdated and concidered bad practice in most cases. Developers these days extrude the bounding mesh of a object over the velocity direction vector with a extend of the velocity, and use that mesh for collisions checking. Then on true, the polygon level routines are then executed.
I've attached is a image representing a spherical bounding object starting at position -6 travelling at 2 units per interval. Using step based collisions the ball could just fly through the vertical white wall, while this is never possible when using extruded bounding objects.
Anyway, just for your information
K
- Attachments
-
- Collision.gif (3.75 KiB) Viewed 9028 times
-
jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
ha,. that is neet Kjell! looks like a great idea for lots of uses,. have you figured and simple way to implement something like that in ZGE? I would be interested for sure.
diki - welcome,. I look forward to seeing what you come up with,. ZGE is a fun system and produces some fine results,. if you are flexible and able to work with the components and find creative ways to use them,. my biggest hurdle has also been with the update speed,. trying to get the alphaTime maths to work,. as on my machine I can not get ZGE to go over 60fps I have trouble testing this,. a limiter would likely help here,. although i still need to get that math for the slower situations..,
peace.
diki - welcome,. I look forward to seeing what you come up with,. ZGE is a fun system and produces some fine results,. if you are flexible and able to work with the components and find creative ways to use them,. my biggest hurdle has also been with the update speed,. trying to get the alphaTime maths to work,. as on my machine I can not get ZGE to go over 60fps I have trouble testing this,. a limiter would likely help here,. although i still need to get that math for the slower situations..,
peace.
iterationGAMES.com
Hej jph,
Well, no .. there is no easy way at the moment. Apart from when you're using Rect2D_OBB, then you can just use the scale properties and CollisionOffset to extend the collision box while countering the rendered scale using a RenderTransform. Problem is that with these kind of collision checks you really want to follow up with some Raycasts or Polygon style collisions ..
And after the much needed Box3D_OBB, Sphere3D_OBB, Cylinder3D_OBB, Cone3D_OBB and Mesh* style collisions have arrived, it would be nice to have some EBB variants ( Rect2D_EBB, Box3D_EBB, Capsule3D_EBB ) that use the Model Velocity properties to dynamically generate extruded bounding objects / frustums / boxes.
*Ville: You probably want to use Box3D_OBB/EBB internally first to check if there's collision with the bounding object at least, before iterating through all the triangles of a mesh.
K
Well, no .. there is no easy way at the moment. Apart from when you're using Rect2D_OBB, then you can just use the scale properties and CollisionOffset to extend the collision box while countering the rendered scale using a RenderTransform. Problem is that with these kind of collision checks you really want to follow up with some Raycasts or Polygon style collisions ..
And after the much needed Box3D_OBB, Sphere3D_OBB, Cylinder3D_OBB, Cone3D_OBB and Mesh* style collisions have arrived, it would be nice to have some EBB variants ( Rect2D_EBB, Box3D_EBB, Capsule3D_EBB ) that use the Model Velocity properties to dynamically generate extruded bounding objects / frustums / boxes.
*Ville: You probably want to use Box3D_OBB/EBB internally first to check if there's collision with the bounding object at least, before iterating through all the triangles of a mesh.
K
hi kjell, thanks for the info! i knew that there was some extrapolation on time going on with current collision detection, but i was unaware of the bounding box extrusion trick :)
jph: i'll see what i can do; you set the bar pretty high ;) but it's always fun to try new systems (been working with vvvv for a while, which is in some ways related).
jph: i'll see what i can do; you set the bar pretty high ;) but it's always fun to try new systems (been working with vvvv for a while, which is in some ways related).