MAME Musings with graphics

@thellierMAME doesn't use Sprites and fonts like that - it builds up the display from dynamically created textures.
First it creates all the primitives in system memory (this would be very slow in graphics memory).
Then it renders the primitives in system memory (again, very slow in graphics memory).
Then I do a p96WritePixelArray to video memory, and then CompositeTags() it over to the display (unless it's an overlay surface).

I only get the data once the primitives have been created (in system memory) though. MAME does have some support for OpenGL textures, and these are all held in video memory, but I'm not aware of it being intelligent enough to cope when video memory runs out (I presume OpenGL does this transparently) - this would be very necessary on a system like the Sam440ep with only 32MB VRAM.

It is R5G5B5 - the bytes are correct. I tested by setting all red, all green and all blue - and all was correct. It really is just that white is pink and black is green!

The R5G5B5 overlay is first, the YUV422CGX overlay is second (using my own mapping code):




Thanks for the help though! It's all useful information!

@Spirantho

"
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."

I had a similar issue in the past. Mine was an endian issue, don't know about this.

@Spirantho
don't know if you already using SAM460ex onchipmem.resource (http://www.os4depot.net/index.php?fun ... er/misc/onchipmem_res.lha) maybe it helps a little for getting a few FPS more.

I'd have thought if it was an endian issue then:
a) 0xFFFF would still be white (I tried using R5G6B5 - still pink)
b) 0x0000 would still be black
c) 0x7C00 would come out blue.

The colours are right - except for the white/black pink/green thing.
But thanks for the input! The more ideas the better!

@Spirantho

Thanks for the screenshots of what's happening. It looks like it's doing YUV to RGB conversion on the R5G5B5 bitmap. In that case, white becomes pink and black becomes green, just like you describe. You can play with a colour converter here.

So, that's a Radeon driver bug.
If a beta tester could file a bug report, that would be great.

Hans

I just tried it only my Voodoo III A4000 Os4.1.
I requested a r5g5b5 overlay window and it actually gave me a r5g6b5 window! Once I tweaked the code to support this it worked just right, though.
On my Sam440 with the M9. though it's still pink and green with the r5g6b5 code, so yes, I think it's a Radeon driver problem I'm afraid!

@Spirantho

if you need tester you can ask ;)

I fixed it. :) Overlay now works nicely.....
It *was* a bug in the Radeon driver.

@Spirantho
Just curious , but : did you mean bug in radeon driver already fixed and will be avail for public, or do you make a workaround for ? Because if later, then saying what exactly need fixing may help to fill BZ about with more info => easy to fix for devs

I mean it's a bug that I've fixed in the ATIRadeon.chip - it'll be released to beta-testers soon, I'm sure.