[hatari-devel] Hatari patches for bitplane conversion

[Eero Tamminen]

Hi,

On Saturday 25 July 2009, Kåre Andersen wrote:
> I think the overlay code needs to track its own blit rectangles tho.
> Quickly skimming the statusbar.c source gives me the understanding
> that it handles its own blits. Want me to coordinate these? Currently
> we have SDL_UpdateRects() with 1 rectangle hardcoded - it could easily
> be made to keep track of several rects and blit them in one go by
> doing some bounding box calculations to see if we are already blitting
> the overlay area, touching the last line when statusbar needs update
> etc...

Blitting isn't the problem.

The (performance) problem is that unless there's a way to force the
convertors to rewrite certain lines / areas of screen (even in updates-only
mode) when needed, the area below LED also needs to be backed up and
restored for *each* frame.  This is needed because currently convertors can
do their drawing in a way that will only partly cover the LED  (even knowing
it afterwards doesn't really help) and you can't handle that in any other
way unfortunately.

This takes 20-25% of Hatari CPU usage when no frameskip is used although
the size of the area is minuscule (I think it's because of the copy from HW
surface).


> On Sat, Jul 25, 2009 at 1:44 PM, Eero Tamminen<eerot at users.berlios.de> > 
And yes, spectrum mode will be integrated. Makes no sense to keep
> using the old converters there alone. Some comment suggested using
> spectrum mode in all cases, and that might be a good idea considering
> its more like the real hardware - but it depends, of course, on the
> overhead incurred. And also, the extended VDI modes will get the
> treatment. And TT modes. And Videl stuff. Looks like i have a lot of
> work in front of me, provided you guys want it of course. :)

Regarding AdjustLinePaletteRemap() function called before converting
each of the lines, which tells in addition to memcmp() whether the line
needs to be converted...

It unconditionally copies the HBL palette to STRGBPalette[] and checks from
HBLPaletteMasks[y] whether that line needs updating because of palette
changes.

I think it would be more readable and faster to have in screen.h:
static inline Screen_LineChanged(int y)
{
	return HBLPaletteMasks[y];
}

And remove the return value from AdjustLinePaletteRemap().
The function could also be renamed to Screen_AdjustLinePalette().

Conversion function would then look like this:
	update = Screen_LineChanged(y) || memcmp(...);
	if (!update) {
		...
		continue;
	}
	Screen_AdjustLinePalette(y);
	/* convert line */
	for (x = 0; ...; ..) {
		...
	}


Hm. Once the convertors have been change to compare & convert line at
the time (instead every word), I can force the overlay LED area re-draw
simply with:
static void Screen_SetFullUpdateMaskRange(int y1, int y2)
{
	while (y1 <= y2)
		HBLPaletteMasks[y1++] |= PALETTEMASK_UPDATEFULL;
}
static void Screen_SetFullUpdateMask(void)
{
	Screen_SetFullUpdateRange(0, NUM_VISIBLE_LINES);
}


> Regarding the names shifter.[ch], in real STs and TTs, the SHIFTER is
> the decoder from bitplanes to analog RGB data, while the MMU and GLUE
> are handling the register stuff. So i dont think its that far off...

Fair enough, but Hatari Shifter handling is in video.c.

Also, as the files handle only certain (target) bit-depth, that should be
in the file name too.  Maybe convert/32bit.c?


	- Eero