So planar-to-chunky could be done in the shader?

@Hans

I may end up doing both in the end. The problem isn't the 8-bit CLUT, it's getting OpenGL to open an 8-bit alpha-only framebuffer to save on video RAM. For those graphics cards that don't have Gallium, the OpenGL version will require 32-bits of memory per 8-bit pixel just because I don't know how to allocate an 8-bit framebuffer in OpenGL.

@Elwood
Sorry, no. There were no comments on Aros-Exec so it didn't even show up as a blip on Power2People's radar screen. I suppose I could have started a bounty myself by offering some money.

I might just start tinkering soon. I'm getting a used computer from a friend and if I'm lucky it should have an nVidia graphics card so I can get it to run with the AROS Gallium3D drivers.

Great! But the OS41ice theme doesn't have a report button image. Could that be solved as easily?

Personally, I think they should have made the ASL requester shorter and wider so that, on a classic machine, the file requester could be put on a custom screen to avoid palette collisions, since each screen can have its own Copper list.

@ChrisH

The free Nauveau driver for Linux that is also used by AROS works with the cards you linked above. It's possible that there will be non-free Radeon drivers for use with OS 4.x since Hyperion has NDA access to the specifications of the Radeon.

I'm not sure what the licensing implications of using the Nauveau drivers with OS 4.x would be. I have heard that Gallium doesn't use the binary-blobs LGPL library stub to interface to the Linux kernal. It may require some GPL interfacing to be able to use the free drivers that Linux uses.

I started out with this thread on AROS-Exec. I guess that's all that needs to be discussed.

The permissions on the executable were rwxr-xr-x so the executable bits were already set.

@gerograph

The second test works well now.

The preview program shows me the JPG images. The BGPic doesn't show because it doesn't have the correct suffix for the viewer to detect the type.

-edit-
The BGPic views when using the Open Using Google Chrome menu item from the context menu. It isn't corrupt.

Quote:
No, actually, it is still a black screen when it runs.
Quote:
Yes it still works as showing a black screen when I rename the bundle.

@gerograph

SlideAndFly just shows a black screen when I run it. If I run it from the command as SlideAndFly.app/contents/MacOS/SlideAndFly from the addslidetestdir directory it shows the same black screen and no error message. I think it's looking at the wrong place for its files.

Usually the current directory when running the SlideAndFly application from the icon is SlideAndFly.app/contents/MacOS/ and if you want to look at the directory outside the app bundle, you have to change directories to ../../../ and access your files from there.

I hope this helps you.

BTW, I don't have P96 installed in my work directory on E-UAE so I cannot view the 68k binary.

Message sent.

I've got an Intel Mac. Do you need me to test something?

Since AROS already has the Gallium3D drivers ported to it, I decided to post the Bounty to Power2People.org instead of AmigaBounty. Discussion about the details should continue on AROS-Exec.org.

@kas1e

There will still need to be an emulation layer over the top of the shader for the CIA timers and Paula and so on. That shouldn't need to be in the library though.

A full thick emulation layer could still use the shader routine to boost the speed of the graphics emulation. The planar to chunky conversions would still need to take place in the thick emulator application, for example, so incorporating CIAgent and Nalle Puh or something similar shouldn't kill the performance.

I think the important thing is to keep the emulation thin by mapping old functionality into the modern equivalents as closely as possible.

@retro

I decided to go with Power2People.org since AmigaBounty is OS4 only and doesn't require that the code be released as open-source. AROS has Gallium3D drivers working right now and once OS4 gets the Gallium drivers it should be easy to port from there to here. If nobody accepts the bounty right away, then writing both versions in parallel should be possible.

BTW, the Radeon 7000 chips in a MicroA1 won't be able to run shader programs. They use what's called a "fixed-function pipeline" that works differently. It'll need thick emulation on the MicroA1 or else use the hack to allow a graphics card to plug into the PCI slot.

Easier? Maybe, but it would also be DEAD SLOW. E-UAE does thick emulation. Thin emulation would be executable by the shaders in the graphics card and would run much faster since it would leave the CPU alone for executing the actual code and the JIT besides.

On the SAM 440 series, the graphics cards or on-board chips are fast but the CPU is not very fast by today's standards. The SAM 460 fixes the CPU speed problem partially but still has underutilized graphics capabilities on its graphics card. Only an AmigaOne X1000 would have the brute force to make thick emulation work.

Thick emulation works well on MicroA1-c machines because the Radeon 7000 chips have no shader capabilities. On modern graphics cards, the chips can be programmed to run simple programs on each pixel displayed so that some Copper-style capabilities can be regained by the system.

For example, Total Chaos AGA runs dog slow on my Intel Mac running E-UAE even though the JIT is active. The reason for this is that the chipset emulation is much slower than the processor emulation. I suspect P-UAE would be more compatible but still slow. I want chipset emulation on NextGen Amigas to be uniquely capable of emulation of Classic capabilities that even WinUAE struggles with. Of course DirectX is more able than OpenGL in this regard so I want to close the gap.

@DAX

Preferably as a shared library so that software could run from a common source code with people writing software for Classic Amiga. EUAE could access it among others programs.

There is a Wikipedia article about Gallium3D drivers.

Gallium3D drivers are slated to come in a future version of AmigaOS 4.x.

I'm talking about code that will bypass OpenGL and access the graphics drivers directly to implement AGA chipset features.