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?

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!

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. :)

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

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

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.

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?

Thanks for your inputs! It wouldn't help in this case just putting it in SDL because MAME software renders to the whole window. I forced it to make a window of the correct machine size (e.g. 384x224) and then used that as the source bitmap with a scaling factor to the actual desired monitor size . Just putting composite into SDL would still be rendering in software to the actual window size.


Onice I'm happy with my build , we won't need openGL for it at all (which is much less efficient).

No can do. MAME uses all sorts of weird screen sizes, from very small to huge.

Anyway, compositing is so cheap it seems silly not to use it. :) I'm actually very impressed by the speed of my little Sam now it's being used correctly with hardware DMA (BltBitMap) and compositing - made a massive difference.

@broadblues

I may make it do that eventually, but one step at a time :) MAME is a huge, complicated project, and I'm already very chuffed that my little Sam440ep 600MHz has gone from 38% speed on "Circus" at a low screen size, to 100% speed (no frame skip!) at a high screen size!

That's why I'm compositing, by the way - for scaling.

My first effort at code was literally my first effort - doing it the most basic way. I knew it was wrong, that was the purpose of this post :)

I'm a little puzzled by the A1XE's not being so much faster. I'm going to try an Altivec build and see if that helps.

Is it possible to do a build for a particular machine? I want to do a specialised build for my Sam440ep, my A1XE G4, my CS-PPC and my X1000 and see how they benefit. I believe particularly the X1000 may benefit...

Hi everybody,

I've been "relaxing" today by playing around with MAME - it's so slow on a Sam because of the SDL graphics routines (even in OpenGL, because minigl is rather inefficient).

Incredibly, I actually have a game displaying now!

I was wondering, though -
what is the fastest way to display the bitmap?

MAME has a list of primitives which it iterates through every render. Therefore it's building up the image bit by bit.

I'm currently doing a p96LockBitMap() on my previously p96AllocBitMap()'d bitmap, and then calling the Render list. After that, I p96UnlockBitMap() and do a CompositeTags call "borrowed" from the boing3 example.

What is the most efficient way of doing this? Any particular parameters that would be useful in the allocation of the bitmap, or the call to the CompositeTags()? I'm currently using (COMPTAG_Flags, COMPFLAG_SrcAlphaOverride) as my flags field, as MAME renders to the RGBA32 bitmap with a zero alpha.

Any help gratefully appreciated!

Thanks!


Edit:
I am now allocating an off-card bitmap as well as the on-card bitmap. I render to the off-card bitmap and then do a BltBitMap to the on-card bitmap when the data is ready. Then I do a CompositeTags(). This gave a major speed-up on my Sam440ep, but not much difference on my A1XE G4. I presume this is to do with the DMA of the Sam's PCI bus....

No, just means I haven't checked in too long. :)
I've only just got my X1000 set up at work so obviously I was confusing it with an old version. Sorry!

(But great! Hurrah! :) )

AmigaAmp is great, but my music collection is all in OGG Vorbis form... so I'm limited to Tunenet (which is excellent, but lacks some features I could use). I hope other formats support gets added at some point!
Still good to see an update though, so thanks!

CubicIDE does install on OS 4.1 but it requires a bit of ... 'persusasion'.
If you have the WBstart problem, use the script on AW.net (it's on there somewhere if you Google it) which runs WBrun.

Am I right in thinking that the GCC we have pre-dates the PA6t? I'm not sure anyone is maintaining GCC are they? We really need support for our flagship.... is the current GCC version in thr official GCC repisitory?


Well done on the JIT progress though!

@afxgroup

The Linux coders are recognised by manufacturers like Conexant, so they get provided with lots of documentation I don't. The source on its own would be useful to an extent but it would take a long time to make it work fully.
I really need the datasheet, the Linux source isn't enough. Otherwise I just see Linux sticking flags into registers without necessarily knowing why or what they're doing.

@gregthecanuck

Yes, but didn't get anything useful from them at all.

@KimmoK

I need a bit more than a 4 page sales brochure, yes :)

Thanks for looking though!

@utri007

Same answer as always, I'm afraid. I need the Cx22702 datasheet.

@ssolie

That would help, yes :)
We still need the datasheet for the Conexant Cx22702 though I'm afraid. I may mess around with the 23416 a bit though, in case anyone needs a video encoding from composite video :)

I can't, I'm afraid.I need the datasheet for the MPEG encoder chip, and I can't find one.Sorry!
If you can find a full datasheet for the Conexant Cx23416 let me know!