A-EON Technology secures graphic card support for AmigaOS 4

[itix]

@tmhgm

In fact, I just recall that other Radeon drivers were also outsourced to some other subcontractor. A company called Forefront technologies or something like that. Apparently Hyperion was not willing to pay what Hans asked and they are released separately.

It is not really surprising because Picasso96 was licensed from another company.

[itix]

I know what you mean but it depends how you want to see it. A-eon is a 3rd party manufacturer so they provide drivers for their hardware. Or in other words, Hyperion wasnt interested. Who cares. Certainly I dont.

[itix]

It is not Hyperion's responsibility to write drivers, only the API.

I agree. A-eon and Acube are 3rd party vendors and responsible to provide drivers for their hardware. I dont see any reason why Hyperion should support any 3rd party hardware without getting paid. For some reason ACube customers think they should have A-eon's drivers for free.

[itix]

However, they *are* getting paid, aren't they?

By ACube and A-eon? I doubt it. If they are, they obviously are not paying enough. I am looking this from the MorphOS developer point of view: if ACube wanted MorphOS on their hardware they pay all porting costs + premium or they develop all drivers themselves and pay less to the MorphOS team to get required support.

AFAIK, Hyperion set their price tags themselves, it's from them the whole OS4 business stems, it's them who grants "AmigaOne" systems rights, and "AmigaOS" systems rights, entirely according to their rules and fees, absolute power.

Hyperion could have paid the driver development and bundle drivers with the OS and sell OS4 at higher price. Or sell it without it and sell it at current price.

In my opinion ACube were fools to not deliver their Sams with supported Radeon cards like Radeon 9250. There is a PCI slot so why not use it. They are fast enough to do what ever you have to do with it.

"3rd party hardware"? What?! It's the only two "available" OS4 computers, in direct license/partnership with Hyperion, it's simply what OS4 runs on, it is the *official OS4 platform*! It's not something alien, something unrelated, some rudimentary unofficial third party gizmo that lacks relevance; we are talking graphics for the official "AmigaOne" OS4 computers! And AFAIK, Hyperion have at least claimed to pay for development before, so what changed? Hyperion is still here? Or is it Dickinson & Leaman now?

To be honest, it is none of my business.

I also think people who speaks about Microsoft, ATI and nVidia etc in this OS4 contexts is slightly confused. There are no similarities, not anywhere.

I agree.

[itix]

t's not even a new idea. The Permedia2 doesn't have a dedicated overlay, instead supporting YUV textures. Due to the lack of fill rate (and on the Amiga, slow buses), you are pretty much restricted to one or two streams.

I really don't think you are missing much if you don't have a genuine overlay on anything like the HD4xxx series or above but you can leverage the 3D hardware instead.

Yeah, that is how overlay is supported on BVision but it still doesnt give overlay support to current Radeon HD drivers. My car could be a UFO if it had wings.

[itix]

Think you are missing the point there

No, it is just silly. Emulating overlay using OpenGL is old story.

[itix]

Who said anything about emulating overlay with OpenGL? It's not as if we're talking about decoding each frame as an RGB texture and passing that to OpenGL. What I am describing is video texturing, in which the GPU directly applies YUV formatted data as a texture to a primitive, doing the YUV -> RGB conversion directly. This is a hardware level feature that even the old Permedia2 supported.

I was thinking that you can already achieve it on Amiga by using current OpenGL functionality. Of course it doesnt have to be exposed via OpenGL (only). BVision and CVision boards expose overlay support using standard overlay API on Amiga and users dont have to know how it works under the hood.

Btw

- Overlay typically occludes framebuffer and can't be part of any graphics pipeline or windowing architecture. It's basically "on top" or not at all.

Not really true, at least on Amiga. Overlay works with windowing and compositing just fine.

Heh, I just remember that good old never released Dragon2 even implemented overlay emulation so you could expose two mplayers with overlay simultaneously... it was only software based and quite slow but it worked

[itix]

Precisely. As I recall, it was cgxvirgin.library that supported it, if you enabled a LAYER=DESTRUCTIVE tooltype in the monitor driver or something (I don't recall exactly). You could tell it was a textured triangle fan when you made the window large enough, occasionally you could see the leading diagonal when the video wasn't properly synced.

Yup, VLAYER=DESTRUCTIVE.

Then you aren't using an overlay (at least not a traditional one). A hardware overlay, by definition, is not part of the current frame buffer any more than a hardware mouse cursor is. Modern overlays, however, tend to be implemented in a manner not unlike the Permedia2 did and as such can integrate nicely into a proper windowing environment.

Nope. Technically you are correct but it can also work with windowing and compositing. Remember that weird (pink?) colour you can see in screenshots from programs using an overlay? It is for colour keying that screenshot application found from a window bitmap where a hardware overlay was supposed to be. When colour keying is enabled the overlay data is only visible where this colour is found. If an overlay window is behind another window its colour key backfill is also destroyed and no overlay data is displayed there.

Similarly if you render text to an overlay backfill and have subtitles in a video application, for example.