PDA

View Full Version : Slowdown on certain videocards



Speeeder
12-04-2006, 06:49 PM
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
12-04-2006, 07:11 PM
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
12-04-2006, 07:30 PM
Suggestions, yeah...


Savage4, TNT2, GeForce2MXThese 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
12-04-2006, 08:51 PM
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
12-04-2006, 08:57 PM
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
12-04-2006, 09:03 PM
@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
12-04-2006, 09:15 PM
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
12-04-2006, 11:25 PM
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
13-04-2006, 12:51 PM
Can you post some code piece of heaviest drawing routine?

Speeeder
13-04-2006, 12:56 PM
Erm, nope, cuz that has nothing to do with my problem :)

Speeeder
13-04-2006, 07:41 PM
hhmm... In fullscreen, if I set 16 bit mode, the transparency craps up on a couple of places... :\ Guess it'll stay 24 window, 32 fullscreen then :P

czar
14-04-2006, 12:03 AM
DelphiX works best in 16 bit colour. Avoid 24bit colour at all costs and newer cards tend to work best in 32 bit colour.

I use fuschia as a transparent colour.

Quite easy to convert full colour pictures to 8 bit colour in photoshop without any pink edges.

Speeeder
14-04-2006, 12:42 AM
I use that as transparent as well and tell the crapped up transparency how that DelphiX works best in 16, not me :D 16 + FullScreen = nice fuchsia screen ^^

And no... I'm not THAT much of a lamer to blur the fuchsia into the images... btw, I'm using 256 paletted Length Encoded bitmaps mostly, they are so very good for all these transparented pics... Some are smaller than JPGs :)

Speeeder
14-04-2006, 12:51 AM
Talkin about all this bit depth thing... Could anyone tell me how the heck 16 and 32bit work exactly? I would think with an unknowing mind that 24bit would be RGB 1-1-1 bytes, but if that IS the fact, then how do 16 and 32 store the colours? Or is it 16/24/32 Bit per pixel? If so, then why is 16bit be a little edgy without dithering? (Or was it only cuz some older games were written crappily? :P)

czar
14-04-2006, 05:59 AM
One pixel requires 3 bytes of info for 24bit and 4 bytes for 32 bit i.e., RGB and one byte for alpha channel.

16 bit mode, 2 bytes are used to store the RGB values i.e. 5,5 and 6 bits for each colour. I think green takes 6 bits, someone else can fill that in if it ain't right.


@speeder

When you convert to 8 bit pallete do you force primary colours?

If you do not the fuschia may not infact not be fuschia in which case it won't function as the transparent colour. I used photoshop and when I convert to 256 colour mode I ensure the primary colours are present. I also only "paint" the fuschia into my graphic after I convert to 8 bit colour.

Speeeder
14-04-2006, 11:11 AM
ermm... I told you it works in 32bit mode, so errrmm... I guess that the pic is pretty good :)
Btw, Paint Shop Pro has a VERY good bitdepth decrementor filter thingy... It can do WONDERS in 256 colours and it preserves the colour of everything that takes quite much space in the pic... In oher words, it nicely dithers the slight colour gradients, but preserves the bigger parts perfectly... Give it a try one maybe :)
An thanks about that thingy with bitdepths... Even tho I wonder that if what you said about 32bit mode then you could as well make the primary surface transparent? (well, if it has an alpha channel.... :P)

czar
14-04-2006, 07:04 PM
@speeder

That is my whole point, your picture is not pretty good - it can be fine in 32bit but not fine in 16 bit. Unless the fuschia that you think is there is exactly the right RGB value.

Do a get pixel of a fuschia area while in 16bit colour and my guess would be it will not be $ff00ff.

I have implemented hundreds of different delphix programs across a huge array of hardware for over 7 years now. My suggestion is that you need to look for your problems in your own workings rather than trying to fault delphix.

Speeeder
14-04-2006, 07:53 PM
oohhh, I'm not faulting DelphiX, I never did... I think it's a very nice lil thing and I like it like hell! And well... How will a 256colour paletted bitmap with FF00FF get not FF00FF in 16bit? o_o Anyway, let's check...

Speeeder
16-04-2006, 09:01 PM
Did a pretty thorough test on a rig with Gef3 Ti 200 in it...
Tried in all combination of these modes:
16bit, 24bit, windowed, fullscreen, high quality (DrawAdds, DrawAlphas, DrawAlphaCols) and low quality (Draw and StretchDraw only).
The game displayed kindof normally, but the cpu usage went up, up, up!
The game could ran at around 16FPS :)
The video drivers were from march, so I guess those were pretty much new enough ^^
Aaaand yes I'm pretty sure it's something about the videocards :) I would think it's the stretchdraw part, buuut dunno what I messed up in my way of doing it so the Gef3 and older cards hate my prog such a bad way... :\
Ahhh, well, I guess I'll get a few ****you mails from Gef2MX users after I release the game :)
Oh, Czar, and I have to add, that the game more or less did the same way in windowed; fullscreen and 16bit; 32bit mode on the Gef3 and only got somewhat slower in "highquality" mode, so I guess why not 32bit in that case (Nicer blending hopefully ^^ Too bad my monitor is so crappy I can't really see the diff :P)

czar
16-04-2006, 09:27 PM
After using DelphiX for many years we have stepped over to Omega and DanJetX.

All those things you want to do can be done so much more easily with newer component sets. And more besides.

DelphiX has had its day.

Speeeder
16-04-2006, 09:50 PM
Well, I didn't know much about components like these when I've started this game, so I guess you can imagine that I won't go to any other, but oh well ^^

And I'm getting to understand DXDraws too! Now I'm putting in the missing DirectDrawSurface functions... (tsk, tsk, ijcro for forgetting those :))