Streetfighter 2 conversion for MSX

Página 3/17
1 | 2 | | 4 | 5 | 6 | 7 | 8

Por hit9918

Prophet (2932)

Imagen del hit9918

24-10-2011, 00:29

I wanted to suggest using vram as a cache.

A player can have hundreds pics, but only a fraction of that is "recently used", so the reload will not hurt framerate. Benefits of the cache:

All vram space fiddeling headache is gone SmileSmile
1 page vram cache, means: can have a 3rd background buffer, no more background save blit, BOB drawing speedup SmileSmile

The cache: let's divide a page into 4x4 pics, 16 pics. The cache got 16x this entry:

3 bytes ROM address of the pic (a 24bit mapper address)
2 bytes vram address of the cache position (or maybe 2 bytes x y coordinate for the blitter)

The ROM address is the unique id for the cache.
You could also have some different kind of id, like a 2 byte index to some tables.

Then just search thru all 16 entries. If found, you take the vram address and go.
If not found, then load the desired pic into one of the 16 cache positions. The position to pick is told by a counter that increments on every cache miss, round robin.

Whenever I said "16", this should be loaded from a "cachesize" variable to keep things tunable later. The slicing of the cache is contained in the "vram address" part, can also be changed later.

Limits of this setup: one pic is max 64x64 pixels size.
With more than 16 different pics "permanently in use" the speed may stall (or maybe not, see below).

sketching inner loop of the cache search:

	;a contains low byte of id
	;b is number of cache entries
8	cp (hl)			;hl->low byte of id
8	jr z,checkhibyte	;rarely called extra stuff
12	add hl,de		;de = 5, skip to next cache entry
14	djnz loop

42*16 = 3 rasterlines per sprite. And with 10 sprites the penalty is... 3 rasterlines Smile
Because z80 does something instead waiting for blitter painting that previous fat fighter, multiprocessor action Smile

Actually, z80 is faster in copying a BOB from .rom to vram cache than blitter drawing it onscreen (transparent blit, slowest mode). So z80 is doing something while blitter is running. Even permanent cache miss doesn't look like a desaster.

And if the cache turns out to do well, the cache loader could DECOMPRESS images from .rom Cool
Also kind of "decompress" would be the conversion from screen 5 pics to 16 color sprites format - no more "things stored 2x in the .rom".

Por Sarcasmic

Master (149)

Imagen del Sarcasmic

24-10-2011, 00:43

You should make a gfx dump from the original snes game in this way you will see how those sprites where made 16x16 tiles if you look in the original texture atlas you will see what i mean every charcher including chun lee is chopped up to save space.... ever tought of doing a copy mirrored instead of wasting 2 times as much data??

Por hit9918

Prophet (2932)

Imagen del hit9918

24-10-2011, 02:12

ever tought of doing a copy mirrored instead of wasting 2 times as much data??

Good point! The cache loader mirroring the image also kind of is "decompress ROM data".
I feel that your idea just somehow virtualy doubled the .rom size Big smile

In this case, the cache entry needs an update:

3 bytes ROM address
1 byte mirror info (like 0 = unflipped, 1 = flipped horizontal)

The pic comes from the same ROM address, but it is different (flipped).
A different thing needs a different id. So the mirror byte is part of the id.

Update about the vram pointer of the cache entry:

Port 99 setup only covers 16k. Need to set another vdp register to address 16k banks.
For speed, this value is better in a third byte.
Now things are more tidy because now you can allocate a cache tile anywhere in 128k.

Similar, there be 3 bytes to completely describe the same vram address to the blitter: x,y, and page number.

So a cache entry ends up like this:

--- id part
3 bytes ROM address
1 byte mirror info (like 0 = unflipped, 1 = flipped horizontal)
--- vram address part
3 bytes to describe it to port 99 gear
3 bytes to describe the same location to blitter gear

The id part in the cache entries change dynamic, the vram addresses are initialized one time at game start.

Por Sarcasmic

Master (149)

Imagen del Sarcasmic

24-10-2011, 02:14

I'm glad i maybe helped out some one with such simple solution Hannibal


Enlighted (6977)

Imagen del ARTRAG

24-10-2011, 08:42

don't you think that the gain from having a 3rd screen for restoring background is lost owing to the overhead of the cache management and update?
Consider that a sprite frame (32x64) takes about 256 (shapes)+128(colors) bytes, not a lot in the end.

I think there is a much simpler solution for this game:

Assume that the bitmap details are small and can fit all in one single page (it has to be the case, as sprites are already 32x64), say page 3
Use, as you say, page 2 for storing the background, so there is no need for extra copies for restoring the area where sw sprites appear.
Store data for HW sprites in ROM (as we said 64K give 170 frames, you can live with that Tongue)

Each frame:
Send vdp commands to restore the background in page 0 and 1 from page 2 and to copy the bitmap details
While the vdp works, use standard rom to vram transfer to update sprite definitions

This implies 2*384 bytes to be transferred by the z80 at each frame (two players) -> it can work even to 60Hz!

In ROM you can store as many sprites you like, in the 4th vram page, you can fit the bitmap details for those frames that do not fit in the 32x64 grid

For this game it can work, it is much simpler and without cache overhead

Por hit9918

Prophet (2932)

Imagen del hit9918

24-10-2011, 23:00

I guess your message was "I want both players with sprites".

I see the whole issue coming down to "30 fps streetfighter versus 60 fps streetfighter with reduced graphics".

A stunt palette was posted and I envision that palette getting damaged by 3color sprites.
Is there a screen 5 to 3color sprite converter? Or someone draw the 300 sprites?

A 32x64 pixel bob: LMMM 0.017s + HMMM 0.006s = 0.023s . The 30fps streetfighter would go with BOBs + a 32 pixel wide 16 color sprite band assisting. 16 color means no repainting of pics and no palette damage.

About the cache,

blitter HMMM copy 167040 byte/s
cpu outi 198333 bytes/s

cpu loads the image from ROM while blitter does the background cleanup copy LOL!
You still could have a cache for flipped images - in RAM LOL!

Por norakomi

Paragon (1150)

Imagen del norakomi

25-10-2011, 11:00

well to be honest...
I dont see a decent sf2 clone working on 60fps
maybe 15 or 20 fps is discussable...
im kinda losing hope of making a decent port........
the sprites are just too big to handle
I have been talking and thinking about it for the last few days,
I just dont see it happening on 30 fps, unless we reduce the spritesize immensely:
But is this really gonna be cool ?

this will look too much the already existing sf2 clone:

Por pitpan

Prophet (3156)

Imagen del pitpan

25-10-2011, 14:02

I'd gladly go for a *decent* MSX/MSX2 port of Gameboy Color STREET FIGHTER ALFA: fast paced action, smaller graphics, less animations and just two buttons but tons of fun and playability. I think that for this game speed is a must. Check it here.


Enlighted (6977)

Imagen del ARTRAG

25-10-2011, 14:19

what is the issue? The speed or the rom/ram/vram space needed for the frames?
The smaller player is a lot smaller than 32x64
Can you do a darft with the actual sizes ?

Por syn

Prophet (2135)

Imagen del syn

25-10-2011, 16:17

the question is do you really want to make an acurate port (graphics-wise/sprite size etc) or just a great 2d fighter/sf-esque game? If its the last option, you can go for smaller sprites and focus on the gameplay and overal smoothness. There have been a few great fighters with smaller sprites and it can work wel imho. Imho one of the best portable fighting games was SNK vs Capcom on the neo geo pocket Something like this should be doable on msx right? (obviously the sprites will look smaller on the msx.. I think they are like 16*16 or something, though I havent counted the pixels :) )

btw a bit offtopic, but since we were talking about 2d fighters with small sprites, do you know Card Sagas Wars? its a WIP fanmade/homebrew game with videogame characters from many different games. But unlike other fan dreammatch/vs games they dont use spriterips, instead all the art is original work!

Página 3/17
1 | 2 | | 4 | 5 | 6 | 7 | 8