@PixelHi

Many Radeon R7 240 and R7 250 cards wont work with the Sam460ex currently so it can be trial and error.

I am using a RadeonHD 8570 for testing.
As of this morning with a updated beta version of the RadeonHD V5 driver it is working very well .
Compositing gui prefs and Interrupts .
Warp3DNova and accelerated video up to to 720p .
Both DVPlayer and Emotion.

RadonHD 8570 model

Using a DP to DVI cable.

_________________
Sam460ex : Radeon Rx550 Single slot Video Card : SIL3112 SATA card

@Spectre660

Great thank you for suggestion. I have some Radeon 5450 and 4xxx and something else lying around on my pile of useless hardware😁. If none will work I will get 8570, on ebay those quite cheap.

Thank you!

I think I will create new thread.. Sam460 most optimal hardware selection 🙄

@Hans

Quote:

I think I mixed up your comment and billt's, who did seem to ask about the RadeonRX driver.

Ah ok. Yes he did. He was asking what Rx meant and if it related to RX. So in any case it is relevant. Unfortunately, as I found, both Rx and RX terms are used in OS4 Radeon driver info as well Radeon GPU info.

Quote:

It doesn't go full-screen, because WipeOut is hard-coded for a big-endian 16-bit screen which aren't available on newer graphics cards.

Okay. So how is it rendered into a window? Does it need the Workbench screen to be RGB16BE?

If not, when that mode doesn't exist, how is it rendered into a window on a framebuffer of different format? And can this or some kind of compositing or conversion be performed to render it on a foreign screen? With scaling if needed.

Last edited by Hypex on 07-Oct-2022 at 03:00 PM.

@Hypex

Quote:

Okay. So how is it rendered into a window? Does it need the Workbench screen to be RGB16BE? If not, when that mode doesn't exist, how is it rendered into a window on a framebuffer of different format? And can this or some kind of compositing or conversion be performed to render it on a foreign screen? With scaling if needed.

The Workbench screen can be 16 or 32-bit. I don't know exactly what it does, but it's most likely rendering to a 16-bit back-buffer, which is then copied into the window. The GPU handles the conversion.

Yes, the same conversion during copy to the screen could theoretically work for full-screen, but it might not be needed. It could be as easy as patching the binary to look for a 16-bit little-endian mode instead of big-endian. If the game's intro copies 16-bit bitmaps directly to the screen, then those would be messed up (I've seen that done before). However, the game itself would work just fine.

_________________
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work

@Hans

Quote:

The Workbench screen can be 16 or 32-bit. I don't know exactly what it does, but it's most likely rendering to a 16-bit back-buffer, which is then copied into the window. The GPU handles the conversion.

Okay, that makes sense, since the 3d needs to be rendered. Unlike copper lists that can render live.

Quote:

Yes, the same conversion during copy to the screen could theoretically work for full-screen, but it might not be needed. It could be as easy as patching the binary to look for a 16-bit little-endian mode instead of big-endian. If the game's intro copies 16-bit bitmaps directly to the screen, then those would be messed up (I've seen that done before). However, the game itself would work just fine.

Patching seems a bit hacky. But if the source is unavailable I can see why. Good to know is how it copies the bitmaps, directly or using Warp3d or OS. In any case something would need to intervene and convert it. Be easier even if a virtual big endian mode could exist that did it when prompted.

The P96 FakeNative modes did something similar for planar to conversion,