Direct3D 3 renderer

[leileilol]

When Carmack was coding D3DQuake in late '96 he ran into lots of problems with the DirectX 3 API (latest at the time) presumably due to lightmapping and having to blend that somehow, and how messy of an API it was.


How would that have looked had that actually came to something? It'd have to be vertex lit, though (like every other first-gen Direct3D game in 96)

Curiously i'm even more wondering how it would perform on the hardware of the era, i.e. Virge, Verite, Voodoo... In 2010 it's definitely a waste of time to undertake this, but this is a 'what could have been' kind of thread.

To get it looking at least like Quake should with lightmaps and overbright would need DX5/6. Add warping, and it's 8/9. It's the whole plan of Quake on DX3 I've been wondering about.

[mh]

I'd personally love to get my hands on that code, but I agree that the state of D3D at that time means that it would be historically intereesting more than actually useful.

I've actually managed to find old DirectX SDKs for 1, 2, 3, 6.1 and 7. Interestingly, D3D3 actually did have the necessary blending modes to allow multipass lightmaps (same as GLQuake without multitexture).

[Rich]

I vaguely remember that. I don't recall Carmack running into any actual roadblocks, though. I think he was mainly just complaining about the general API and the need to construct your own command buffers. Which I'd tend to agree was a pretty retarded approach for a generalized 3D API, though it's a perfectly fine one when you're making an API for an embedded system or very small fixed range of embedded devices and you want ultra-minimal API overhead.

I've seen some homebrew Dreamcast code that looks a lot like what you had to do standard for DX3 D3D. Sega wrapped it up nicely in the official SDK with the Kamui 2 API, though.

[mh]

The funny thing is that the designs of D3D10 and 11 are - when you really look at them - execute buffers all over again.

I might have a go at doing a port sometime if I can get D3D3 stuff to compile.