VOGONS


Is this the possibility of a Power VR SGL Wrapper?

Topic actions

Reply 120 of 127, by Stiletto

User metadata
Rank l33t
Rank
l33t

I have RaVeN-05's file here:
http://vogonsdrivers.com/wrappers/files/PowerSGL/SGL2/

kjliew wrote on 2020-04-02, 22:07:

Sorry for necromancing an old thread as I really hope to see the light of SGL wrappers one day, even the last binary alpha release is fine. They used to be available for download from Tuxality website before they were taken down abruptly.

You sure about that? I think I would have remembered that... but I'm getting older, maybe I forgot. 😉

Have you tried sending him a private message? Tuxality last logged in in early March.

I can confirm he removed some old project pages on his website that had been in their infancy:
http://web.archive.org/web/20180524131118/htt … ub=s3tk_wrapper
http://web.archive.org/web/20180524131046/htt … ti3dcif_wrapper
http://web.archive.org/web/20160904125422/htt … sub=msi_wrapper
http://web.archive.org/web/20180524131108/htt … sub=nv1_wrapper

"I see a little silhouette-o of a man, Scaramouche, Scaramouche, will you
do the Fandango!" - Queen

Stiletto

Reply 121 of 127, by vbdasc

User metadata
Rank Newbie
Rank
Newbie

Some thoughts about the topic. An eventual PowerSGL wrapper (for PowerSGL as it is supported in PCX1/PCX2) has long been for me an itch which I wanted to scratch; the COVID lockdown finally gave me a chance to invest some time and put some thought into it. So, to begin, PowerSGL consists actually of three groups of functions: first, PowerSGL functions for high-level rendering which deals with things like display lists, materials etc.; second, PowerSGL Direct functions for low-level rendering which has the same scope as Glide and deals directly with vertices, triangles and more complex primitives; and third, the common functions that are used by both PowerSGL and PowerSGL Direct. I have no exact statistics, but I feel that the majority of games using PowerSGL actually use PowerSGL Direct, or in other words, only the second and third of the aforementioned groups of functions. So, for starters, an emulator only for the PowerSGL Direct subset should suffice. Next, actually the PowerSGL Direct API is quite simple. It's so simple, that I can see in my head how every of its functions can translate to, say, OpenGL calls. Where is the catch, then? The catch that makes creating a wrapper a really difficult task? The catch is that the PowerVR accelerators are rather unusual cards. They have no own framebuffer memory. They depend heavily on DirectDraw support for the main 2D graphic card, with the goal to use its framebuffer memory for rendering. In fact, one of the main modes of using PowerSGL/PowerSGL Direct, the so called address mode, requires that the game or client application initializes DirectDraw, creates a DirectDraw surface, and then before rendering each frame, locks the surface, obtains the address of 2D card video memory associated with the surface through the lock call, and then sends to PowerSGL/PowerSGL Direct this address, where the rendering must take place. This creates a big problem - how exactly to render to a memory address. Of course, I could create an OpenGL rendering context, render into it, and copy the rendered scene to this address, but unfortunately, DirectDraw tends to hog all video memory for itself and not leave a chance for OpenGL to even create a rendering context. The bottom line is that for proper wrapping of PowerSGL one needs to also intercept DirectDraw and create a custom DirectDraw implementation, which makes the task much more difficult. I would like to ask the user Tuxality how is his wrapper implemented with respect to DirectDraw and how does he solve the problems I outlined above. Too bad that he seems to be inactive lately. Anyway, sorry for the long rant and let's hope that one day we will finally have a working wrapper 😀

Last edited by vbdasc on 2020-12-20, 10:49. Edited 1 time in total.

Reply 122 of 127, by RaVeN-05

User metadata
Rank Member
Rank
Member

Things like this should be on internet is available in open source form even during development , so anybody can read , program , suggest , or fork and continue development.
Its not commercial project, so its should be community building, we not fight to each other for name or... We together build.

Tuxality if you read it, i really hope you release source code

as i like that concept, i am my self do things like that, trying to keep things available to anyone so any can understand. And trying to keep my source codes available too.

I can confirm on Moon Racer, if primary card is Verite2100 its works slow, if card is TNT it flies fast =)

https://hexenworld.org/forum/index.php (Heretic's & HeXen's forum)
https://www.youtube.com/user/whitemagicraven
https://go.twitch.tv/whitemagicraventv

Reply 123 of 127, by vbdasc

User metadata
Rank Newbie
Rank
Newbie
RaVeN-05 wrote on 2020-12-20, 09:52:

Things like this should be on internet is available in open source form even during development , so anybody can read , program , suggest , or fork and continue development.

If I ever manage to create something working, I promise that will put what I have in public domain, or at least in GPL if I need to reuse some GPL'ed code. Even if I put my project on hold for a long time, I will publish it, in case it reaches the stage where it contains anything valuable. But right now what I have is so ugly and embarrassing and non-working, that I will refrain from publishing it, sorry 😀

Reply 124 of 127, by kjliew

User metadata
Rank Oldbie
Rank
Oldbie

There is nothing embarrassing or ugly when one published codes for the open-source community. It helps preserving the work, passing on the know-hows and allows future enhancements by anyone who is interested and motivated. You will only get complains from those who are reluctant to learn how to compile the codes. Similar promises had been made for Tuxility's PowerSGL wrapper and Zeck's GlideWrapper, but those promises vanished into thin air.

Otherwise, QEMU capabilities of running Win98/ME VMs with OpenGL acceleration will be prime for restoring PowerVR games on modern OS through virtualization. PowerVR games are notoriously heavy on the CPU and virtualization with modern CPUs rightfully address the shortcoming. And, Linux would get a more capable Glide wrappers than OpenGlide.

Reply 125 of 127, by spiroyster

User metadata
Rank Oldbie
Rank
Oldbie
vbdasc wrote on 2020-12-19, 22:13:

Some thoughts about the topic. An eventual PowerSGL wrapper (for PowerSGL as it is supported in PCX1/PCX2) has long been for me an itch which I wanted to scratch; the COVID lockdown finally gave me a chance to invest some time and put some thought into it. So, to begin, PowerSGL consists actually of three groups of functions: first, PowerSGL functions for high-level rendering which deals with things like display lists, materials etc.; second, PowerSGL Direct functions for low-level rendering which has the same scope as Glide and deals directly with vertices, triangles and more complex primitives; and third, the common functions that are used by both PowerSGL and PowerSGL Direct. I have no exact statistics, but I feel that the majority of games using PowerSGL actually use PowerSGL Direct, or in other words, only the second and third of the aforementioned groups of functions. So, for starters, an emulator only for the PowerSGL Direct subset should suffice. Next, actually the PowerSGL Direct API is quite simple. It's so simple, that I can see in my head how every of its functions can translate to, say, OpenGL calls. Where is the catch, then? The catch that makes creating a wrapper a really difficult task? The catch is that the PowerVR accelerators are rather unusual cards. They have no own framebuffer memory. They depend heavily on DirectDraw support for the main 2D graphic card, with the goal to use its framebuffer memory for rendering. In fact, one of the main modes of using PowerSGL/PowerSGL Direct, the so called address mode, requires that the game or client application initializes DirectDraw, creates a DirectDraw surface, and then before rendering each frame, locks the surface, obtains the address of 2D card video memory associated with the surface through the lock call, and then sends to PowerSGL/PowerSGL Direct this address, where the rendering must take place. This creates a big problem - how exactly to render to a memory address. Of course, I could create an OpenGL rendering context, render into it, and copy the rendered scene to this address, but unfortunately, DirectDraw tends to hog all video memory for itself and not leave a chance for OpenGL to even create a rendering context. The bottom line is that for proper wrapping of PowerSGL one needs to also intercept DirectDraw and create a custom DirectDraw implementation, which makes the task much more difficult. I would like to ask the user Tuxality how is his wrapper implemented with respect to DirectDraw and how does he solve the problems I outlined above. Too bad that he seems to be inactive lately. Anyway, sorry for the long rant and let's hope that one day we will finally have a working wrapper 😀

This is really interesting, and may go someway to describing why an SGL wrapper has been so elusive for so long. Thanks for this. Still a pipe dream for the time being I guess 🙁

Reply 126 of 127, by dr.zeissler

User metadata
Rank l33t
Rank
l33t

I would prefer that old games get patches or fixes if they use D3D on PCX1.
e.g. Forsaken is great except the black borders on the lights (weapons/explosions) beside that it's fantastic on K6-2/450 Win95b and PCX1 (Onboard RageIIc)

Retro-Gamer 😀PowerMac 6100-66/Houdini 486/66 - G4 Cube 450/Rage128pro OS9.0.1 - Macintosh LC/Apple IIe Card OS6.0.8 - Acorn A4000 Archimedes - Unisys CWD 486/66 + Aztech Washington

Reply 127 of 127, by vbdasc

User metadata
Rank Newbie
Rank
Newbie

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.