Image data and chipmem

[meynaf]

Hi,

I noticed that ImageData from struct Image must point to chipmem otherwise it will not work (for use on a gadget or directly via intuition/DrawImage).
Now wondering if it is possible to remove this limitation -- other than creating temporary data in chipmem.

[Thomas Richter]

Two obvious answers. Obvious answer #1 is to redirect the blits to the CPU, for example with "Native" and P96. Obvious answer #2 is to use a Boopsi and there render the data with the CPU. A boopsi of the image class can be used in all places where an IntuiImage would work.

[meynaf]

And... how do I redirect/render the blits to/with the cpu ?
On own screen i can take over planar data, but there it's a window on WB screen...

[Thomas Richter]

You have to write your own blitter emulation, obviously. Roughly, you need to lock the layer of the target rastport, then perform a DoHookClipRects() on this layer, and implement the lower level rendering on the bitmap you receive from the above functions through your hook yourself.

[Bruce Abbott]

Originally Posted by meynaf

Hi,

I noticed that ImageData from struct Image must point to chipmem otherwise it will not work (for use on a gadget or directly via intuition/DrawImage).
Now wondering if it is possible to remove this limitation -- other than creating temporary data in chipmem...

it's a window on WB screen...

What's wrong with doing it the normal way?

[meynaf]

Originally Posted by Bruce Abbott

What's wrong with doing it the normal way?

Not much, i just wanted to see if i could spare a few chipmem without making the thing needlessly complicated.

[Thomas Richter]

Unfortunately, a CPU-based blitter implementation that covers all cases correctly is "needlessly complicated" - in particular if you want to cover also RTG in such cases.

It depends on what you want to actually render as image. If the image can be constructed by usual rendering calls to the graphics library (such as drawing lines and rectangles), then it is relatively easy as you do not need to simulate the blitter but can use what is there. The advantage of the boopsi would be then that you could plug it in wherever an IntuiImage is needed (e.g. in Gadgets).

If the input is a generic bitmap, it can become quite complex as it may also include changing the pixel mode, e.g. if the output is direct color (truecolor or highcolor), chunky or planar, and you need to perform clipping yourself, too.

As said earlier, I would suggest to look into DoHookClipRects() as this call at least provides you with the infrastructure of splitting the (potential) blit into all the cliprects a particular rastport can have, and there are really multiple of them (visible but clipped, invisible, and superbitmap cliprects) and it is easy to miss some of them. This function at least gives a nice interface for walking all the cliprects.

Anyhow. The easiest approach is probably just to depend on some other package providing CPU blitting. All you need then is a way to find out whether a bitmaps can be put into FastRAM. For that, check whether the screen bitmap is in chip. If not so, you are safe. Otherwise, if it is in chip ram, allocate a (throwaway) bitmap as invisible, non-displayable friend bitmap of the bitmap of the screen rastport. If that is in fast, you are also safe. If it is in chip, you need to put your bitmaps into chip as well.

[meynaf]

I think it may be better for me to just allocate some temporary chipmem area for copying the bitmap. If used with DrawImage calls rather than integrated into gadgets, it doesn't even need to stay there and i can recycle the buffer immediately afterwards.
This gives the extra benefit of removing alignment restrictions on bitplane data located inside of the program.