Get Real Max Pen Depending on Bitmap Depth

[AGS]

Hi,

I found out, that RPTAG_MaxPen in graphics library GetRPAttr() returns always 256 on my AGA system, also if the bitmap has only 2 planes.

So how can I get the real useable max pen? For 2 planes it should be 3, for 3 planes it should be 7 ...

i think it is ( 1 << depth ) - 1

but there might be another or more direct solution like reading the correct value from some system structure?

a

[thomas]

Why?

[AGS]

In my GUI I have built in the option to use less pens for drawing than the bitmap has to gain speed on classic screenmodes. The pens can be reduced to 4, 8 or 16 pens. But I get the colors to use with FindColor() and that needs a max pen. The Max Pen cannot be greater than the RPAttr Max Pen but also can not be greater than the number of Bitmap allows. So I now do it like this:

		move.l	gfxbase(pc),a6

		move.l	rp_BitMap(a1),a0
		moveq	#BMA_DEPTH,d1
		jsr	_LVOGetBitMapAttr(a6)

		moveq	#1,d1
		lsl.l	d0,d1
		subq.l	#1,d1
		move.l	d1,d2

		move.l	4(a7),a0	; rp a1 on stack

		clr.l	-(a7)	; TAG_END
		clr.l	-(a7)	; space for the return value
		move.l	a7,(a7)	; poiner to the sapce for the return value
		move.l	#RPTAG_MaxPen,-(a7)
		move.l	a7,a1

		jsr	_LVOGetRPAttrA(a6)

		addq.l	#4,a7
		move.l	(a7)+,d0
		cmp.l	d0,d2
		ble	.storemaxpen
		move.l 	d0,d2
.storemaxpen	move.l	d2,oxWin_screenmaxpen(a3)
		addq.l	#4,a7

[thomas]

IMHO you are thinking in the wrong direction.

Firstly I am quite sure we talked about RPTAG_MaxPen already and I told you that this is an attribute you have to *set*. You will always get the default value if you didn't set it to another one before. So in your routine above you can as well remove the call to GetRPAttrs because you always get the same value anyway.

Secondly reducing the number of pens to be searched by FindColor to something less than the number of colors in the palette will surely not give you the expected result.

Imagine a palette with 256 entries. It may have for example all shades of red in the first part, all shades of green in the middle part and all shades of blue in the last part. Now if you reduce the number of colors to be searched for example to 16, it will only ever find pens with red colors, even if the picture you want to draw only contains green colors.

You should rather optimize the palette to only contain as many entries as your bitmap has pens, then you can search the entire palette and find all kinds or colors.

And finally your attempt to reduce the number of pens does not gain anything. If you reduce the number of bitplanes in a bitmap, you reduce the amount of memory needed, but you do not gain speed. I assume that you are seeking for speed because you complained about flashing colors previously.

Colors are flashing if the logical blit operation has not finished before the bitmap data is read by the graphics chips to be displayed on the screen. It's even worth if the logical blit operation has to be split into multiple physical blit operations.

The number of physical blit operations necessary to execute a logical blit operation depends on the attributes of the destination bitmap and not less important on the differences between the attributes of the source and the destination bitmap.

If the depths of the source and the destination bitmap are different, then it always needs as many blit operations as the depth of the destination bitmap. This is because the bitplanes which are in the destination but not in the source have to be cleared in the destination bitmap. So the bilts have to be done anyway, no matter how few bitplanes your source bitmap has. The only exception might be if the destination rastport has MaxPen set to a lower value.

If the destination bitmap is interleaved, the best you can do is to make your source bitmap interleaved, too, with the same depth. Then and only then the logical blit can be executed by a single physical blit. This will reduce the flashing colors to a minimum. Likewise the worst thing you can do is to make your source bitmap have a different depth or to be not interleaved.

That's why AllocBitMap allows to specify a friend bitmap. If you specify a friend and the same depth as the friend, then your new bitmap will be optimized for blitting into the friend bitmap.

[AGS]

For my Doublebuffer Off-Canvas i always use FriendBitmap. An I can really notice increase in speed on my A4000 when I set smaller MaxPen value. Farther, I guess that the RPAttr Maxpen is different (not 256) on non-aga platforms.

The thing with the distribution of the colors in the colormap however is really a problem. With 4 pens it works here, because the first 4 entries seem to be always the typical amiga colors. The question is, how to reduce to 8 or 16 and get good colors anyway.

[thomas]

Originally Posted by AGS

I guess that the RPAttr Maxpen is different (not 256) on non-aga platforms.

No, you never get more than 256 pens.

[AGS]

Yes, I meant less.

[thomas]

non-AGA means ECS or OCS? I thought you meant RTG.

[AGS]

I thought of OCS.

Here is a little patch like solution for my color problem: A very often downloaded util from Aminet that puts the last four palette entries directly after the first four entries. In 8 color screenmode they are used to be there, but in more than 8 colors they are normally placed at the end of the pens list. I tried this patch and results were good. http://aminet.net/package/util/wb/256colour

[thomas]

Solution for what?

This software is obsolete. And a waste or four pens anyway. You better use MagicWB-Demon or FullPalette to set the four pens you wish.

Or use ObtainPen in your program to set the four desired pens exclusively for your use.

[AGS]

Ok, I think I use OptainPen() for the colors 4-7 for my 8 color-mode. There is just one open question: As 4 of my 8 colors have to be found in the entries 0-3, how do I know which of the 8 colors have to be allocated in 4-7?

[AGS]

Ok, I am using ObtainPen() now and at first run it works. But when I release the pens, system changes the colors of some of them and those pens are not available again for use in next run. I really tested it and traced it through. ReleasePen() does't seem to do what it should. This even happens when I obtain the pens in shared mode. The System seems to alloc the pens for something else as soon as I release them. But it doesn't do this before my first Obtain. Is there any known thing that I must take care of?

EDIT: I found the reason: The "StartMenu" thingy and "VisualPrefs" eat away my colors for nothing! Further I get my colors not every run and also sometimes partially. Obviously the system does something with them.

And I wonder why FullPalette doesn't show my colors as locked when my GUI is running.

[thomas]

That's why you're still doing it wrong. You cannot insist of using only the first 8 pens if the system offers you 256. You have to share the screen's pens with other programs and this means that there are situations where other programs have allocated these first 8 pens already and you have to use other pens. What if for example a user runs two of your programs at the same time?

[AGS]

Same time? Yes, I stumbled upon that. It's great, it's really great. Pens must be allocated centrally, not for just one app's window ... but recall, the 4 or 8 pens solution (while only 4-7 are obtained and the others are 'Found') is only a fallback function for those who want to try the GUI on slow systems. It is not intended for default use. I think I keep it. For any other cases I use ObtainBestPen() on the whole lot of colors.

[thomas]

You should reduce the number of blits, not the number of colors.

[AGS]

Any idea?

[mark_k]

If you're using Workbench 3.0 or later, the Workbench screen bitplanes will be interleaved, so reducing the number of planes written to won't really help. If you're opening your own custom screen then unless you specify SA_INTERLEAVED your screen won't be interleaved.

By the way, the Amiga Mail article IV-77: Optimized Window Refreshing might be worth a read. It's on the Amiga Developer CD.

[AGS]

Thanks, I think using ClipBlit() instead of ScrollRaster() in my Listviews can really help me on classic Amigas. I was able to detect a speedup with reducing the colors in 3.1 though.

[mark_k]

I might have been mistaken about reducing the number of planes to be written, where the destination bitmap is interleaved. (There may still be a performance benefit in some cases.)

Another possible speed-up technique could be to use ScrollRasterBF() instead of ScrollRaster(), though that requires Kickstart 3.0 or later. You can use a dummy backfill hook which does nothing to avoid newly-exposed areas being erased unnecessarily.

The author of that Amiga Mail article is Martin Taillefer, who wrote the TurboText text editor. Presumably TurboText uses those techniques.

[AGS]

I now have built in a switch into the config editor: use clipblit or scrollraster. this will help checking out which one is faster.