So, I mostly decided on the "logistics" of the wrapper (let's tentatively call it WrapSGL for now). The main design goal of WrapSGL is that it has to be a tiny wrapper and simple. No rediscovering the bicycle. If a non-critical feature is cumbersome to implement, it doesn't get implemented. If the feature is critical, the projects gets abandoned. For the rendering itself, OpenGL will be used, and the render target will be an off-screen FBO (Framebuffer object), for these who are interested. After each frame is rendered, it will be copied to the DirectDraw surface, possibly with format conversion (using glReadPixels, again for these who are interested). And this is the first potential major problem. Copying a whole screen is not a fast operation. For some combos of hardware and drivers it's more slow, for others - less. My tests indicate that in some cases a whole 1024 x 768 x 32bpp screen takes about 50 milliseconds to be copied, which makes it theoretically impossible to achieve more than 20fps regardless of how quickly your accelerator can handle 3D scenes. But again, in other cases it's not so bad. Of course, PowerVR cards before KYRO and the PowerSGL API itself were never designed for high fps numbers, because by design the 3D accelerator had, almost as in our case, to transfer large quantities of data to the 2D card over the slow PCI bus. Another problem may arise from the fact that most video cards today don't support 24bpp color modes. Some samples from the PowerSGL SDK set the 24bpp mode, and fail if they don't succeed. If some game uses similar code as the samples, it will fail too, and I can do nothing to alleviate that (save for hacking DirectDraw itself, which I won't do), because the problem won't be in the code under my control. Yet another problem is Windows 8's (and perhaps, Windows 10) apparent unwillingness to work with color modes less than 32bpp, with the same consequences as the previous problem. Yet another nasty problem that I was researching just yesterday hides in the fact that apparently some samples (and presumably, some real games will too) make the invalid assumption that after locking a DirectDraw surface to obtain the pointers to its memory, it can be unlocked immediately and the pointers will stay valid. Which, needless to say, is demonstrably wrong in some cases, and in these cases the aforementioned games won't work, and again, I can do nothing to help. In order to help the users find a predictable environment for running the wrapper, I will try to make it usable in a VirtualBox guest (which helps against the issues with non-32bpp color modes and locking/unlocking at the price of possibly reduced performance).
With all that said, I'm still working on the project, albeit slowly. For now, I've mostly finished the "logistics" part, or the glue between OpenGL and DirectDraw. The next thing I will do is the rendering itself, which by the way, won't be too hard. Then come textures (which can be tedious and time-consuming if not actually hard) and next the more advanced features like fog, shadow/light volumes and so on. My primary objective is to run Unreal and Unreal Tournament with the wrapper. Once I achieve showing something adequate on the screen without too much crashes I will make the code public.
