Skip to main content
GameDev.net gamedev.net
🔒 Locked

Performance issues with C++/CLI?

OpenGL
Started by xpnctoc Dec 30, 2006 at 10:19 PM 7 replies 1.4k views
Original Post
xpnctoc
xpnctoc
Hello, I read an article on another site about how to make an OpenGL interface in the C++/CLI environment. I'd really like to port an existing MFC-based game I am writing over to C++/CLI in order to use .NET to take advantage of the easier window menu and dialog box development. However, I seem to be having performance problems that I wonder if someone has encountered and/or knows how to fix. Here's my problem: The game involves a terrain mesh. The terrain algorithm is crude (brute force triangle strips with some modification for frustum culling), but my GeForce5900FX graphics card steadily cranks out 30-40 FPS even on such terrible technique. I ported over just the terrain portion of code to C++/CLI. Since the Application::Idle event in the managed environment is not the same as the Application::Idle process in MFC, I decided to use a Timer control, per the article I read. However, even with the timer interval set to 1ms, I am only getting about 5-10 FPS. Sure enough, if I cut down the dimensions of my terrain mesh to about 25% of its original size, I get the inverse 400% increase in performance, and back up to 40 FPS. So I guess my question is 3-fold: (1) Is C++/CLI, even with the "NativeWindow" class, really a viable method for high-speed games, (2) has anyone else experienced speed reduction problems when porting over their code, (3) does anyone have any suggestions for what I could be doing wrong? Thanks for your thoughts...
xpnctoc
xpnctoc
An update to my previous post... I'm wondering now if there is some greater problem with the Visual Studio 2005 compiler in general. I used the VS2005 environment to set up an MFC application, as the program I'm porting from is an MFC application in VS2003. So now I have an apples-to-apples comparison. But still the VS2005-compiled version is running distinctly slower.

My brute-force terrain algorithm is only drawing 6,100 triangles. I'm using a GeForce 5900FX card at 1280x1024 resolution. In the VS2003 application I'm getting 40-50 frames per sec. In the VS2005 application I'm getting 5-10 frames per sec. When graphics cards are measured in MILLIONS of triangles per second, 10 frames per second for 6,100 triangles just doesn't make sense.

Any ideas?
xpnctoc
xpnctoc
I found the issue. It's not anything about managed/unmanaged code. It's an IDE problem. On a whim I tried running the compiled EXE outside of the IDE and VOILA! The framerate jumped up to 40FPS. I re-ran the program in the IDE, and the rate was immediately back down to 4FPS.

So does anyone have any suggestions on IDE optimizations that would take care of this issue?
Spoonbender
Spoonbender
You were running it in the debugger?
xpnctoc
xpnctoc
Yes, when running in the IDE I'm running in full debug mode.
xpnctoc
xpnctoc
I'm already in /clr mode and not /clr:pure. I have to be as most of my data structures are unmanaged. However, someone on another forum did suggest that instead of using F5 to run, I should use Ctrl+F5 to run w/o debugging, and then use the "attach process" function to access my breakpoints. Seems like that would be kind of a pain in the butt, though.
Spoonbender
Spoonbender
Basically, running anything in the debugger is always slow. It may be slower under some circumstances than others (I haven't tested 2k5 vs 2k3, but it is possible that the 2k5 debugger slows you down more), but it's always slow.

So when you debug, you shouldn't worry about performance. And when you want to measure performance, you shouldn't run in the debugger (and you shouldn't run a debug build either)
xpnctoc
xpnctoc
No, I would never performance test in a debugger. But at 4 FPS, it becomes incredibly difficult to do any development/debugging.

Oddly enough, if I just build the project in debug mode, but then run the application directly outside of the IDE and use "Attach to Process" to intercept breakpoints, I get the full 40-50 FPS. It's only when using F5 to launch the app that I experience the slow-down.

It does definitely appear to be something that MS changed in the IDE between 2003 and 2005.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.