MAME Musings with graphics

So... as some of you have probably noticed, I'm currently playing with MAME again.

I'm currently using MAME's software renderer to render to a previously allocated private (off-card) bitmap, then doing a BlitBitMap to a previously allocated ON-card bitmap, and then doing a CompositeTags() to get the data into the RastPort.

This works well.

However, it's probably not the perfect solution. That software renderer is much slower than doing it in hardware... but HOW to do it in hardware...

Obviously I can't do compositing in main memory, and yet compositing is the only way to do the alpha blits required by MAME (which uses blend modes). That would restrict me to doing everything in graphics memory.
BUT, given that all my primitives are dynamically created, I have no way of getting the primitives into graphics memory without calling p96AllocBitMap() every time a primitive is created, which I imagine would be dreadfully slow (there's quite a few primitives).

So is there any way I can get a nice speed-up that I've not thought of yet?
Any suggestions?

@Spirantho

Are you talking about primitives being updated dymaically? Or, are new primitives being created all the time? For dynamic updates you could simply use the same off-card & on-card bitmap combo.

If you're talking about new primitives being created continually, then what does the OpenGL backend do? There's a similar overhead to continually creating and destroying textures, so I doubt that it would be handled in that way.

Hans

Hello

>every time a primitive is created
> (there's quite a few primitives)

I dont know what are your "primitives" pixels ? lines ? triangles ? rectangles ? shapes ?
But perhaps you can use Warp3D (lines,points,triangles) or Compositing (triangles) to draw your primitives in graphics memory.

Alain Thellier

@thellier

Nice!!! I hope someone takes the flag of the Amiga MAME conversion trend and can develop for the Amiga the latests MAME versions.

If someone succeded even maybe I will pay it for that.

Mame is GREAT!!!

Long live the loud of Heavy Metal and Amiga conversions!!!

That's a luck to have people like you here in the community forums,that's it eat the heat and keep it up

Thanks for all Spirantho little Dragon

Best

Javier Vega

I spent most of yesterday messing with palettes on MAME, only to find out it uses 16 bit palettes internally. (grrr).

The primitives are mostly textured quads- they're the ones I'm interested in.
MAME appears to keep a list of textures in video memory and reuse them when it can... however, I don't think I can do this because OpenGL probadly supports off-card textures, and I'm not using 3d software. I would need texture management code, I think.

I'm avoiding Warp3d because it's a method of the past and is being phased out. Plus it doesn't work on my x1000!

What I have found us that a fair chunk of time is lost on the creation of the primitive in graphics memory when it is translated from the 16 bit palette MAME uses internally to the ARGB32 format used by the Amiga. I found the BltBitmap and CompositeTags to be almost free compared to this.

I'm wondering how intelligent the cache control of the AMCC440ep is... to render the bitmap internally requires reading the bitmap data, then using that as an index into a 64KB palette array somewhere completely different, outputting to yet another area of memory. If the cache is stupid, this could be "Cache-Miss City".

I'm wracking my brains for the fastest way to do this depalletisation.

Currently I can play Ghouls 'n' Ghosts at nearly full speed with full frameskip but I want it faster than that. Obviously my x1000 can do it but I want it to play well on my Sam440ep 600Mhz too.

Edit:
No matter - just me being dumb. :)

However, I'm now finding that CompositeTags() is a big bottleneck... need to investigate that now...

@Spirantho

The great Spirantho :)

https://www.youtube.com/watch?v=WOkInkm7tOc
;)

@Spirantho

Don't know what you edited out, but compositetags might become a bottleneck if it's falling back to software, which might happen when dealing with of card bitmaps and / or incompatable formats.

@Spirantho

[edit]
What I have found us that a fair chunk of time is lost on the creation of the primitive in graphics memory when it is translated from the 16 bit palette MAME uses internally to the ARGB32 format used by the Amiga. I found the BltBitmap and CompositeTags to be almost free compared to this.
[/edit]

Create it in main memory then Blit or WritePixelArray() to your etxture bitmap.

Is MAME using 16bit palettes because the original hardware it's emulating does?

What I edited out was just the symptom of me working when tired :) I was using the wrong dimensions and it was crashing stuff.

I found that CompositeTags was slower when applying a scaling factor - so that was a bit of a speed-up I made there.

I'm not sure now how much time it's actually taking up, but it is a fair chunk (not surprising really, as it's a 32bit image, usually 640x480 or so, every frame). That's going from on-card memory to the main window RastPort.

I wonder what more I can do.... any tricks or tips would be nice if anyone has any. :)

@Spirantho

Quote:
I'm surprised that you can even notice the difference with the scaling factor, as 640x480 isn't that big. What graphics card are you using?

Quote:
If you're just compositing the 640x480 bitmap to the window, then I'm not sure what you can do. If you're not scaling the bitmap and aren't doing any blending/compositing, then use BltBitMap() instead of CompositeTags(); it's faster, especially with old Radeon cards. Save compositing for when you actually need it.

Try to minimise switching between GPU based rendering and software rendering (or transferring data to/from VRAM). Every time that the CPU needs access to VRAM, it has to wait for the GPU to be idle. You want the CPU and GPU to be working in parallel as much as possible.

Compositing has a certain amount of per-call overhead. As a result, rendering a few large bitmaps is much faster than rendering hundreds of tiny ones. So, it helps if you can render as much as possible in as few calls as possible. This is irrelevant if you're only copying the bitmap to screen, but does become important when you're rendering lots of small objects. My advice to those who are rendering lots of small objects, is to store multiple tiny textures in large bitmaps**, and use vertex arrays to render multiple objects in one rendering call.

Hans


** Take care with the maximum size restrictions of graphics cards. Radeon cards can handle up to 2048x2048. Radeon HD cards have larger limits, which depends on the

Just did a back-to-back test of scaling on or off. On my AmigaOne XE (G4@800), mame runs ghouls with -scale 1 at approximately 85% speed. Mame runs ghouls with -scale 0 (i.e. don't pass a SCALE tag at all to CompositeTags) at approximately 95% (10% faster) - so it's quite a difference. The same happens on my Sam440ep, more or less.

Edit: The A1 is using the Radeon 9250 for its display, and the Sam using its onboard RadeonM9.

Edit2: I only make one call to write to graphics memory (currently using p96WritePixelArray as it seems slightly faster) and one call to CompositeTags which is only using graphics memory.

Thanks for the advice, it's appreciated!

Replying to myself as this post is related but not really the same thing. :)

I'm now messing with overlay.

I've created an overlay PIP window just fine, and I've got it rendering to a 16-bit PIP window nicely (R5G5B5) - EXCEPT white comes out as pink, and black comes out as green.
I'm sure there's something really simple I don't know about - could anyone inform me as to why this is happening? It's sped up my Sam markedly, so worth doing!

I even tested it filling the memory directly -
fill memory with 0x7C00 and it's red.
fill memory with 0x03E0 and it's green.
fill memory with 0x001F and it's blue.
I can also get cyan, purple and yellow as you'd expect.

But put them all together, and you have 0x7FFF - which comes out bright pink, not white.

Can anyone tell me what's going on here? I'm edging ever closer to a release of my first Amiga-ised MAME build.... :) The RadeonHD can't do overlay, of course, but it can do composite - the overlay is really to help the lesser machines like the Sam440...

Edit:
I think this behavior is because of colour keying in the overlay window. I suspect the green is the source colour key, and the pink is the destination colour key..... but I have no idea how to change these colours! There's a small mention in the p96 API doc of how to GET a chroma key, but not set it, and even then only one key.

Is it actually possible to use RGB formats with overlay in p96?

Hello

Overlay pip window use YUV no ?

Alain

@Spirantho

Quote:
Yes, that should work just fine.

I doubt that the problem is colour keying, as the colour key operates on the window's bitmap, not the R5G5B5 bitmap that you're writing to. It simply determines which pixels your bitmap shows through on.

Hans

That's what I first thought. It's very confusing.
Same happens on my Radeon 9250.... white is pink, black is green, everything else is fine and RGB components in isolation work perfectly.
If you don't know the answer, I suspect no-one does ...!
A shame, it gives a big speed up....

@Spirantho

Not unless you encode the RGB to overlay format.
libffmpeg can trans-code the picture.

Overlay format you have one bitmap that is back and white, and then you have a picture that is the color wheel, unless you use some altivec optimized routine there big loss in speed.

You should try to find out what is b/w part of the picture and work out the rest from there.

Overlay has lot in common whit how composite video works (Lux and color are separated.)

http://www.eetimes.com/document.asp?doc_id=1272387

@LiveForIt

You're describing YUV pixel formats, but overlay should be able to handle RGB too. While overlay is usually used for displaying YUV frames from videos, it is just a rectangular region containing a scaled bitmap in an independent pixel format. Radeon graphics cards can handle RGB overlay.

@Spirantho

Try setting the Most-Significant-Bit (MSB) in each pixel, so pixel = 0x8000 | colour. While the Picasso96 format says R5G5B5, the hardware only understands A1R5G5B5 (i.e., with a 1-bit alpha channel).

Hans

@Hans

Thanks for the advice, but I tried that and it's no different (as it should be - the autodoc says it's ignored).
I'm wondering if it's something in the Radeon hardware that needs to be set up, but we don't have a way of doing it in the P96 API? The DirectDraw documentation says you need to specify the source colourkey and the destination colourkey, but there's no way of doing that for us.

Has anyone ever actually used RGB overlays before?

If you can think of anything else though I'd be very grateful - each few percentage points of speed on my MAME is making it a bit more usable on lower end Amigas....

Hello

>The primitives are mostly textured quads- they're the ones I'm interested in.

then use compositetags to draw them :
a quad = 2 tris
several quad =several tris in a single CompositeTags call
Just copy the whole "sprites map" "fonts map" etc to VRAM and pick inside this big bitmap the quads that you need

>But put them all together, and you have 0x7FFF
Perhaps it is not R5GB5 but B5G5R5 with PC ordering : i mean the 2 bytes swapped

Cant say more without seeing the display...
Do you have a source+binary i can test on my Sam440

Alain