|
Portability And Performance Question submitted by (18 November 1999)  |
Return to The Archives |
 |
 |
|
|
Years ago, I started coding 3d stuff with DirectX 2.0, using my own 3D engine.
DirectX 3.0 came out and I quickly learned RM mode.
Currently, at work, I'm required to write 3D code for 98, NT and Linux.
I use Mesa for the portability, but unless I use the Voodoo chip set, I get pretty lousy performance.
If I port my Mesa apps to use OpenGL l under NT or 98, I also get lousy performance.
I've written a few apps, that use glide, it's fast, but being so tied to the Voodoo chips set, it not a valid option.
Recently, I've started using DirectX 6.0/7.0 IM mode, I get great performance, but, of course, I'm not compatable w/ Linux or NT. This is what I'd like: I can use Mesa w/ 3dfx support for Linux ( I can dictate the video cards under Linux). I'd like to be able to easily port the code to NT/98 and have it work fast. ( with hardware support) What's a guy to do? |
||
 |
 |
 |
|
|
|
Considering the fact that you want portability, OpenGL seems to be the
best choice. It also sounds like you already have working OpenGL/Mesa
code so if it were me, I would certainly try to make this option work. I've got a VooDoo3 and a TNT2 in my home machine, and they both perform very similar under OpenGL. Read up on the OpenGL drivers you're using under Windows. Make sure you're using the hardware accelerated versions. This may sound silly to say out loud, but I've been caught in this trap a few times. For example, NVidia's TNT1 OpenGL drivers didn't use hardware acceleration unless you were in 16-bit mode. If your performance isn't THAT lousy (i.e. your definition of 'lousy' is 10% slower rather than 2000% slower) then start doing some profiles. You may find that you're doing something incorrectly. For example, you might not be initializing something properly, which doesn't affect the performance of one card, but does affect the performance of another. It might be that the incorrect initialization dosn't affect the Mesa performance, but does affect the OpenGL performance. Take certain things out of the equation (i.e. render without textures) to try to narrow in on the culprit. Are you using the OpenGL texture caching? Remember that it's up to the particular OpenGL driver developer as to how the memory is managed. Poor management could make the difference between 30FPS and 4FPS (I've seen this for myself.) If so, a possible option is to write your own texture caching algorithm (they're not difficult, and it would help you get more consistent performance across multiple platforms.) The point is, you can't fix something unless you know what's broken. So narrow down the what's causing the bottleneck and fix it. Every problem has a solution. Response provided by Paul Nettle |
||
|
|
|
This article was originally an entry in flipCode's Fountain of Knowledge, an open Question and Answer column that no longer exists. |