I'm pleased to be able to "let the cat out of the bag" about NovaBridge. It's something I've been working on for a while to solve an annoying problem: backward compatibility for old Warp3D software on the Amiga computer.

NovaBridge started after yet another discussion about how confusing the Warp3D Nova naming scheme was. After all, it's not compatible with its older namesake: Warp3D. The real issue, however, is not the incompatibility itself, but the fact that end-users need to know about it. End users shouldn't have to care about which API is used; it should all just work.

So, I took the W3D_SI driver's source code, stripped out the hardware dependent code, and began replacing it with Warp3D Nova code instead. I sent a working proof-of-concept to Matthew & Trevor over at A-EON Technology, who were excited about it.

From there, it was a lot of work to implement the remaining features, including all the multi-texturing draw modes.

Some Surprises

Older Warp3D drivers have multiple per-application environment variables to work around bugs. Well, NovaBridge doesn't have any. I did add a few workarounds for some naughty demos that poked directly into the Warp3D context, but nothing else was needed. For example, WipeOut 2097's shadows work fine, without any chroma-testing workarounds. That's because it doesn't use chroma-testing after all.

I'm not sure what happened when the older drivers were written. Warp3D is quite complex, even though it's nothing compared to modern 3D. So, it can be difficult to figure out why some things don't work right. This is especially true in a time where we didn't have tools such as glsnoop to help out.

What Does It All Mean?

For end users: you don't need to care about 3D APIs any more. Warp3D, Warp3D Nova, MiniGL , OpenGL ES 2, GL4ES? It'll all just work (so long as you have Warp3D Nova drivers).

For developers: nobody needs to write a Warp3D driver ever again.

NOTE: I originally presented this talk (virtually) at AmiWest 2021, on 16 October 2021.