TS2068 GFX speed-up

[stefano]

It took me very long to trace the Dominic's efforts in creating a common graphics library for the ZX Spectrum supersets (TS2068, SAM and Next).
It is an ambitious idea, but I must admit it is totally feasible.
Given the many options, (fat pixels, color support, various display modes) I decided to begin recovering the TS2068 portions trying to gradually improve the codebase up to an acceptable level.
I now have invazion.c and xample.c helping a little in testing the result, they are definitely a good benchmark for putsprite() and clga().

I'm tempted not to fatten the sprites when fat_pixel is enabled, they can be easily redrawn (with the sprite editor) and the results look very interesting already!

https://github.com/z88dk/z88dk-ext/blob ... invazion.c

invazion.png

[stefano]

This is something I left half way and this is bad
The current ZX Next library is now buggy, the colour attributes handling tend to overflow in the traditional video modes (only when the pictures get close to the rightmost display edge).
I'll test it soon and give a more detailed report, then I'll try to spot the bug, I suppose this has to do with a workaround I had introduced in the high resolution driver for the ts2068, where the attributes weren't altered.

[stefano]

The test is very simple, just change to +ts2068. If you move your spaceship to the rightmost positions the game crashes.
I *think* the problem is on how hl_inc_x_MODE6 works when used by w_putsprite.

[stefano]

This is odd, the game on the TS2068 crashes in 256x192 display mode also if I edit w_putsprite and stick the normal putsprite (with the following small adjustment):

Code: Select all

(...)
    push    af
    ;ld      h, a
    ;ld      l, e
	ld	h,0
	ld l,a
	ld d,0
    call    swapgfxbk
    call    w_pixeladdress

Moving on, I'll try by excluding game portions to spot the offending function.

[stefano]

I finally spotted the culript, it is clga().
Well it confirms that the updated putsprite for enhanced ZX Spectrum models with extended video works (yet just partially tested), deals with colours and is reasonably fast.

[stefano]

The code is cumbersome but the problem is elsewhere, the game when built for the TS2068 runs in standard screen mode, but the "fatpix" attribute is not reset. This doubles the area to be cleaned and causes the overflow.
I noticed I had already excluded the management of the fatpix attribute in w_putsprite, so I'm going to do the same on clga as a temporary fix.

[stefano]

I left this library dormant for such a long period I had to dig into the code to remember what happened.

Originally w_putsprite and w_clga were just absent. The default generic ones allowed a slow but effective result in all the display modes sorted by plotpixel.

I recovered the parked functions which were optimized for the ts2068 and expanded them to work with the standard ZX display mode, but I had to temporarily disable the fatpixel mode because it gets triggered also in standard video mode. Workarounds are possible but it's better to have it sorted properly.

Now a ts2068 works fine in both classic or hrg, the zxn target shas its local version of the .lst file and keep the original behaviour, I should check the Sam variant.

To be done:
Check/extend to SAM/ZX Next
Fix fatpixel
Remove redundant subroutines (inc_y, inc_x for de, etc..) w_xorclga and filled rect area fn
Color attributes to be checked in standard mode

[stefano]

I managed to solve most of the problems on the rect area functions (w_xorclga, w_clga, w_fillb).
For what I could observe timex_zxn_graphics.lst is included in the TS2068 and in the ZXN targets, which means that fixing w_putsprite is a priority.

As a workaround, "fatpixel" is now forcefully disabled if a "rect area" function is called when the display is in mode0 (it should now work correctly with the other video modes), I also noticed that SAM Coupè has its own set_fatpix() function, probably we have something to sort there as well.

EDIT: the color attributes in mode0 runs ok, w_putsprite() avoids filling the rightmost edge if it's only partially used. There is no ideal way to avoid the colour clash, this is the fastest option. The hl_inc_x variant is different than the one we use for the "stencils", this must be checked as well.

I'm sorry for the blog approach I'm following, it's mostly a way to motivate myself
This stuff got rather complex, I prefer to proceed by small steps.

[stefano]

Ok, things weren't that bad, the ZX Next was already mostly working.
My updated merge for w_putsprite is now slightly off when coloring the areas in standard mode and does not apply the fatpixel effect when in MODE 6, but overall it tests good.
The same code supports modes 0 and 6 and is reasonably fast, the other modes still rely on __generic_putsprite. SAM Coupè is not affected by the changes.

The only critical issue was on the clga()/fillb() functions because of the persistent fatpixel flag also when not appropriate. As said it is now fixed.