Talk:A.I.M. 2: Clan Wars

Hello,

Regarding the rollback of rev. 1347861 (via 1439157)...

> "Game only implements D3D8" needs citation [...]

This was a personal research of mine and I have no one else to cite. As I understand, part of the reason why my change was rolled back is because I didn't self-ref. it, yes?

I can confirm the game never calls and is not even linked against any of the DirectX 7 libraries. Although the game depends on DirectDraw and DirectSound, notably which are part of DX7 and even earlier iterations with the very same dynlib names (without a version number), they're are both also core component of DirectX 8. Both have been directly incorporated into Windows SDK since ~2012 and users shouldn't be missing these libraries nowadays even if they were needed.

> [...] especially given game crashes when going in-game if system lacks D3D7 support (i.e. when using wrappers)

Wrappers shouldn't be mixed into this topic at all and only the game's binary should be the sole source of the supported DirectX version. Some wrappers may have dependencies to wider selection of libraries and additional functionalities (which is esp. true for dgVoodoo 2, which was referenced, as it does _a lot more_ than just translate calls) that native driver, or more conservative wrappers, wouldn't have.

When an user installs a wrapper and the game doesn't run due to lacking DX7 support, it's the very same wrapper itself which is dependent on DX7 for whatever reason, and not the game.

There were never any wrappers bundled with the game, at least not originally. Out of all vendors, right now, I know that GOG does ship their own external wrapper with the game. The article should mention this in the notes of affected releases and list only the real capabilities and requirements of the game's binary under system requirements section since this remains the same across all versions (patches) and releases.

For the note, I'm on an OS which is incapable of DX7 (due to it not being installed) and I can run the game just fine.

The main reason your edit was reverted is because it contradicted research done by Dege, the creator of the dgVoodoo2 wrapper - which remains pertinent because at the time of the research, dgVoodoo2 only wrapped D3D7-8.x and Glide APIs to DX11 unlike today.

I am not going to waste my time refuting an obvious misunderstanding of how Windows compatibility works and how this wiki documents things - which can prove contrary to what the developer states in system requirements, such as in this case.

Your edit will not be reverted.

I apologize for the harshness of my tone in my initial reply. I was not in a good place when I wrote it, and I should not have even been replying in that state.

While the main reason is still correct, I would also invite you to share how you came to your conclusions. Windows compatibility works in strange ways. For example, D3D9 has backwards-compatibility built-in for both D3D8.x and D3D7 and lower (long story short, up until D3D8, all D3D versions contained supersets of all prior D3D versions, meaning you didn't have to have multiple versions of system D3D files installed), which is how the original release of Half-Life 2 can directly support GPUs as old as the D3D6 era while still requiring and exclusively using D3D9. It's still making the same old calls those cards will recognize, just not through the normal methods.

Furthermore, it sounds like the behavior you're describing is simple Windows compatibility kicking in. Nobody with a modern machine has D3D7 installed, yet those games will still run because Microsoft has built-in system files for anyone playing games which need them. Plus, it could be that D3D8 has a similar approach to backwards-compatibility as D3D9 does.

Also, why dgVoodoo2 needs both D3D8 and D3D7 DLLs when a game like A.I.M. 2 uses D3D8's backwards-compatibility is because when D3D8 makes the D3D7 calls, Windows is expecting the GPU drivers to handle those calls because, as far as it knows, a D3D8-compatible GPU is being used, so it doesn't need its usual compatibility work. So when D3D8 makes D3D7 calls, dgVoodoo2 needs the corresponding D3D7 DLLs to accept and wrap those calls - otherwise, the game crashes because, in effect, the GPU has no idea how to handle calls it should know how to make.

I'm late to this, but I'll add a few things.

dgvoodoo doesn't make calls to system d3d files. The interfaces are within the dll files of the program, D3D2-6 (d3dim.dll) and D3D7 (d3dim700.dll) are implemented in d3dimm.dll, and D3D8 and 9 have their own dll files.

It has a tracing feature where you can exactly see which interfaces are called, which would reveal which D3D version is used. I haven't personally tested this game though.

@Macgovern

D3D9 (d3d9.dll) doesn't inherently have backward compatibility; not all D3D9 games would work on older video cards. It's up to the game developer to choose which interfaces to use.

Also d3d9.dll isn't a replacement for older vesions. If a game needs d3dim700.dll, it wouldn't work without it. You actually need to have the older dll present for such old games, and these files do in fact exist in the System or sysWoW64 folders (and if not, can be added by installing a pre-June 2010 DirectX redistributable package).

I just tested the GOG release. It does have its own DDraw-&-D3D8 to 9 wrappers. Funnily enough, the game crashes at launch with these.

I replaced them with dgVoodoo and it now works. Tracing shows that it only uses D3D8.1 for rendering, and also seems to be using Pixel Shader 1.4.

It also accesses DirectDraw but it doesn't really seem to be doing much with it. It's not even DD7; seems to be DD1. Maybe it's used for video playback?

In any case, as far as D3D is concerned, it's 8 only.

With these new findings, I find it hilarious the game crashes if it can't interop with DirectDraw 1 for what could simply be VIDEO PLAYBACK (unless it's also doing some rudimentary 2D work in-game). Great find!

Also, could you please amend your self-reference with the version of dgVoodoo2 you used for tracing? That way, people can tell what version was used without having to ask you every time. :D

It might be used for the menus too, I'm not expert enough to tell, but the usage is very limited.

I can't tell which GOG wrapper is causing the crash, DDraw or D3D8.

Never mind; it is RTSS that causes the crashing.