Hi Georg

Quote:

Not 100%. But this is certainly the effect on AmigaOS and MorphOS.

Quote:

Yep. I realized this from looking at the AROS source.

I'm not terribly keen on using this method to access the bitmap's pixels, but this is the way the AmigaOS gfx driver in UAE has always worked. And since it works on AmigaOS and MorphOS I haven't changed this - yet.

As I mentioned, I've tried replacing this by creating a friend bm and locking to access the pixels, but, as I said, this didn't work on AROS/X11 either. Thanks for the explanation as to why.

Quote:

Ah ha! This isn't mentioned in the CGX autodoc I have. Thanks.

Quote:

"In system memory": I did not know that using BMF_SPECIALFMT and NULL friendbm is a guaranteed to create bitmap in system memory. Sure about that?

"garbage":

The "cybergraphics.h" header says:



So it's not even implemented in AROS.

Quote:

If you use screen bitmap as friend bitmap, you will get it. But with X11 driver LockBitMap will still fail, as it's not supported by the driver. LockBitMap is allowed to fail according to autodocs, so apps must keep that in mind. The reason why it fails is that the X11 driver works in a way not similiar to for example UAE. There's no virtual VRAM or anything. The visible (screen) bitmap is the X11 window itself. Other screen bitmaps are X11 Pixmaps. Friend bitmaps of screen bitmaps are X11 Pixmaps, too. By doing it like this gfx operations like line drawing, rectfilling, blitting can be done with the corresponding X11 gfx functions == hw accelerated == faster. Of course there are also cases where the UAE approach would be faster. When reading pixels out of bitmaps from example. This needs to be done with XGetImage() which is slower.

The best way here is really to do it like said by Fabio. Using WritePixelArray() and RECTFMT_RAW which means pixels are same format as dest bitmap. RECTFMT_RAW might not be available in AOS CGX, or at least not in older versions. Probably it was invented only after MorphOS development started.

PS: There's also a Linux framebuffer gfx driver for AROS hosted, but it's not really meant to be used by anyone, as it's a bit dangerous, can lock up whole machine if AROS crashes sometimes, etc., because code not really doing things correctly (probably) regarding error handling, virtual console stuff, etc.

Quote:Ditto

evilrich, nice to see you around! =o)

under native it doesnt worked too!

fabio ideia is good, and i even thought that you have allready looked into. aros uae also has a gui based on custom mui/zune class, that is not working atm, but maybe you think that is cool! =o) (maybe not)

regards,

Quote:

No, the problem is not that the bitmap couldn't be created - that's just a warning given by the x11 hidd, the parent class will create it flawlessy, as in fact it is - the problem is rather that you seem to want to access the bitmap directly, which is not possible under X11.

Look at my UAE port - it's in the contrib repository, under the emu directory - to see how to deal with such things. You might just want to reuse my UAE gfx driver, it also has support for p96.

Hi Coolcat29

You wrote:
> The function arosc/signal() is not implemented.

No biggie. Sending CTRL+C to E-UAE won't start the debugger.

> The function ChangeExtSpriteA() is not implemented.

Again, not the end of the world. This means that the mouse pointer won't be hidden in windowed mode.

> x11 hidd: Could not create offscreen bitmap for supplied attrs! Superclass hopefully can.

This is the problem - I think.

E-UAE tries to allocate an off-screen bitmap in system memory (not video memory). AROS claims that this works - the AllocBitmap succeeds - but the pointer to the bitmap's pixels is garbage. Hence the segfault.

I had suspected this may be a deficiency of the X11 driver, but I haven't had time to try a native version yet.

Anyway, I can work around this for now simply by disabling CGX support for AROS. This means that output is only in a maximum of 8 bits of colour (like that screenshot I sent you a while back) but this doesn't slow it down. I'll provide you with a new binary that works hosted on X. (Sorry. I did mention that the binary I gave you was buggered on X. I assumed as an AROS enthusiast you were running native, and I thought it was X driver at fault,)

However, IMHO, this is a compatibility problem for AROS, since the code works correctly on AmigaOS (68k and OS4.0) and on MorphOS.

I am re-writing E-UAE's AmigaOS gfx driver for the next version, and it's possible that a better work-around for AROS can be achieved if necessary. In the new version, for example, I'm trying to use video memory for the off-screen bitmap where possible and where it is an advantage to do so - but even that (allocating a bitmap as a friend of the screen) doesn't seem to work on AROS on Linux/X11. I've tried many permutations of parameters to AllocBitMap. I can't get this to work on AROS on X at the moment.

I'm not giving up just yet, though, even if I have to start debugging AROS's X driver.

Cheers,
Rich

Quote:

As a technical support professional I can give the most common advice for any situation when you don't know the real answer.

"REBOOT!!!"

Thus ends today's support class.

[LDDemon] Could not open trackdisk.device
The function arosc/signal() is not implemented.
...
The function ChangeExtSpriteA() is not implemented.
x11 hidd: Could not create offscreen bitmap for supplied attrs! Superclass hopefully can.
The function arosc/sigaction() is not implemented.
Segmentation fault


any hints!?!?!?

A work in progress then ... another thing to look forward too though

hi, i just tried the e-uae bin...

24 bit depth is not supported and 16 bit make it crash....no joy atm! just reporting!

regards,