I was basically going to say the same thing as above.
The last game I played that supported OpenGL and DirectX within the same executable was Unreal Tournament 2003, and that was almost 10 years ago.
And it basically makes sense.
- Dynamic cast is something you never need to use within your entire career. I still to this day have never actually used that type of cast in code.
- Dynamic casts are not an optimization anyway. There is a lot of overhead associated with this type of cast, and it is generally regarded as a “never use” situation.
- Even if any specific user wanted to the option to run OpenGL or DirectX within the same executable, that user is only going to make that choice once. It is not like a users is going to suddenly decide in the middle of a game that he or she wants to switch from OpenGL to DirectX. That basically means all those virtual functions have no meaning. 10 months later you just called the same virtual functions over and over and basically just wasted time. Virtual functions make sense when the type of object might change during run-time, but, in a game, the change from DirectX to OpenGL or vice-versa is only going to happen at most once a year. Meanwhile, every frame of every day of every month of every year you are taking the hit from the same virtual function. It doesn’t make sense. Just compile a second executable as all games these days do.
And if you do decide to compile a second .EXE for each API as you should, you may find this article helpful. Trust me when I say you definitely do need a strategy to avoid spaghetti when you start compiling multiple versions of the same executable.
L. Spiro
How do you handle the user switching between APIs? The simplest method which would also allow end-user API switching would seem to be to just have the launcher swap around API.dlls - Copy the relevant API.dll from the DirectX/OpenGL/Whatever folder into the dlls folder when the user clicks "Ok".