Just want to check in here.
Long time no see Rice. Been wanting to chat to you for ages, I'm glad your here regardless.
I may be able to answer some questions off my head, but will probably not be able to help too much.
Don't worry, I'll be able to assist, though my memory is also a bit rusty.
Supporting both DirectX and OpenGL is very nice. However, to do so, I have made the code very complicate and difficult to follow. The whole project uses C++ classes, and virtual function concepts, in order to support multiple render engine (opengl/directx), multiple graphic cards and color combiners. To understand why I do so, you have to understand that the code was written for video cards of many generation ago. Every video card supports pixel shader now, but not 4 or 5 years ago. Of course, a lot of old code is not useful anymore.
Personally Rice, since there is now a prevalence of Shader Model 2.0 - 4.0 compatible cards, I don't see the harm in completely rewriting the whole plugin to exclusively use a pixel shader based rendering pipeline for blenders and combiners. The shader pipeline I reckon does not need to have seperate ATI and NVIDIA render paths, but instead, have only special cases where its needed. For instance, in Glide64's wrapper's case, we use some ATI specific hacks only to make up for failings in ATI's OpenGL ICD (eg, specific texture formats).
HOWEVER, that leaves the question, what API?
Another important goal was to run fast. This goal may have also made the code difficult to follow. This goal may not be as important as it was years ago.
I have to agree. In this day and age, I bet most enthusiasts in emulation by now have dual core or even quad core based systems. So speed ain't a issue. Plus, GeForce FX cards are more than enough for N64 emulation with shaders. Its only in PC gaming where they are horrendously slow. So, I say now, having a clean code base should be more important than speed, since we are dealing with HLE here.
Hardware framebuffer features are not very well supported because such features were often depended on video card.
But now thats not the case. All recent cards support render to texture, as well as shaders. Also, antialiasing on hardware render buffers is possible on the most recent cards. So we don't have to worry about that anymore.
I certainly do not have anytime to rewrite/cleanup the code. There are indeed many works to be done, for example, to delete OpenGL or DirectX code from it, or to delete all codes to support low end graphic cards. I could give many worthy suggestions if someone would like to do so.
Personally, I say we remove all code to support old cards, and replace with a shader based rendering pipeline. From there, there will be no real need for explicit Nvidia/ATI render paths.
As for the API choice, that comes down to personal choice. Direct3D9 and OpenGL 1.5 are near identical in feature sets, so there is no real difference. Thats something we devs have to really think hard about, as there is no point for rash decisions.
I also see some things missing from the current source, like missing support for my ported filters from GlideHQ (HQxxS/LQxxS). Guess I could help with that.
But honestly, a complete rewrite of the plugin to fit modern cards appeals to me, no offense.
--mud.