Retrieve RGB screen data on Picasso96 screen

[asrael22]

Hi.

I'm wondering how to do that.
I guess there is some Picasso96 developer documentation which would explain how to do that.
But I don't have it.

Is there an alternative way?

My goal is that I want to check feasability of doing a screen recorder.
I'd just dump the screen data to file. Later a .BMP header can be added and converted to something else.


Manfred

[TribbleSmasher]

You could start taking a look into the developer docs recently released by iComp, located here
http://wiki.icomp.de/wiki/P96
.

[asrael22]

Yeps, thanks.

[guest11527]

I'm wondering how to do that.
I guess there is some Picasso96 developer documentation which would explain how to do that.

You open the Picasso96API.library, and then you lock the bitmap:

Code: [Select]

struct RenderInfo ri;
if (lock=p96LockBitMap(bitmap,&ri,sizeof(ri))) {
 /* bitmap is locked now */
  p96UnlockBitMap(bitmap,lock);
}

struct RenderInfo is documented in "libraries/Picasso96.h" and looks as follows:

Code: [Select]

struct RenderInfo {
        APTR                    Memory;
        WORD                    BytesPerRow;
        WORD                    pad;
        RGBFTYPE                RGBFormat;
};

Actually, this include was always part of the public P96 API, and was also accessible before icomp bought it.

[asrael22]

OK, thanks for this.

I'm not fully sure what the 'bitmap' parameter should be.
Should I allocate a new bitmap using p96AllocBitMap?
Or LockPubScreen and use the bitmap from there? Well, that freezes the system, so it doesn't work.
That's not clear from the documentation. It says "the bitmap that should be locked", but where to get it from?

Aside from that, I'm trying to do this in AmigaE and had to fall back to C.
The Picasso96.e module in the dev package only contains structure, but no function call definitions.
I tried to produce an AmigaE module from the pragma but had some hurdles. The pragma can't be converted as is.
Now I think I got it working, need some more testing. At least I could call one of the Picasso96 API functions.
Maybe this could be either included in the dev package or I'll upload to Aminet.



Manfred

[guest11527]

I'm not fully sure what the 'bitmap' parameter should be.

Well, of course the bitmap whose bitmap data you want to read. Which bitmap that is only you can know. If you have a window, then this would be window->RPort.BitMap, for example, which would read from the bitmap where the window is placed on. But it could also be any other bitmap.

Should I allocate a new bitmap using p96AllocBitMap?

I don't know - what do you want to do?

Or LockPubScreen and use the bitmap from there?

If you want to read the bitmap from a public screen, that that is what you need to do.

Well, that freezes the system, so it doesn't work.

LockPubScreen()? Hardly. It just prevents the screen from going away, which is a natural thing to require since you want to read its bitmap. Unlock it againwhen you are done.

[asrael22]

OK, understood.

I had tried LockPubScreen() and provided the `&screen->BitMap`.
But that freezes the system.

Some code here.
I see log until "Opened screen!" then the system freezes. I'm assuming at p96LockBitMap().

Anything you se that's wrong?


Manfred

Code: [Select]

struct Library *P96Base;

int main(int argc, char **argv) {
    struct Screen *screen;
    struct BitMap *bitmap;
    struct RenderInfo ri;
    ULONG lock;

    puts("hello world!");

    P96Base = OpenLibrary(P96NAME, 2);
    if(P96Base == NULL) {
        printf("Unable to open picasso96 library!\n");
        exit(1);
    }
/*
if(screen = p96OpenScreenTags(
P96SA_Width, 640,
P96SA_Height, 480,
P96SA_Depth, 8,
P96SA_AutoScroll, TRUE,
P96SA_Title, (ULONG)"MyScreen",
TAG_DONE)){
                                    */
    if(screen = LockPubScreen("workbench")) {
        printf("Opened screen!\n");

        if(lock = p96LockBitMap(&screen->BitMap, &ri, sizeof(ri))) {
             printf("locked\n");
             p96UnlockBitMap(&screen->BitMap, lock);
        }
        else {
            printf("Unable to lock!\n");
        }

        printf("Closing screen!\n");
        UnlockPubScreen(NULL, screen);
        //p96CloseScreen(screen);
    }

    printf("Closing lib..\n");
    CloseLibrary(P96Base);

    return(0);
}


[Thomas]

1. you must not use &screen->BitMap. Read the comments in intuition/screens.h about it. You should use screen->RastPort.BitMap instead.

2. your program deadlocks because you try to write text to the screen while the screen's bitmap is locked. The text routine waits for the bitmap to become unlocked but your program waits for the text to be printed -> deadlock.

3. you should not lock the bitmap at all. As you only want RGB data from the screen, you should use the function which reads RGB data from the screen.

Here is a complete example which writes the screen contents to a file:

[asrael22]

1. you must not use &screen->BitMap. Read the comments in intuition/screens.h about it. You should use screen->RastPort.BitMap instead.

Understood.

2. your program deadlocks because you try to write text to the screen while the screen's bitmap is locked. The text routine waits for the bitmap to become unlocked but your program waits for the text to be printed -> deadlock.

I don't see where I write to the screen. It's just 'printf'.

3. you should not lock the bitmap at all. As you only want RGB data from the screen, you should use the function which reads RGB data from the screen.

I understood that while I read or copy the screen bitmap it can change. That's why the lock.

Here is a complete example which writes the screen contents to a file:

Thanks.

[Thomas]

I don't see where I write to the screen. It's just 'printf'.

printf prints text to the console window and the console window is on the Workbench screen, isn't it?

I understood that while I read or copy the screen bitmap it can change. That's why the lock.

That's correct. What I wanted to point out is that you should not go the route of locking and directly accessing the bitmap data if there is a function which does the whole job for you. If you lock the bitmap and access the bitmap data directly, you have to be aware of all the possible pixel formats, 15bit, 16bit, 24bit, 32bit, each in big endian or little endian order. With the ReadPixelArray function you can choose that you want to receive 24bit RGB data. With direct bitmap access you have to do all the conversion yourself.


By the way, if your target platform is not limited to OS4 only, you should consider to use Cybergraphics API instead of Picasso96. Because CGX programs work on both CGX and P96, your program will work on all RTG systems on all AmigaOS flavours, even MorphOS and AROS. With P96 you limit the user base to AmigaOS4 users and the part of the AmigaOS3 users which use P96.

[asrael22]

I don't see where I write to the screen. It's just 'printf'.

printf prints text to the console window and the console window is on the Workbench screen, isn't it?

True.

I understood that while I read or copy the screen bitmap it can change. That's why the lock.

That's correct. What I wanted to point out is that you should not go the route of locking and directly accessing the bitmap data if there is a function which does the whole job for you. If you lock the bitmap and access the bitmap data directly, you have to be aware of all the possible pixel formats, 15bit, 16bit, 24bit, 32bit, each in big endian or little endian order. With the ReadPixelArray function you can choose that you want to receive 24bit RGB data. With direct bitmap access you have to do all the conversion yourself.

OK, I'll give this a try. A fast mem copy should be pretty fast.

By the way, if your target platform is not limited to OS4 only, you should consider to use Cybergraphics API instead of Picasso96. Because CGX programs work on both CGX and P96, your program will work on all RTG systems on all AmigaOS flavours, even MorphOS and AROS. With P96 you limit the user base to AmigaOS4 users and the part of the AmigaOS3 users which use P96.

I'm primarily targeting classic Amiga. Trying to figure out what frame rate can be archived with Vampire. And if it's usable at all.
Cybergraphics would also work on MorphOS.
But not sure yet where all this leads too.


Manfred

[asrael22]

By the way, if your target platform is not limited to OS4 only, you should consider to use Cybergraphics API instead of Picasso96. Because CGX programs work on both CGX and P96, your program will work on all RTG systems on all AmigaOS flavours, even MorphOS and AROS. With P96 you limit the user base to AmigaOS4 users and the part of the AmigaOS3 users which use P96.

I'm primarily targeting classic Amiga. Trying to figure out what frame rate can be archived with Vampire. And if it's usable at all.
Cybergraphics would also work on MorphOS.
But not sure yet where all this leads too.

Wait a moment.
You're saying when I use Cybergraphics API this will work on classic (with either CGX and P96) and also other Amiga flavours?


Manfred

[Thomas]

Wait a moment.
You're saying when I use Cybergraphics API this will work on classic (with either CGX and P96) and also other Amiga flavours?

Yes. CGX API is common to CGX and P96. 68K software works on OS4 and MOS. Only AROS needs a recompile, but the API is available.

[asrael22]

Finally I have gotten around to implement that, or some POC.

What's weird is that p96PixelReadArray takes a lot of time, ~30 ticks (not sure of this is the best way to measure it).
Where as writing this to file only takes ~7 ticks.
I would assume that a mem copy should be a lot faster, on a Vampire with on-board Fastram.


Manfred