Streetfighter 2 conversion for MSX

Page 5/17
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10

By retrocanada76

Champion (460)

retrocanada76's picture

26-10-2011, 19:55

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:

www.usgamingonline.com/NES%20Screenshots/ALTERED_033.jpg

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

By ARTRAG

Enlighted (6243)

ARTRAG's picture

26-10-2011, 20:35

Yes

By GhostwriterP

Champion (511)

GhostwriterP's picture

26-10-2011, 21:10

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.

By Ivan

Ascended (9115)

Ivan's picture

26-10-2011, 22:22

I prefer big sprites! I am sure that the game will be faster than the ZX Spectrum version by US Gold:

Zx Spectrum: Street Fighter 2

Anyway even with small sprites, SF2 is a master piece that deserves an MSX port!

By hit9918

Prophet (2867)

hit9918's picture

26-10-2011, 23:00


@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.

By retrocanada76

Champion (460)

retrocanada76's picture

26-10-2011, 23:09

1 chunk per line ? do your characters have arms, hands and attachments ? Don't forget the shoryuken fire and other special FX's. also when blanka electrifies it could be very bad for the chunk technique.

By hit9918

Prophet (2867)

hit9918's picture

26-10-2011, 23:09

@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
Smile

By norakomi

Paladin (992)

norakomi's picture

26-10-2011, 23:12

hit9918 proposed a very new and clever way to do transparent copy:

Develop a PC tool or whatever that, given a picture with transaprent background, pre-computes a list of offsets of vram addresses and a list of lengths able to "depict" the shape of the object you need to plot.
Use standard vram access (port 0x99) and outi (port 0x98) to "fill" the shape of teh object with its bitmap.

As you do not do any logical operation, you work almost at the full I/O speed between z80 and VRAM
The overhead is the continous computation and setting of vram addresses, that can be limited if the shape of the object is not so much irregular.

The idea is nice, even if it is a bit complex to be implemented as it needs an external tool, but it leaves the VDP engine free to work in parallel other copies.
I still don't see how you handle this when both players overlap each other:
www.hadoukenonline.com/wp-content/uploads//2008/11/akuma-ssf2thdr.jpg 4.bp.blogspot.com/-lLIbCGzjzKo/TZwGEeTKauI/AAAAAAAABMA/LHT0skF-Yuk/s1600/streetfighter2chunli.jpg
In this situation you need to first restore background behind BOTH players in your buffer, before you paste both players in your buffer.
If you handle each player individually then you end up corrupting part of player 1 when restoring background behind player 2. Right ?

By retrocanada76

Champion (460)

retrocanada76's picture

26-10-2011, 23:13

like this one:

1.bp.blogspot.com/_lJrjBIcUXQM/SmLFWLaIv7I/AAAAAAAAAJQ/gWyykZQnW3M/s320/SF2-2.png

By retrocanada76

Champion (460)

retrocanada76's picture

26-10-2011, 23:15

we have to agree the MSX sucks with blitter. The game could end like the YS3 with a incredible 1/2 frame per sec...

Page 5/17
1 | 2 | 3 | 4 | | 6 | 7 | 8 | 9 | 10