Archived

This topic is now archived and is closed to further replies.

Incommunicado

Radeons and D3D8

Recommended Posts

Hi folks! I recently implemented my own little shader language with several codepaths for the nvidia chipsets. Now i wanted to implement further paths for ATIs radeon series, especially the 8500. The only problem is that i can''t find the D3D8 Vendor and chipset id. NVidia posted these on their web page, ATI did not. Can anybody give me these hex-codes especially for ATI Radeon8500. Many thanks in advance and Happy coding Incommunicado

Share this post


Link to post
Share on other sites
It''s probably better to check the caps of the card and write a separate code path for each relevant area you wish to implement. Why? Well you write your code which works perfectly on GF1,2,3,4 and ATI Radeon 7500/8500/9000 and everything is perfect. BUT THEN Nvidia releases GF5. Suddenly your code doesnt recognize the card and has to default to a "safe" mode and all the lovely features are ignored. BAD.

Neil

WHATCHA GONNA DO WHEN THE LARGEST ARMS IN THE WORLD RUN WILD ON YOU?!?!

Share this post


Link to post
Share on other sites
Hi again.
First of all thanks for the replies.
I do not have a Radeon at home so i cannot check the id at home, and i do not know someone with a card of that type either. ATIs developer site does not seem to offer much info and since i only got a crappy 33.6kbit modem i cannot download the larger demos and sources they offer.

To Neil:
Actually my own Highlevel shader language allows to code paths for various cards which might need various rendering passes. If you hardcode paths for several caps then your code will grow immensely. I know what im talking about since i tried this one out. I am also aware that futurecards will need support therefore my engine checks upon initialization the caps of any UNKNOWN card and tries to find the best next compatible card that is supported natively. To be more precise. If NV puts out their new NV30 it will run the most advanced pass it can find in the HL-shadercode.
For example:
GF4Ti can run GF4Ti, GF3, GF2, DEFAULT codepath
Radeon9700 can run Radeon8500, GF4Ti, GF2, DEFAULT codepath
etc.

Happy coding
Incommunicado

Share this post


Link to post
Share on other sites
Reported for ATI Radeon 8500DV:

Driver ................ ati2dvag.dll
Description ........... ALL-IN-WONDER RADEON 8500DV
DriverVersion ......... 393229661454
VendorId .............. 0x00001002
DeviceId .............. 0x00004242
SubSysId .............. 0x02aa1002
Revision .............. 0
DeviceIdentifier ...... {D7B71EE2-0102-11CF-7C64-A022A2C2CB35}
WHQLLevel ............. 1



[edited by - don on July 30, 2002 11:26:02 PM]

Share this post


Link to post
Share on other sites
Fair enough. Just thought that it might be one way around your predicament. Hope everything works out OK. Good luck.

Neil

WHATCHA GONNA DO WHEN THE LARGEST ARMS IN THE WORLD RUN WILD ON YOU?!?!

Share this post


Link to post
Share on other sites

It would be better to query for capabilities (vertex shader versions etc) than to hard-code device IDs. What happens if a new card comes out that you don''t have access to, and I run your game on it? Even though it may beat the Geforce4/Radeon, your code will run as if it were a a single-texture low-end card?

Different driver versions also expose different capabilities, so if you want it to be accurate, you''d have to build a database of driver versions as well.


Stay Casual,

Ken
Drunken Hyena

Share this post


Link to post
Share on other sites
Hi!

Drunken if you take a look at a post in which i replied to Neil you will probably get the idea that i had. In principle its far too complicated to hardcode completely for caps. I tried this one out and it sucks. Newer cards are also supported. Just read the reply that i gave neil!

Happy coding!
Incommunicado

Share this post


Link to post
Share on other sites
So if it runs on a card you haven''t hard-coded for, then it queries the caps and chooses the best path it can based on them. So how is this better than doing it based just on caps? You define x different paths, give them requirements (use this path if it has VS2.0, etc) and then just always handle it as if it were a new card. You get the same effect without having to hard-code any device IDs.

Plus it handles the situation where caps can change based on differing driver versions. New drivers have taken away and added features in the past, it''s a fair bit they will continue to do so. And when that happens, your hard-coded paths either are no longer optimal, or they may not work anymore.




Stay Casual,

Ken
Drunken Hyena

Share this post


Link to post
Share on other sites