30 or 60 fps ?
Community Forums/General Help/30 or 60 fps ?
| ||
| so I have been working on my physics engine's fluid engine for a while and I was wondering what people thought about frames per second for a physics game based around fluid dynamics. I can get about 2200 particles at 60 fps but I need a LOT more... like 5000 which I can run at 30 fps but is that too slow for a game? I have changed all of the properties so it behaves the same at 30 fps but does 30 fps ever look to slow to yall? should I shoot for 60 fps or is 30 fps fine for a cpu intensive physics game? |
| ||
| Depends on the type of game, really - 30fps is fine for some, but may appear a bit choppy ofor others, depending on how fast/dynamic the game itself is. |
| ||
| Also bear in mind the pc your testing the game on. A game running at 30fps on my home gaming pc would really crawl on the pc at work. |
| ||
| Physics frames or video frames? 30 physics frames is probably plenty for something involving relatively low velocities - like fluids - but 30 video frames per second is pretty jarring. |
| ||
| well I dont have any kind of frame tweening yet for my physics engine so if I run the physics at 30 fps then I should run the screen at 30 fps... and I dont think 30fps looks jerky really for fluids... take a look at this... http://www.blitzbasic.com/Community/posts.php?topic=86037 thats all 30 fps and really smooth too @gabriel, its not a fast action game, its basicly a slow mo fluid physics strategy game so it shouldnt be too jarring like say a raceing game would be at 30 fps |
| ||
| I've been using 30 logic fps for loads of things and providing you use render tweening to smooth the framerate update out it looks just as good as 60fps. |
| ||
| As long as you can manage to keep 30 fps "all time" on "every machine", you should be fine. |
| ||
| That's the problem. You can't. There is too much diversity in GFX cards, CPU's, memory amount, etc... The best thing you can do is make your engine scale-able, and create some basic settings the user can modify to suit their machine. I don't think it works the other way around. |
| ||
| so are yall saying there are gfx cards that will only go at 60 fps? hmm maybe ill have an option for 60 or 30 fps? that might change the physics around a bit though |
| ||
| so are yall saying there are gfx cards that will only go at 60 fps? No, they're saying you can't guarantee everything will keep up with 30. hmm maybe ill have an option for 60 or 30 fps? that might change the physics around a bit though If it does, you should fix it so that it doesn't. If you haven't already, you need to decouple logic from rendering so that you can have 30 logic updates per second without affecting how many render updates per second you can/will have. Because Vorderman is right, 30 logic updates per second is plenty, but I don't want to be limited to 30 render updates if my graphics card could do 100. I'm sure you're right that a low velocity game like this is less noticeable than a racing game, but there are still a lot of people out there - like me - who dislike playing anything at less than 60 render updates per second. |
| ||
| My new game now updates as 120 hz and draws at 60... works great for an action game. |
| ||
| well wiebo, the problem is my physics engine cant run 120 hz with 5000 fluid particles flowing around :) so im thinking ill stick it at 30 fps for now and see how it turns out. when I get some kind of tween or delta timing built in, ill make it 60 fps |
| ||
| If it does, you should fix it so that it doesn't. If you haven't already, you need to decouple logic from rendering so that you can have 30 logic updates per second without affecting how many render updates per second you can/will have. Because Vorderman is right, 30 logic updates per second is plenty, but I don't want to be limited to 30 render updates if my graphics card could do 100. How can you find out how many render updates your card can ideally do? |
| ||
| I understand you have some hefy updating to perform. If you can de-couple updates from drawing you can do neat things like update at 30hz, and draw at 60hz. The rest of your game can update at a different rate if you want to. How can you find out how many render updates your card can ideally do? I do it this way: create a timer and find out how many millisecs() a renderpass takes with all effect or objects present, and how much an update pass takes. You can then see if rendering fits within (1000/60) - update time. My game runs at 120hz and I have to make sure to fit it all into 8.33 millisecs(), and provide options to turn stuff off at rendertime for slower computers. |
| ||
| as I have said, I dont have time to decouple the logic at this stage... its due august 1st and decoupling logic would require me to alter my entire engine (which would leave me no time to write the game although I plan to decouple the logic whenever I get done with the compo) also it would be much less efficient rendering twice for every physics update with heavy fluid physics... ok did some speed tests 0 particles update time: 0 ms render time 0 ms 3100 particles update time: 25 ms render time 6 ms this last test puts me at 31 ms total... 33.3333 is the max allowed for a smooth 30 fps. so lets assume I succesfully split up the physics update and render 60 times a second instead... the update time each frame would be 12.5 and the render time would still be 6 which puts me over the 16.6666 ms update, 60 fps mark. in threaded mode using no threads the update time jumps to 60 something so I cant use threads atm because of the slow gc which imo should be replaced asap |
| ||
Nate, you need to separate your physics from the rendering. I mean run your logic at say 60 or 100 cycles a second and then just render at full speed or tween (tweening is smoother). Here's a typical setup:While Not KeyHit(1) <timing code> If ticks blah blah GameLogic(dt) Endif tween# = accumulator / dt GameRender(tween) Function GameLogic(dt#) xold = xpos yold = ypos xpos = xpos + xvel * dt ypos = ypos + yvel * dt End Function Function GameRender(tween#) Local nx# = xpos * tween + xold * (1.0 - tween) Local ny# = ypos * tween + yold * (1.0 - tween) DrawImage blah,nx,ny End Function Using this manner will also allow you to freeze time but it will still continue to draw objects (great for pausing the game). |
| ||
| @chroma - I thought you meant do physics 30 times a second and render 60 fps and no I cant do that... this game is too intensive to do that unfortunately... the physics take 26 ms to update 5-6 to render with a 1500 x 1200 map, the average map size so I cant run the physics faster than 30 times a second... ok well now that I know my physics engine isnt up to 60 fps for this game, it doesnt matter any more. |
| ||
| If you separate your logic from your rendering, as Chroma suggests, you can do each as often or infrequently as you wish. For something like liquids, you might even find you could reduce your logic frames - to 15 perhaps - and still get acceptable results by rendering more often and tweening to make it appear that you're running logic more often than you are. The point of separating them is to allow you to be flexible. Ok, you can't do 60 updates per second on your machine, but maybe someone with a faster processor can. Separate rendering from logic and you can let them configure it for themselves. It's all about making the best use of the resources of the machine you're running on. Well, that and making your life a lot easier. |
| ||
| Well, that and making your life a lot easier. I hate making my life easier. I want it to be as hard as possible! arg! (sarcasm) but anyway, the projects done and I will be adding render tweening soon... someday |
   |