That's a misquote. What I actually said was:samo79 wrote:A month ago i talk with him on Amigaworld about WarpOS layer emulation and he more or less say: Ok i have a good idea for what can be done but for now i don't have any access to the Warp3D code so i wait and see
http://amigaworld.net/modules/newbb/vie ... r=0#618026
I have access to actual Warp3D repository - would be a bit tricky to work on drivers otherwise ... it's the WarpOS+Warp3DPPC.library wrapper sources I have no access to.One of the more annoying problems to deal with is supporting older applications that do naughty things whilst trying to refactor driver code for better performance. It was disappointing to see just how many old apps were broken because they relied on poking into structures for which there are perfectly good API calls. The few CPU cycles they saved in doing so is nothing compared to what they end up losing if a more efficient strategy for rendering is hampered by having to constantly check for the changes they may (or may not) have made.
In an ideal implementation (at least ideal until we have an alternative 3D system), the Warp3D.library and drives would be made a lot stricter insofar as the API must be adhered to the letter and would be unit tested. Then supporting older WarpOS applications and whatever workarounds are needed to do so when a stricter library is in force would be put into the Warp3DPPC.library emulation - even if it required creating a surrogate set of structures to be poked by older applications and passing that data down into the proper driver via the correct methods. I like this as an interim approach as it keeps any dubious hacks out of the main driver and in the emulation support. However, I don't have any access to the WarpOS/Warp3D emulation source, so it's not a likely prospect.
To reiterate, the above quote was in relation to working around all the ugly hacks. A perfectly clean, API-compliant Warp3D driver will not run a lot of old titles simply because too many of them poked into the internals of it in order to save a few cycles*. I actually unit tested my Permedia2 driver functions to ensure they were as close to the API specification as possible and it still wont run a lot of old WarpOS era Warp3D titles because they took shortcuts with Warp3D, poking contexts and so on. So, I had to add various work-arounds to improve compatibility but even then, there are old apps that simply don't work.
It is my opinion that any such hacks should be put into the Warp3DPPC.library emulation and not into Warp3D itself, since otherwise, you are making any attempt to tidy up and bugfix Warp3D itself incredibly difficult. Ideally, Warp3D would be extremely strict so that drivers can be unit tested, MiniGL would be recompiled with it's various bugs fixed and all the kludges to support the old stuff moved into the legacy emulation stuff.
However, that is very unlikely to happen. Warp3D will be tweaked and fixed as far as is reasonably possible and then it will be retired in favour of a wrapper around Gallium (if at all - that's not my call but I'd hate to see all support for it as an API dropped) and can then be patched to support old stuff till the cows come home without support for any of that stuff leaking down into the 3D subsystem like it does now.
*The worst thing is, the few clock cycles they saved by circumventing an API call is nothing compared to the potential performance gain they lost out on by forcing the driver to continuously revalidate internal state that just calling the API function originally would have avoided.