From: | David McMinn |
Date: | 29 May 2001 at 19:10:57 |
Subject: | Re: Merging Backgrounds |
Hi Jason
> I have a background set up on one screen and a foreground
> set up on another, I need a way to somehow merge the foreground
> graphics on top of the backround, kind of like DPaint's merge in front tool.
Is it actually a screen you want to copy? Or just a bitmap? And would
this be in Blitz mode or not?
> I would really like to copy the screen as a whole and not blit
> individual sections of it onto the backround but it must be done
> reasonably quickly. I initially thought that I might be able to use the scroll
> command to copy the contents over from one screen to another but the
> transparent parts of the foreground (colour 0) are not transparent so they
> do not let the background show through them. Can I change the way scrolls
> are performed to allow colour 0 to be transparent?
The problem for that is you also need a mask (which is a one bitplane
image to show where the foreground should be drawn). You'll need to
generate this mask, as bitmaps do not have these by default (shapes do
though).
The easiest way I can think of using existing commands in Blitz is this
(watch out for line wrap and textstyles):
; You need amigalibs.res and bb2objtypes.res included in the compiler
; options
; Instead of "BitMap bmp,w,h,d" we're gonna make our own
; wdth, hght, dpth are the width, height and depth of your bitmaps
fg_bmp.l=AllocVec_((((wdth+15)&$FFF0)lsr3)*hght*dpth,
#MEMF_CLEAR|#MEMF_PUBLIC|#MEMF_CHIP)
; If you are using Blitz mode do the previous two lines before entering it
If fg_bmp
fg.w = 0
CludgeBitMap fg,wdth,hght,dpth,fg_bmp
fg_shp.w = 69 ; just some number that ain't being used by anything
; Here's some kuldgery-pokery fun :)
; NEVER FREE THIS SHAPE!!!!!!!!
*fgs.shape = Addr Shape(fg_shape)
*fgs\_pixwidth = wdth
*fgs\_pixheight = hght
*fgs\_depth = dpth
*fgs\_ebwidth = ((wdth+15)&$FFF0)lsr3
*fgs\_bltsize = (*fgs\_pixheight&$FFC0)lsl6 + ((*fgs\_ebwidth/2+1)&$3F)
*fgs\_xhandle = 0
*fgs\_yhandle = 0
*fgs\_data = fg_bmp
*fgs\_cookie = 0
*fgs\_onebpmem = *fgs\_ebwidth * *fgs\_pixheight
*fgs\_onebpmemx = (*fgs\_ebwidth + 2)* *fgs\_pixheight
*fgs\_allbpmem = *fgs\_onebpmem * *fgs\_depth
*fgs\_allbpmemx = *fgs\_onebpmemx * *fgs\_depth
; You can blit as you normally would to the bitmap.
; When you want to blit the foreground onto the background, do this:
MakeCookie fg_shp
Use BitMap bg
Blit fg_shp,0,0
; At the end of the program, do this or die in guru hell!
; (Do this when you free the bitmap too.)
FillMem Addr Shape(fg_shp),SizeOf.shape,0
; RIAmosFuncLib command
EndIf
; Do the next bit after you come out of Blitz mode
If fg_bmp : FreeVec_ fg_bmp : fg_bmp = 0 : EndIf
End
Of course, this doesn't take double buffered displays into account, but
you should be able to modify it easily. Oh, and I've never tested it, so
I don't know if it works. Or how fast, but that will depend on the size
of the bitmap and how often you need to do a MakeCookie (i.e. if your
foreground never changes, you only need to do it once, but if it changes
every time round a loop, you must do a MakeCookie every time round the
loop).
My guess is that it would be pretty slow (a single MakeCookie command
needs to read 8 bitplanes [assuming the depth of your bitmap is 8] and
write 1 bitplane). I'd guess it uses the blitter (therefore also chipmem)
which would make it stop your program while it works. Actually, if it did
use the blitter and you had an 8 bitplane bitmap, it would need to read
11 bitplanes (8 planes + read mask 3 times) and write to the mask
bitplane 4 times. The blitter runs at a clock cycle of 1/7.09MHz = 140ns
and each blitter operation needs a number of clock cycles (called ticks
here and in the RKRMs). So assuming a 320x256x8 foreground bitmap, it
will take:
30 ticks (the minimum I could work out)* 20 (words per line) * 256
(lines) * 140ns = 21.504 milliseconds.
Which at 50 frames per second is a whole frame (and a bit). And that
doesn't include any time it takes for the blitter to logically OR the
data together at each stage (tho' I'm not sure if that takes any
measurable time). This also doesn't include any time taken by the CPU to
do the function calls and set up the blitter. And it also doesn't include
any time take by other DMA processes (sound, disk drive, etc).
There are a few tricks you can use to give your program a higher
throughput or make it run a bit faster (the first would be make sure you
don't call MakeCookie every time round a loop :). If you want the ideas,
tell me and I'll send a list (didn't want to make this mail any longer
:). They'll mostly be based on writing your own assembly language
routines to replace some of the Blitz ones though.
---------------------------------------------------------------------
To unsubscribe, e-mail: blitz-list-unsubscribe@netsoc.ucd.ie
For additional commands, e-mail: blitz-list-help@netsoc.ucd.ie