Prevent intuition/OpenScreen from clearing custom bitmap?

[dalton]

Hi,

I have some troubles creating a screen from a picture I have prepared beforehand in chip ram.

It seems to me that OpenScreen actually clears the bitmap. I'm aware of the SCREENQUIET flag which prevents drawing of the title bar. But is there anyway to prevent clearing of the bitmap?

Cheers

[Samurai_Crow]

If you have your bitmap structure set up and initialize a rastport for it, I think you can pass the rastport to openscreen on Kickstart version 2+.

[Leffmann]

One of the fields in the BitMap or NewScreen structs are probably initialized wrong. Have you specified BMF_DISPLAYABLE in BitMap.Flags, and CUSTOMBITMAP in NewScreen.Type?

EDIT: for a 320*256 interleaved bitmap in 32 colors:

struct BitMap bmp = {
  .BytesPerRow = 200,
  .Rows = 256,
  .Depth = 5,
  .Planes[0] = Picture,
  .Planes[1] = Picture+40,
  .Planes[2] = Picture+80,
  .Planes[3] = Picture+120,
  .Planes[4] = Picture+160,
  .Flags = BMF_DISPLAYABLE|BMF_INTERLEAVED,
  .pad = 0
};

struct NewScreen newscr = {
  .LeftEdge = 0, .TopEdge = 0,
  .Width = 320, .Height = 256,
  .Depth = 5,
  .CustomBitMap = &bmp,
  .ViewModes = 0,
  .Type = CUSTOMSCREEN|CUSTOMBITMAP|SCREENQUIET,
  .DefaultTitle = NULL, .Font = NULL, .Gadgets = NULL
};

[dalton]

That's very similar to what I have. I'm trying to display a picture which is four bitplanes interleaved. Hires.

But just comes out black If I use AllocBitmap and copy my picture to that bitmap after opening the screen, it works.

	extern UBYTE picture[256][4][80];

	struct NewScreen new_screen =
	{
		.LeftEdge = 0,
		.TopEdge = 0,
		.Width = 640,
		.Height = 256,
		.Depth = 4,
		.DetailPen = DETAILPEN,
		.BlockPen = BLOCKPEN,
		.ViewModes = HIRES,
		.Type = CUSTOMSCREEN | CUSTOMBITMAP | SCREENQUIET,
		.Font = &(struct TextAttr)
		{
			.ta_Name = "topaz.font",
			.ta_YSize = 8,
			.ta_Style = 0,
			.ta_Flags = 0,
		},
		.DefaultTitle = "My screen", 
		.Gadgets = NULL,
		.CustomBitMap = &(struct BitMap)
		{
			.BytesPerRow = 80*4,
			.Rows = 256,
			.Flags = BMF_DISPLAYABLE | BMF_INTERLEAVED,
			.Depth = 4,
			.pad = 0,
			.Planes =
			{
				picture[0][0],
				picture[0][1],
				picture[0][2],
				picture[0][3],
			},
		},
	};

	struct Screen *screen = OpenScreen(&new_screen);

[dalton]

Gah, found the problem, sorry! I'm opening a window right after opening the screen (to capture key strokes). The window hides the picture.

	struct NewWindow new_window =
	{
		0, 10,			// LeftEdge, TopEdge
		640, 256-10,	// Width, Height
		1, 0,			// DetailPen, BlockPen
		/*IDCMP_MOUSEMOVE | IDCMP_DELTAMOVE | */IDCMP_VANILLAKEY,	// IDCMPFlags
		WFLG_SIMPLE_REFRESH /* | WFLG_BACKDROP | WFLG_REPORTMOUSE */ | WFLG_BORDERLESS
			| WFLG_ACTIVATE | WFLG_RMBTRAP | WFLG_NOCAREREFRESH,
		NULL,		// FirstGadget
		NULL,		// CheckMark
		NULL,		// Title
		screen,		// Screen
		NULL,		// BitMap
		0, 0,		// MinWidth, MinHeight
		0, 0,		// MaxWidth, MaxHeight
		CUSTOMSCREEN
	};

This raises the question: can I have a window without covering the screen?

[Asman]

Originally Posted by dalton

This raises the question: can I have a window without covering the screen?

Did you tried to set window tag WA_CustomScreen ( NewWindow.Screen ) with your Screen ?
Mean you first open screen and then open window and above tag is set to proper valule.

[ReadOnlyCat]

Originally Posted by dalton

This raises the question: can I have a window without covering the screen?

Yes, the 2.0 Workbench where the window can be transformed from backdrop to resizable is an illustration of it if I recall correctly. This was not possible with the 1.3 Kickstart I believe.

However I cannot recall whether a windowless screen is capable of preserving the parts of its background which are covered by windows. I am under the impression that only windows which are flagged with

BITMAP<something>

(or

<something>BITMAP

) can survive being covered by other windows but I am not too sure screens are capable of similar feats.

I seem to recall reading that one explicitly had to use a backdrop borderless window with aforementioned

BITMAPstuff

flag in order to be able to preserve a screen's background. But if I were you i would not rely on such an unreliable source of information as my memory.

This said, I am 100% confident that this information is covered in the RKMs.

Update: I gave a quick look at the Graphics data structures and the corresponding Intuition ones (

Screen

notably) and I am fairly confident that screens bitmaps are not preserved when covered by overlapping windows. The

Bitmap

field of the

Screen

structure is a copy of the one held by the graphics.library's for the corresponding screen but there are no fields which could hold the overlapped contents.
If you want to preserve the background bitmap you need a backdrop borderless

SUPERBITMAP

window. (So,

<something> = SUPER

)

However, it is not clear whether the creation of that window will result in the erasing of your screen content. You will have to try.

Update2: You can create a 1x1 pixel window to work around potential clearing, but now that I am digging deeper in my memories of the system I kinda recall that it's possible to have a window without bitmap which is used only to intercept user input. Once again, please verify in the RKMs, I am really not certain of that one.

[thomas]

Originally Posted by dalton

Gah, found the problem, sorry! I'm opening a window right after opening the screen (to capture key strokes). The window hides the picture.

This raises the question: can I have a window without covering the screen?

In 2.0 and above you could set the WA_BackFill tag to LAYERS_NOBACKFILL, then the window will be transparent. But this does not work in 1.3.

Another possible way is to open the screen without a custom bitmap, put your image into the NewWindow.Bitmap field and set the WFLG_SUPER_BITMAP flag.

Or just open the screen, open the window and BltBitMapRastPort your image into the window.

[dalton]

Solved it now using the SUPER_BITMAP flag of the window. I create a bitmap struct for the window which is identical to that of the screen, but its pointers are set to row 11 of the picture rather than row 0. Then I set the window to begin at row 11 of the screen and cover the entire width down to the bottom of the screen.

So basically the window draws on top of the screen, but it uses the same data so there's no visible difference

Thanks for all your replies!