Performance Test I

To get an overview how good GG is running on the different systems, we should test the performance on different systems. Many users, many systems. It should be not a contest/competition who has the best PC, it should be an overview how your game maybe will run on a different machine...

Test settings:

Start GG
Start the test mode (empty map), not move the mouse, press TAB and wait a few sec. Then write down the framerate you had on this empty map.

And post the result here.

CPU: i5 4690k
Graphic card: GTX 970 4GB
Frames: 388

Writing from my tablet, have to edit the post tonight....

Maybe it could help all of us.

218 FPS
Machine specs below in sig.

Good, now we have 2 results.
Not much results so far, but ok

Intel® Core™ i7-4820K, 3,7 GHz (3,9 GHz Turbo Boost)
Graphic card: GTX 970 4GB
windows7 64

505 fps that's really much, I hope when I release my game all people have a i7 hahaha

FPS=272 specs below

24 FPS :/

not sure what happened in the last couple GG versions but i think my performance has actually gone down.

flat terrain and entity and terrain shaders set to medium.

64 FPS

If i turn off bloom, lightrays, water reflection, shadows... also if i turn the shaders to lowest istill get only 64 FPS... strange.

specs are in my signature below. As you can see my video card is quite old.

Your test of checking the FPS in the editor with a blank map is not accurate.
Editor mode does not use any GPU ram and is running in software mode.
Check the task manager and you will see.
You are not using Hardware mode until you are in game mode.
The little green bar in the editor shows GPU ram used and is not accurate until you
run the map once in game mode.

Frames per second is a very misunderstood topic.
First you need the vsync mode set to the refresh of the monitor.
The FPS needs to locked at this which is usually 60FPS.
The physics needs to timed to the visual representation which will not be accurate beyond 60 FPS.
If you would like to learn more about why FPS are not an accurate way to gauge performance read this article.

http://www.mvps.org/directx/articles/fps_versus_frame_time.htm

Ok, then it's only the power of the CPU.
But I think this test can be helpful for some people, to see how their CPU would work with GG .
Or to see how the game they've made would run on lower spec machines.

It depends on what you're trying to measure - physics computing time remains constant over different levels of graphics settings.

If you're just running a performance test on an empty level you'll be measuring the average basic loop processing time rather than rendering/ai/physics performance.



Not sure what you mean by this but hardware rendering will be used in both cases. Software rendering is horrendously slow and isn't even supported in DBPro for that matter.

This is why I said FPS is a very misunderstood topic.
Since I wrote the some of the physics code that is used in GG, I have a better understanding of what is happening. (Check the credits)
For the physics to stay in sync with the visual representation the frame rates should not exceed 60 FPS which is the Vsync
rate of most monitors. Anything above 30 frames per second is good and will not be caught by the human eye.
Anything over 60 FPS is pointless and a waste of processing that can be used elsewhere.
Also Vsync prevents video tearing which you would not want your customers to experience while playing your game.
All game engines use timer based movement to keep everything smooth which is defeated by allowing the rendering to run wild.
I would not judge GG by what DBPro can do as Lee is using a highly modified version.
If you check the task manager while GG is in editor mode you will see it uses no GPU ram.
So in editor mode this would not be an accurate test of the GPU. It would also not be a benchmark of how well a game would run.
No game engine is ever judge for performance while running in an editor why would you want to hold GG to that standard.
This is a basic design principle of game engine programming to limit FPS and have a smooth performance.

Thanks for the detailed reply, although I'm confused by a couple of points:



Not sure I understand what you're saying here since the whole point of timer-based movement is that it's completely independent of frame rate - so movement will be the same regardless of whether the game is horribly lagging or running at 200fps. Or are we talking about different things?



I have a good article bookmarked that shows how and why the human eye can actually see far above this:

http://www.100fps.com/how_many_frames_can_humans_see.htm



Yeah that's true. It wouldn't be an accurate representation of how the game itself runs; only how it runs in the editor (which may or may not be desired).

EDIT: Also, regarding vsync, be careful not to use it if the performance is poor - the game will run even slower due having to wait to render.

It is not completely independent of frame rate. It is adjusted based on the frame rate to keep the physics in sync.
The physics code will have a range limitation where it works best say between 30 and 60 FPS.
I am telling you from experience since I wrote the code.

If you look at my youtube channel you may understand better my experience with physics code and DBPro.

It should be. Wild variations in frame rate might cause some oddities, but a constant 200fps should give the same results as 30fps if implemented properly.



You should use the timed step-based iterative approach that most commercial engines have; every so many milliseconds (16ms for example) the physics routine is run for a fixed time step, which is then repeated if necessary to make up the total time elapsed since last time. It works very well in both extremes of frame rates.

Many competitive gamers run the game at as high a refresh rate as possible for reduced input latency, and if the physics system were badly implemented in these games they'd have a very bad time!

Would you care to elaborate on your experience writing physics code with a little proof.
What you are doing is spouting nonsense just to contradict what I am explaining.

If you could tell me what part of my post is "nonsense" maybe I can elaborate for you. It's established science, used across most if not all modern game engines. And, please be civil with your response.

Gammers believe that they need to run a game as fast as it can go, programmers know better.
You are claiming that modern game engines allow the end user to just run the game flat out as fast
as it can go and that is not true. Could you provide an example of one that does what you claim.

I have a very extensive knowledge of DBPro and the physics used by GG and have provided proof.
Grabbing info from questionable websites does not mean its established science.
You are proving my point that FPS is a VERY misunderstood subject.
Did you read the MICROSOFT link I posted above?

Alright guys let's settle down a bit. No need to get into an argument here.

Unity (uncapped fps, framerate-independent physics)

Unreal Engine 4 (uncapped fps, framerate-independent physics)

CryEngine (uncapped fps, framerate-independent physics)

Some of the games that run on these engines do limit their frame rate by default, but the important thing is that the physics logic is decoupled from the rendering, so a higher frame rate won't produce any issues.

See here for an example of how to properly implement timer-based movement in DBPro. For implementing physics, you should use a fixed/semi-fixed time step as described here.

Hope it helps.

If you actually believe this then there is no helping you.
I guess if you actually knew how to program a game engine you would have and would not be using GG.

Rather than arrogantly denying anything I say and throwing around insults, perhaps you could provide a rebuttal instead. Judging by the fact that you haven't yet, I'm going to guess that you can't. In which case this discussion is over. I just hope Lee reads this thread and strips your broken code out of the engine, replacing it with something that works.

Good day.

Since you profile shows you have only ever posted in GEEK CULTURE your comments
have no credibility. Since you are not a programmer you would not understand, but its not your fault
you just do not have the education. I suggest take a programming course.

I am now locking this thread. I think you have both said your part.

The thread is no longer productive.

Cheers

Jay.