Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Newcomers DBPro Corner / Troubleshooting framerates using Kumkie's 3D Benchmark

Author
Message
GeeBee
16
Years of Service
User Offline
Joined: 26th Aug 2008
Location:
Posted: 27th Aug 2008 01:09
Kumkie's 3D benchmark reports I can achieve 60fps with 89280 polys on screen, at 1280 x768 x 32 res. Tech specs are Core 2 Quad 2.4 ghz, NVidia 7050, 2048 Gb RAM using Vista.

My 13000 line game however only achieves approx 29 fps with 17998 polys, same res settings (see screenshot).

I have tried 'optimising' Vista using forum thread suggestions (disable indexing/fancy displays, force single core use etc).

I have tried 'optimising' my code (eg remove INK / LINE commands, use LoD to minimise model polys etc), but significant changes to framerate. If I remove much more my runtime code will be do...sync...loop !!!

My Question - are there any other obvious areas I should investigate that spring to mind? Or clever test methods to help pinpoint the actual problem or code chokepoints?

Design by Trial and eror...and errror...and errorr

Attachments

Login to view attachments
Nano brain
16
Years of Service
User Offline
Joined: 7th May 2008
Location:
Posted: 28th Aug 2008 14:52
Is Kumkie's benchmark simply a poly benchmark? If so, this could be the difference. Your game has more calculations on top of the polys, due to gameplay calculations.

I'm not sure what can be done to optimize your code...not without reading over it myself.
BlobVanDam
16
Years of Service
User Offline
Joined: 26th Jul 2008
Location: one of Cybertrons moons
Posted: 29th Aug 2008 15:11
Well without seeing the code it's impossible to be sure. I doubt it's the graphics at all. My program was 32,000 polys and has no problem keeping 60fps, but there are only 1100 lines of code to my program so far.
Try to figure out what section(s) of code is slowing it down, such as giant loops, or code being run when it doesn't need to be.
GeeBee
16
Years of Service
User Offline
Joined: 26th Aug 2008
Location:
Posted: 29th Aug 2008 19:54
NanoBrain/BlobVanDam

Thanks for your responses - I am investigating the gameplay calculations. The code is principally an adaptation (with permission), of Jason Sage's "Iron Infantry" source code which he released in Feb 08.

I have so far cut the code back to a 'skeleton' of just the terrain and dismounted player (ie removing other tanks/helis/AI etc) and this has helped significantly - so thanks for your suggestions.

If you choose to scan the original Iron Infantry code and spot anything obvious please let me know. In the meantime I will keep tinkering....

Design by Trial and eror...and errror...and errorr
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 30th Aug 2008 13:12
Hello Guess Who!

In the DBPro version of Iron Infantry, I too realized that SOMETHING was dogging my framerates when I added a few to many tanks/heli/infantry. Like you GeeBee, this frustrated me and I did try various things to speed it up and eventually came to the conclusion that the amount of processing that was going on to provide the "gameplay" and "physics" of the vehicles imparticular seemed to be the culprit. By limiting the number of tanks and vehicles.... I'd get a noticable increase in frame rates, and by adding more I'd lose those framerates.

One thing you might try (if I haven't got code in there for this yet) is to add a flag to a tank for example - that is the sum of all thats going on with it - that is simple - "NO MOVEMENT" flag. This would be set to true when the tank was going slowenough that you consider it "stopped"... you set this flag... then subsequent loops - you just check if new motion commands issued, if not - SKIP all the positioning, tread animation, "motion physics" math etc. This is only a SMALL "gain" however this kind of approach applied to "everything" will at least buy you some CPU however it will not be a static saving - the game will speed up or slowdown (from a Frame Rates point of view) depending on how much is going on at one time.

I tried using shaders at one point - these were a FPS killer! I also now have a better graphics card and might find that my other card was just not good enough - but I came to the conclusion that DarkBasicPro is not a monster for processing lots of code - but then - I'm not a perfect coder by any stretch and I might have bogged down the game using a certain math function to much or some other thing I never identified.

Regardless, this is why I switched to DarkGDK & C++ and I found that processing these kinds of things was perhaps more work to setup - ran faster.

As of late I have been swamped with my day job and my other coding efforts have been rendering 3d using directx directly because DarkBasic or DarkGDK do not render points... Well thats not true - I can get DarkBasic to render points using a shader - but that same code won't run in DarkGDK - so I went to pure DirectX as there is a rendring mode just for points - and using the DirectX indices for poly generation - well - its neat.. though other things are not so easy as in DarkBasicPro and DarkGDK.

In short - I think you will need to look for as many CPU process saving tricks you can to get the extra "oomph" from DarkBasic.

From your screen shot - it looks like you have done very well with that code base and I'm guessing you are learning a lot!

You CAN pull off a game in DarkBasic Pro and DarkGDK for that matter - you just have to constantly make tradeoffs between "looks" "gameply" and "Performance" which is true for ANY game you make using ANY "engine" or kit.

Keep up the good work!
Best Regards,
Jason P Sage

Login to post a reply

Server time is: 2024-09-27 20:27:36
Your offset time is: 2024-09-27 20:27:36