Mesa OpenGL 68k RTG

[DisasterIncarna]

another nice project, what version(s) of opengl does it provide? also might it work hand in hand with Thomas Richter's current PCI Stack project where he plans for better support for old stuff like Voodoo3's/etc.

We have recent chat/topics for project(s) to..
- Let us use older hardware more effectively.
- Let us better use opengl/3d features.

Nice seeing projects like this, but i'm wondering if they will all work ok with each other or if various people will need to smash their heads and projects together for better/fuller support and features, a lot of our standards are still quite old, stuff like RTG/3D/Sound via AHI, no idea if they are the best we can get, "good enough" or if they can be vastly improved or not, but its nice seeing more stuff like this crop up.

[NovaCoder]

Originally Posted by DisasterIncarna

another nice project, what version(s) of opengl does it provide? also might it work hand in hand with Thomas Richter's current PCI Stack project where he plans for better support for old stuff like Voodoo3's/etc.

https://en.wikipedia.org/wiki/Mesa_(computer_graphics)

I've been playing with Mesa v4.0.4 (OpenGL v1.3)


I'm still learning about Mesa, never really looked at it before.

I think up to v7.11.2 (OpenGL v2.1) might be possible on 68k without too much effort (using the existing 68k source code as a starting point)....but that's just a guess, it depends on the changes between v4.0.4 and v7.11.2.

For some reason, I can't get the famous Gears demo to work properly (or GL Quake)

[thellier]

I dont understand what Mesa you are using ? As there are only two GL that have some value on Amiga 68k : StormMesa an MiniGL

Both can hardware render via Warp3D

[Cowcat]

For some reason, I can't get the famous Gears demo to work properly (or GL Quake)

Because expecting a new Mesa port without knowing how warp3d vs opengl works and months/years of changes since the old one kinda not gonna happen or difficult at least: Could be a simple modification or huge amounts of work.

Simple (old) demo tests from Mesa or Minigl should work out of the box (that is, knowing the changes needed with up to date Ami compilers and what opengl AmiGL API you use).

Also a "regular/simple/old PC" opengl program that works as expected on those systems, doesn't mean that the same source would work for an Amiga version.

You "should" take a look at my work at github: Biased towards minigl but it is what I need for my stuff.

[NovaCoder]

Originally Posted by thellier

I dont understand what Mesa you are using ? As there are only two GL that have some value on Amiga 68k : StormMesa an MiniGL

Both can hardware render via Warp3D

I'm currently playing around with Mesa v4.0.4 (software only, no hardware acceleration).

Originally Posted by Cowcat

Because expecting a new Mesa port without knowing how warp3d vs opengl works and months/years of changes since the old one kinda not gonna happen or difficult at least: Could be a simple modification or huge amounts of work.

Simple (old) demo tests from Mesa or Minigl should work out of the box (that is, knowing the changes needed with up to date Ami compilers and what opengl AmiGL API you use).

Also a "regular/simple/old PC" opengl program that works as expected on those systems, doesn't mean that the same source would work for an Amiga version.

You "should" take a look at my work at github: Biased towards minigl but it is what I need for my stuff.

Thanks, early days of course. I'm just having a little play around doing some hobby coding so might not get very far with this but it seems to be working okay. I'm not really that interested in looking at hardware acceleration, that all seems a bit of mess to me and too much like hard work. I'm more interested in seeing what is possible with just software Mesa now that we have some seriously powerful 68k 'accelerators' to play with

Update: With a bit more hacking around with my test code, I manged to get the Gears demo running (attached)

Can people see if it's working okay for them?

Needs to open a 16bit 640x480 Cyber screen, works okay for me in WinUAE.

If I can get this to run fast enough, maybe something like Half-life is possible one day, that would be pretty cool

[riker77]

Tried the binary on an A1200 with PiStorm32lite (CM4 @2.2GHz, OS3.2, Picasso96 3.4.0). When it does not crash, it looks pretty slow. The output flickers pretty bad. Feels like black frame insertion at very slow speeds.

Kudos for your efforts.

[jeff b00toNic]

I have also tested it, and as previously described, it runs very slowly and the buffer swaps are quite noticeable.
Pistom32lite, RPi4, OS3.2 with P96 3.1.2.

[NovaCoder]

mmm, interesting. The buffer swaps are seamless on a slow WinUAE machine, i wonder if that is a PiStorm implementation issue?

I'll try to improve the buffer swaps, thanks for testing.

Performance can be improved a bit, this is just a very rough debug test build.

Try it on Winuae and you can see how it's meant to look (no flicker).

[jeff b00toNic]

I don't know if this helps, but the old "Gears" Mesa demo, although it runs in a window, performs very well on my system even when the window is maximized.

[klx300r]

Cool stuff Nova looking forward to testing stuff out

[NovaCoder]

Originally Posted by klx300r

Cool stuff Nova looking forward to testing stuff out

Thanks mate

I've updated the double buffering code which might reduce the flicker on PiStorms, can someone see if it made any difference?

[klx300r]

@ NovaCoder


here's a quick vid on my A1200-Pistorm32-Pi3A+


https://www.dropbox.com/scl/fi/v39ye...cjnjipdsd&dl=0

[NovaCoder]

Originally Posted by klx300r

@ NovaCoder


here's a quick vid on my A1200-Pistorm32-Pi3A+


https://www.dropbox.com/scl/fi/v39ye...cjnjipdsd&dl=0

Oh wow, interesting. I assume that's with the latest version in this thread? Have a look using winuae and it's working perfectly.

Must be some piStorm bug?

I'll try updating the double buffering code again...

[klx300r]

@ NovaCoder

Is there a lib I need to install?

[NovaCoder]

Originally Posted by klx300r

@ NovaCoder

Is there a lib I need to install?

No lib required.

Did you try it in winuae?

Maybe piStorm has some issue with fullscreen 16 bit double buffering or a bug with the 16 bit clear region OS method, I'll try a different approach to clear the screen (even though it's a pistorm issue).

Okay, this new attachment uses a different method to clear the screen, might work better on Pistorm

[riker77]

Mesa Gear on PiStorm

Looks better now. Still some weirdness, but no more flicker.

[NovaCoder]

Originally Posted by riker77

Mesa Gear on PiStorm

Looks better now. Still some weirdness, but no more flicker.

Cool, thanks for the video.

Yep it seems there are a few little bugs in the piStorm's RTG driver or possibly the CPU implementation, can you report them to whoever maintains piStorm? I guess there isn't a whole lot of 16 bit screen modes used by current software so nobody knows about the bugs.

The speed actually doesn't look too bad considering that this isn't optimized code (and it's running at 640*480), looking at this I think software OpenGL is viable on piStorm.

[paraj]

Originally Posted by NovaCoder

Cool, thanks for the video.

Yep it seems there are a few little bugs in the piStorm's RTG driver or possibly the CPU implementation, can you report them to whoever maintains piStorm? I guess there isn't a whole lot of 16 bit screen modes used by current software so nobody knows about the bugs.

The speed actually doesn't look too bad considering that this isn't optimized code (and it's running at 640*480), looking at this I think software OpenGL is viable on piStorm.

Could you elaborate on what you changed, and think the issue is? I seem to recall there were some issues with specific 15/16-bit modes, but the details elude me, and I think they were only related to specific games looking wrong, not something as simple as the clearing of drawing regions, but not impossible.

[klx300r]

Originally Posted by riker77

Mesa Gear on PiStorm

Looks better now. Still some weirdness, but no more flicker.

same here (see vid below) ...what type of Pi you using?


https://www.dropbox.com/scl/fi/up1hb...tirc43pnk&dl=0

[NovaCoder]

Originally Posted by paraj

Could you elaborate on what you changed, and think the issue is? I seem to recall there were some issues with specific 15/16-bit modes, but the details elude me, and I think they were only related to specific games looking wrong, not something as simple as the clearing of drawing regions, but not impossible.

It was having trouble with the Cybergraphics method FillPixelArray()

I've been looking at the Storm Mesa code in more depth and it's doing some nasty things, it might not even be pistorm issue after all (just illegal code). I'll try and update it to use my tried and tested double buffering code and that should work fine on both Winuae and pistorm.