Slowdown on certain videocards

[Speeeder]

Hi everyone...

This time, I'd like some ideas about why my prog could slow down AWFULLY when it's running under an older videocard. It has been tested on a GeForce2 MX machine with a dual 3.x GHz P4 CPU, and it couldn't even stay above 25FPS... On my 2GHz system with a Radeon 9700 I can't get it above 10% CPU even with the DirectShow decoded HE-AAC music on...

The cards I've tested it on and was crapped as hell: Savage4, TNT2, GeForce2MX

The cards I've tested it to work on: Radeon 9600, 9700, GeForce 4 4400, and some GeForce FX... 5600 I think...

Ideas, suggestions, anything?

[Huehnerschaender]

I think it depends on the game you are making. I can't say anything about it, but of course the older cards are MUCH slower than new ones. Depending on the techniques you are using, a falldown in FPS may be as normal as sugar is sweet.

[Robert Kosek]

Suggestions, yeah...

Savage4, TNT2, GeForce2MX

These are aged cards that don't support some newer methods, therefore the alternatives are slower and often switched to automatically by DX (I believe).

Also, video cards have only one "active" texture. So if you don't sort things by z-order and texture, you'll get signifigant slowdowns. Far more than you'll get from the sorting.

[Speeeder]

Huehnerschander: Not THIS slowdown... It dies even bcuz of simple Draw methods... Not to mention StretchDraw. And of course it can't even display any Alpha blended thing... But I have a switch to turn those off, so, point is that it just can't draw simple surfaces in normal speed.

Robert: I do know those don't support everything, but goodness, simple Draw-s? :\ Maybe the fact that I'm not only using surfaces with width/height of 64?ó128?ó256 and the like?
Z-order, sorting... sorry, I'm not experienced enough for that yet... And I'm talking about something 2D...

[Robert Kosek]

Yeah, because technically Z-Order sorting is just the draw order. If you're looking at the monitor it kinda looks like this, layer-wise.

+  |  +  
|  +  |   /|
|     |  / ----+
+  +  |  \ ----+
   |  +   \|
   +

Like the draw order of (top down) terrain, particles/projectiles, enemies/clouds, player... and so on.

Sort by the draw order and the texture name together, prior to drawing. That way you draw all enemies of the same image in the same "layer" all at once, rather than just doing it inefficiently.

[czar]

@Speeder

We found in the past that some video hardware runs delphix programs really badly (mainly older nvidia cards) - however a change of driver fixed the problems.

We have literally hundreds of different delphix programs running on hunbdreds of computers around the world from pentium 233 and up. So my suggestion check driver issues first.

Are you using the newer hardware accelerated delphix? or the std original version?

[Huehnerschaender]

First, I think the bitdepth can be a problem. Are you using A8R8G8B8? I think this can be a little insufficient on older cards. Try to use a lower bitdepth for your textures.

And yes, it is always a good advice to use textures sized power of 2!

256*256 is the fastest and you can tile it in several patterns if needed (for animations or backgroundtiles. But don't use graphics which are stored in size like 800*600 or 100*123.

The Z-Order thing is another point you should take a look on. The order you are drawing things can extremely slow down (or speed up) rendering.

Other things you could take a look at are:
- Screen resolution (older cards are faster at lower resolutions)
- Are you using Antialiasing? Is this supported by the hardware?
- blending with alphachannel is hardware intensive work for the video card. The more you use it, the slower rendering will be. Try to avoid it where it is possible
- Every DirectX functionality you are using, which is not supported by the hardware will be executed in some kind of software emulation which slows down everything. Take a closer look at your drawing routines.

Can you provide a screenshot so that I can imagine of what "complexity" your renderings are?

And finally: Why are you using DelphiX instead of Asphyre eXtreme?

[Speeeder]

Robert: thanks for telling me the idea of that... I won't modify my prog to be like that, but it sure is a nice idea that I'll try and use in later projects...
Czar: okay, I'll ask my friend with the Gef2MX about drivers, but I don't think he'd have an older driver...
huehnerschaender: My program is totally customizable from inifiles and a script language... I just cannot tell users to use just use those resolutions... And I can't make every picture such a size, cuz it'd be a HUGE amount more in used space...
I'm using 32bit, so I guess that I could give 16bit a shot...
Resolution is fixed 800?ó600 and I like it like that...
No anti-aliasing, cuz I don't even know how to use that ^^. Like I said I'm a starter DirectXer, but a lil tut on that would come nicely...
Again, like I said, the proggy kills the CPU totally even with some stretchdraw parts aside from the fact that it did a highly crapped drawing as well... The alpha parts weren't even anywhere in question... And I've added a low/high quality mode anyway, for the alpha and additive drawing parts...
I know that it does software, but for ****'s sake ON A DUAL P4 3+ GHz computer!!! Unbelievable... I think the vidcard is stealing off the time there or alternative, the time is lost somewhere in memory transfers... Or maybe the card thinks it can do that some kinda drawing while it cannot for some reason or whatever... o_O
Complexity... From about simple drawing to pretty nice graphics... My problem is that the Gef2MX and those older things totally died while trying the simplest drawings... All other rigs I've tried my prog on ran it cleanly at the highest quality... With minimal CPU usage... (Yes, windows timer, and I do know it's not pretty, but I felt that it's better for my prog...)

[User137]

Can you post some code piece of heaviest drawing routine?

[Speeeder]

Erm, nope, cuz that has nothing to do with my problem