Hyperion Entertainment Message Boards

Spirantho wrote:On behalf of all MAME fans, may I say "Thank you"

In the meantime, if you would like to give me a valid unit test for your change, that would be good. Bear in mind I can only test it on the A1200/Permedia right now.

If you download http://www.retroreview.com/iang/minigltest.lha it has a "tiny" compile of MAME (well, it's tiny compared to the full MAME!). It should run on your 1200 though. The archive is 6.8MB compressed.

In the archive is "mametiny" (the executable), "minigl.library.orig" the version of minigl.library that was downloaded before I played with it, for comparison) and "minigl.library.fixed" (the fixed library). There is also a "roms" directory with "circus" in.

To test it, copy either minigl.orig or .fixed (or neither, as you should already have .orig) to libs: (after making a backup, obviously). Then set the stack size high (I use 2048000 to be safe) and run "mametiny circus -video opengl".
If you're running with the original minigl.library, you should get a load of white squares, as the minigl doesn't know how to unpack the ARGB data.
If you're running with the fixed minigl.library, you should get the text and then the game up looking great (and much, much faster on larger screenmodes).

If you need any help just yell.

Thanks again!

@spirantho

Please check your PM.

Spirantho wrote:and run "mametiny circus -video opengl

Wow using this command, so with opengl and with fullscreen enabled (on a Sam440 Flex 800) i got --> Average speed: 91.88% (21 seconds) !
While without opengl i'm still at 21% (more or less)

Only problem, in opengl mode the game window seems not 100% allineated to the screen area

Looking forward for the final release, and of course for the new MiniGL, according to the readme in SVN we had many changes since the oldest 2.5

http://www.hyperion-entertainment.biz/s ... -kc/README

samo79 wrote:

Spirantho wrote:and run "mametiny circus -video opengl

Wow using this command, so with opengl and with fullscreen enabled (on a Sam440 Flex 800) i got --> Average speed: 91.88% (21 seconds) !
While without opengl i'm still at 21% (more or less)

Only problem, in opengl mode the game window seems not 100% allineated to the screen area

Looking forward for the final release, and of course for the new MiniGL, according to the readme in SVN we had many changes since the oldest 2.5

http://www.hyperion-entertainment.biz/s ... -kc/README

I hope to have a 2.9 release when I get a free weekend. There are some improvements to be made to texture handling which should reduce memory use and replace the rather awful unpack and repack to Warp3D conversion routines most of which still do byte reads. Skipping them where possible will improve things like video textures.

@Karlos

Excellent news, thanks to your improvements in the end i hope we will gain also some more speed, beside the fixed issues (that are very welcome of course) this will be essential for playing at 100% our current 3D games on certain (slow) hardwares

Keep it up !

Spirantho wrote:If you download http://www.retroreview.com/iang/minigltest.lha it has a "tiny" compile of MAME (well, it's tiny compared to the full MAME!). It should run on your 1200 though. The archive is 6.8MB compressed.
<snip>
If you need any help just yell.

Unfortunately, I can't get it to run on my A1200/PPC - it basically seems to want to try and use 1024x768 modes which fail as there's not enough memory for these resolutions (when you consider there might be multiple buffers and so forth).

I have compiled a new debug version of MiniGL (still officially 2.8) which now profiles all texture conversion / pixel drawing operations. Currently, MiniGL uses a 2 part conversion process. Pixel/Texel data in esoteric GL formats are expanded a scanline at a time into a temporary line buffer and this data is then converted to whatever Warp3D format best matches. For the most part, this is not a problem because this conversion is infrequent. However, for an application like yours, this is every frame. Also, many of these routines are naive byte based conversions.

Consider further that MiniGL picks the texture formats in Warp3D that are a closest match for the intended source data and not the fastest format for the selected hardware driver. This means that the texture data given to Warp3D by MiniGL may undergo an additional conversion to a fast hardware format.

I intend to replace this entire texture conversion pipeline with something more efficient. First, however, I want to get an idea of how much time is spent. This debug build uses an internal profiler which reports to the debug buffer (or serial if you have it). I'll send it to you and if you could test it and report your debug output (ie C:DumpDebugBuffer CLEAR, then your test, then C:DumpDebugBuffer > debug.txt)

...

Great work!

You can:
set SDLMAME_DESKTOPDIM=320x240
to change the screen size...

Edit: I think Karlos should *definitely* be the benefactor of a bounty - if he's interested.

Spirantho wrote:Great work!

You can:
set SDLMAME_DESKTOPDIM=320x240
to change the screen size...

Done. Unfortunately, the results are still not as expected. The reason in this case is that an unsupported blending mode is being used. Nevertheless, my debug results (which include profiling for Warp3D and the driver) are here:

http://extropia.co.uk/_temp/mametiny_gl ... _debug.txt

If you scroll to the end, you will see a section starting MGL:Profiling statistics. You can see that on this system, MGLUpdate() is a big time consumer and all of it's time is spent, as I suspected, calling unpack_argb_b() and then write_rgba(). This illustrates my previous point regarding inefficiency quite well. The Permedia can handle 32-bit ARGB texture data directly and no conversion should be necessary, it's just enforced by MiniGL's internal texture handling which happens to use RGBA as an interim format for all texel data.

Incidentally, this:

[cgl_GLBlendFunc] Blend mode 0306 0000 not supported by hardware

is what's causing the total lack of visuals on the Permedia2. 0306 is GL_DST_COLOR, 0000 is GL_ZERO. If I am understanding it right, you might as well glDisable(GL_BLEND) instead*.

*note to self - perhaps interpret the underlying warp3d equivalent by disabling blending on the Permedia2 rather than returning unsupported blend mode.

edit

Incidentally, if all you are doing is using MiniGL to scale emulated framebuffer images, then you might consider some alternatives that I believe would be significantly more performant because MiniGL is introducing a large latency here. Futhermore, it would more broadly compatible.

1) Define a set of function prototypes for creating and destroying an opaque Scaler type and a scale method that accepts the raw pixel data input to be scaled into a BitMap. All the contextual information can be stored in the Scaler instance.

2) Define a number of potential scaling methods that all have the same function prototype: Software only, Warp3D and Compositing.

3) Implement each one and have the Scaler creation function choose the most appropriate, Copositing > Warp3D > Software

A quick test I wrote for WarpOS years ago generated a plasma fire fractal texture (32-bit ARGB) and used Warp3D to scale it full screen over a scrolling texture background. 25fps rock solid on my 603e. I hate to say it, but in it's current incarnation, MiniGL can't come close to this and it doesn't even have the context switch overhead to worry about.

OK, so Warp3D is deprecated, but MiniGL sits on top of it anyway. The beauty of a polymorphic scaler engine is that you can swap new implementations in and out.

On reflection, not a bad idea for a library...