Great, then since it isn't important anyway, I choose DirectX 9. I'll just assume that it's coincidental that people like using the well-known interface, that I have tons of testing material, and that there are no limitations to extend the interface. I'm even using and passing many DCT tests, coincidentally.
I doubt that anyone actually LIKES using the DirectX API. Since it's relatively low-level it doesn't make coding any easier.
Please tell me all about the ideal one then.
That is exactly the point. There is no ideal interface. The interface should be dictated by the type of renderer, but in your case it's the other way around. The DX9 interface dictates that your renderer pretty much has to work like hardware, which is not always what you want. You may think it is what you want, but it is not.
As you obviously know, shaders are passed to the DirectX DLL as a stream of tokens. They are highly compatible, so that version 1.1 shaders can easily be implemented using shader 2.0 capable hardware, or software. I have sufficient testing material, but feel free to send me your application and I'll make it run.
You mean you don't have support for it.
Let me point out that the DirectX specs require any driver for shader model X to support every shader model < X.
And my code, like most other D3D-code uses a nice blend of shader versions and fixedfunction, always using the lowest possible version, to improve compatibility and reusability.
That's not going to change any time soon. What would be the alternatives anyway?
Adaptive NURBS tesselation, voxels, raytracing, REYES, ...?
Which isn't a problem at all. Behind the interface I'm in control. I can reorder, batch, cull whatever I want. I can split render operations into a deferred pass and totally eliminate overdraw. Whatever works best, there are many options. And I can still extend the interface with new methods, if that would be useful.
My point exactly, BEHIND the interface. So after the application just generated 10 mb of renderdata, you are going to batch it all, and reorder, and preprocess etc...
While this could have been done BEFORE the application handed it over to the interface, saving a lot of extra overhead.
Also, extending the interface with new methods pretty much breaks the idea of being DX-compatible anyway. People will still need to learn a new interface, and their code will no longer run on DX-hardware again as-is.
Might as well design an optimal interface then.
This isn't "extreme" to imagine. After all, you just pass geometry, material and light information. That's all you need to start raytracing. If I'm not mistaken there's a project that uses the OpenGL interface for ray-tracing.
If you want to raytrace on raw triangle meshes without pregenerated BSP-trees or the like, you are more naive than I thought.
This demonstrates my point as painfully as it can be: You get a raw set of triangles... Two choices:
1) Generate the BSP-tree on-the-fly, which could take QUITE a while.
2) Skip the BSP-tree and bruteforce the ray against all triangles in the mesh, which could take QUITE a while.
While you could implement the raytracer with O(log N) complexity, you now have to implement it with O(N) complexity because the interface doesn't give enough information.
Ofcourse, you could argue that as long as the vertexdata is static, you can re-use the same tree, so you only generate it when the data changes... But that doesn't help when you are using vertexshaders, does it?
And how would you make use of the advantages of raytracing, like shadows or reflections?
Also, if you mean OpenRT... that's a project with an OpenGL-like interface. It's not the same, but it bears resemblance to OpenGL.
I'm only a small factor behind low-end hardware. In five years we'll have the CPU processing power to play today's games in software, and you'll still be complaining...
Yes, why would I want to play today's games on my new high-end CPU in five years? I can already play them today on a simple Radeon 9600 or GeForce FX 5700, which are very cheap. Cheaper than that high-end CPU will be in 5 years. In 5 years, I want to play games that are released then, not now.
My rendering quality and performance is far beyond that of the last software-rendered games.
So was my Java engine, big deal.
So yes, vertex processing was the second bottleneck and optimizing it would have given me 30 FPS.
That code must have been REALLY shitty, if 1000 polys make it 50% slower than optimum code.
That's only six times slower. And I used 32-bit floating-point color precision and a prototype vertex pipeline back then. With fixed-point quad processing pipelines I might equal Intel Extreme Graphics II.
So fixed-point is about 6 times faster than floating point?
And although 'beating' hardware rendering performance-wise is still not my goal, an SSE z-buffer implementation is several times faster than this hardware's z-buffer.
Erm, why exactly would SSE be faster than hardware?
Then what do you really want me to do? What's "my stuff" except for a software renderer? And why don't you do it then? I'm happy with what I do.
Your "stuff" is programmable vertex and pixel processing.
I'd do it if you pay me. Else I have better things to do with my time.
