Streetfighter 2 conversion for MSX

If I understood well the tool would convert a sprite into a list of "line chunks". Each line chunk would have an offset and length and must be set separately as the outi is sequencial not allowing jumps.

Is that correct ? If so this list could be a hell if the sprite uses a chess pattern, like "translucent" megadrive/genesis sprites like this one:

I mean, more holes, more offsets to write to 0x99 port.

Further, cpu can draw while blitter does cleanup in another frame, multiprocessing! you cant really do that. Because if you do this:
1. restore background behind player 1
2. at the same time paste the new movement position of player 1
then step 2 might be overwritten by step 1. You better wait till step 1 is done....
That is why hit suggested three (3) buffers!
I do not know the actual bandwidth for out but it must be at least 2,5 kb. So theoretically speaking, taken into account a character of 48x88 = 2112 bytes in size, you could restore the background and 'softblit' one (1) character at the same time in one (1) frame period. Two characters takes 2 frames, from there follows 30 fps. With a little overhead and music player and game AI a nice 20 fps seems feasible.
Another, more or less similar approach, with only HMMM copies could be as follows:
Spilt each character in horizontal byte aligned lines, and store those on 1 page. Keep in ram a list for which line goes where with using HMMM commands, and some "setpixel" commands to fill the edges (but only if and where required).
Again, with a vdp transfer speed of +/- 3684 bytes per frame, 20 fps seems theoretically feasible.
Though both methods work only well if the player character can only move per byte (2 pixels), obviously.

And for those semi transparent ('ditterfest') sprites hardware sprites would be the way to go.

And one more thing... I do not like a SF2 port.. I prefer something new.

@hit9918: A blitter copy is meant to be faster than a pixel by pixel copy.

@norakomi:

cpu port 98 is same speed as blitter copy.
blitter transparent draw is 3 times slower like blitter copy.

Starting out at a 3x advantage, the cpu can swallow quite some overhead showstoppers till getting as bad as blitter. AND with the cpu method, the blitter cleanup can go in parallel.
Arguments making it worth to try out.

I made a code sketch. You can run this with dummy data and then see.

	info stream:
	dw amount of chunks
	a chunk:
	dw offset, db chunk length

		;sp: point to chunk info stream
		;hl: vram pointer upper left corner
		;    upper two bits are in bank byte like in hardware
		;de': sprite image pointer upper left corner
		
	res 6,h : ld a,(bank) : out (0x99),a
	ld a,14+128 : out (0x99),a	;write r14

	exx
	ld c,0x98
	exx
	
	pop bc	;bc: amount of chunks
	
	;fix bc for djnz + dec c : jp p
	ld a,c : ld c,b : ld b,a	;b = low byte
	and a : jp nz,loop
	dec c				;fix hi counter
loop:

11	pop de				;offset
12	push de
12	add hl,de			
18	bit 6,h : jr nz,fixbank         ;h: bit 6 is carry
                                        
fbret:                                  
17	ld a,e : out (0x99),a           
25	ld a,d : or 64 : out (0x99),a	;set vram write
                                        
5	exx                             
11	pop hl				;again offset
12	add hl,de
10	ld d,h : ld e,l
23	dec sp : pop af : ld b,a	;length
	otir
	
5	exx
14	djnz loop
	dec c : jp p,loop
--
175	overhead per chunk like 8.33 otir = like 16.66 pixels



fixbank:
	res 6,h
	ld a,(bank) : inc a : ld (bank,a)
	out (0x99),a : ld a,14+128 : out (0x99),a ;write r14
	jp fbret

Still todo is the overhead of running a border pixels PSET stream. It can't be worse than this one.
MSX2 PSET code with command gear, anyone?

The fighter is 42 pixels wide. It got one chunk per line, two per line on the feet, averagely 1.5.

42 pixels + (16.66 pixel overhead * 1.5) = 67 pixels.

It is like 67 pixels copy. cpu copy is same speed as blitter copy.

cpu draw budget:
like 67 pixels copy. done!
blitter will be done wiping 42 pixels in parallel.

blitter draw bugdet:
wipe 42 pixels.
transparent draw 42 pixels = like (3*42) copy pixels = 126 pixels.

cpu result: like 67 pixels copy
blitter result: like 42 + 126 = 168 pixels copy, 2.5 times slower!!!

On the one hand, there is still PSET overhead to add,
on the other hand there is transparent pixels of the pic to sub,
because cpu does not need to draw those.
cpu coming out at a 2.5x advantage, not much can go wrong.

@retrocanada76, every second pixel transparent:
This is an example that totaly wrecks the engine. But is no argument against the engine.
Solutions:
do streetfighter instead alteredbeast
do those sprites with blitter
dont expect SNES performance

like this one: