Original Post
Update (3/13) - Problem Solved ______________________________________ This was a bad mistake on my part not related to DirectDraw. I had been writing to a file (using ofstream) each frame, debug information for during development that I ought to have taken out. Still, it had no negative effect on most computers; with a pretty full hard drive, though, my friend's computer apparently slowed down a lot with significant disk access. I'm leaving the original post unedited in case anyone else has similar problems; then, perhaps they can see that even if it seems like it's the graphics or something, they'll realize it could be anything else too. ______________________________________ This is a weird situation I have. I have two applications, both of which use DirectDraw, both of which are in 800x600x16 resolution at the same monitor's refresh rate. So, settings-wise, they are the same. They're both based on tile engines. #1 has 40x30 tiles (16*16 each), and #2 has 26x18 tiles (32*32 each). The point I'm making is that in almost every way, the applications are the same. The Main Differences #1 is a full fledged game. It included libraries for Winsock, Wininet, and ShellAPI in addition to your typical libraries. #2 is a simple platformer that does not originally include these libraries. Now, here's the problem. On almost every machine game #1 is played on, everything works great. It gets 75FPS and everything is great. (It's a simple application that would probably perform beautifully on our old 400.) However, a friend of mine has a computer that does not game #1 very well. He gets about 30FPS, far below the desired rate. When he runs game #2, however, he gets the desired frame rate (75 FPS). His video card is a GeForce FX 5200. I read in a couple places that some nVidia drivers can really hurt DirectDraw performance, but he has tried a couple of older drivers that have not changed the performance. (It is conceivable that if he tried 10 others, 1 of them could work, you never know.) However, if it's a driver problem, then I would expect game #2 to also suffer in its frame rate. As I stated, however, it shows no slowdown effects; it runs at a fine framerate. Here are some things I have tried to fix this situation: Recompile Game #2 to link to the Winsock, Wininet and ShellAPI libraries. This should any variable in which libraries they use. (No gain.) Comment out every line of code except the frame rate display, clear backbuffer, draw FPS on screen, and flip. (Gained maybe 3FPS, so 33FPS in the end.) Explicitly call surfaces to be created in video memory (along with primary surface and backbuffer). I really thought this would work. (No gain.) Remove joystick support from Game #1 completely. (No gain.) Disable audio in Game #1. (Game #2 has no audio, I didn't mention that.) (No gain.) I simply cannot think of what to try next. Game #1, while running poorly on his main computer, does run just fine on his alternate, at-home computer. I would really appreciate any suggestions you can offer me. Edit (3/13 @ 1:05 P.M.) - I dug out our old p2 400 (16 MB gfx card, TnT2 or something I think) to test the game, and it does indeed run fine (75 FPS). [Edited by - mikedoty on March 13, 2006 9:24:24 PM]