Streetfighter 2 conversion for MSX

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

By wolf_

Ambassador_ (9774)

wolf_'s picture

27-10-2011, 12:30

Graphics9000

  • A cartridge that's been around since 1994/1995, with 32768 colors, multilayers, 125 multicolor sprites (and 16 on a row), omnidirectional scrolling, custom sprite/plane order, easy programming..
  • The ideal gaming videochip for MSX
  • Several hundreds have been sold, I believe

And no one seems to be using it ._.

By ARTRAG

Enlighted (6276)

ARTRAG's picture

27-10-2011, 13:16

IMHO it is doable on the v9938 with some restrictions
hit9918's idea of the "shaped" i/o using port 0x98 and GhostwriterP's proposal about slicing sprites in VRAM look very interesting.
In both cases one can store equal sgments only once
The latter lends itself to another optimization: fiting as many segments as you can in one line of 256 pixels without wasting pixels

By retrocanada76

Champion (463)

retrocanada76's picture

27-10-2011, 14:48

One question: is the scene going to scroll left and right ? I so this will be very hard to achieve.

By ARTRAG

Enlighted (6276)

ARTRAG's picture

27-10-2011, 19:07

Not with bitmap sprites...
On msx2 it would be simply impossible.
With HW sprites + (small) bitmap details it would be hard
With pure HW sprites it would be doable (see green beret demo) but not that appealing (at least as SF2 port I mean)

What about using lowres magnified sprites ?
The size of each player could be 64x128 (each line with 3 colors+ transparent)
The lowres look could be adopted as a style choice for the whole game

It could be very fun expecially if in this way we can have fluid animations (170 frames stored in VRAM), special effects, fast action and omnidiretional scrolling

By PingPong

Prophet (3459)

PingPong's picture

27-10-2011, 23:03

lowres sprites can be unaligned by 1 horizontal pixel. giving the illusion of higher resolution.
very tricky

By ARTRAG

Enlighted (6276)

ARTRAG's picture

27-10-2011, 23:26

lovely trick! converting bitmaps to hw sprites with this 1 pixel offset could need a very clever pc tool an a lot of handwork, but it is something that is worth a try
I would use a diagonal offset of 1 pixel so to increase both X an Y resolution

By GhostwriterP

Champion (511)

GhostwriterP's picture

02-11-2011, 23:12

Well, I did some experimentation and testing, waisted my weekend and two evenings in the process, and I combined the results in a nice rom image cq 'tech demo' to show off. Though, I cannot upload it at this time (maybe later or tomorrow), I can tell now it looks nice and just imagine Ken and Ryu bouncing left and right over the screen in front of a street fighter IV logo whilst reading on. Smile

It comprises of 7 blitmodes (actually only 3, being LMMM, HMMM and CPU), and two sizes of fighter sprites. The big fighters are 68 x 100 and 'smaller' ones are 56 x 88.

Between blitmodes can be swithed by pressing [space], and the size can be toggled by pressing [return].

On turbor the r800 will be enabled which will give some better results (on real machine less than on emulator). You can force the z80 mode by holding down [ESC] during rom boot.

The amount of interrupts it takes to update the screen is plotted on the lower left corner and represented by a equal number of white dots. This means to get the frame rate you have to count and then divide 60 by the number. For instance 3 dots is 60 / 3 = 20 fps.

So now that is cleared up lets start! Hannibal

Underneath is in short summarized what the different blit modes intent:

0 - Conventional blitting with vdp                   [double buffered] 
    
    2x HMMM command to restore background               (spr 1 & 2)
    2x LMMM command to blit sprites                     (spr 1 & 2)

1 - HMMM blitting with tpset                         [double buffered] 

    2x HMMM command to restore background               (spr 1 & 2)
    2x list of HMMM and PSET commands to blit sprites   (spr 1 & 2)

2 - HMMM blitting without tpset (loss of detail)     [double buffered] 

    2x 1 HMMM command to restore background             (spr 1 & 2)
    2x list of HMMM commands to blit sprites            (spr 1 & 2)

3 - CPU blitting with tpset                          [triple buffered]
    
    1x HMMM command to restore background                 (spr 1)
    -- CPU blitting (out) with read-in for 'tpset' bytes  (spr 1)
    1x HMMM command to restore background                 (spr 2)
    -- CPU blitting (out) with read-in for 'tpset' bytes  (spr 2)

4 - CPU blitting without tpset                       [triple buffered]

    1x HMMM command to restore background                 (spr 1)
    -- CPU blitting (out) no read-in for 'tpset' bytes    (spr 1)
    1x HMMM command to restore background                 (spr 2)
    -- CPU blitting (out) no read-in for 'tpset' bytes    (spr 2)

5 - CPU blitting with tpset                          [triple buffered]

    1x HMMM command to restore background  (14kb)       (spr 1 & 2)
    -- CPU blitting (out) with read-in for 'tpset' bytes  (spr 1)
    -- CPU blitting (out) with read-in for 'tpset' bytes  (spr 2)

6 - CPU blitting without tpset                       [triple buffered]

    1x HMMM command to restore background  (14kb)       (spr 1 & 2)
    -- CPU blitting (out) with read-in for 'tpset' bytes  (spr 1)
    -- CPU blitting (out) with read-in for 'tpset' bytes  (spr 2)

 - Modes 0 uses vram for the sprite bitmap data
 - Modes 1 to 2 use ram for the line (copy) lists & vram for the sprite bitmap data
 - Modes 3 to 6 use ram for both line (copy) lists and sprite bitmap data

I assume the above speaks for itself and does not require further explaination.

Let me talk you through some findings for a bit:

The nice thing about including 2 sprite sizes is that it becomes clear that mode 1 suffers from the huge amount of overhead and only increases the frame rate on the big sprites, in fact it even is slower than mode 0 with the small sprites. Going on to mode 2 resolves the overhead issue at cost of level of detail, but at least its faster again than mode 0 and mode 1.
Next is cpu blitting, mode 3 for instance is already quite a bit faster than mode 0. Mode 4 on its turn faster again, though, like in mode 2 with some loss of detail. Which strangely enough does not bother me that much those big sprites. One could actually consider colorspill at some points as I think a background often have one governing color.
Anyway, so far it all seams very promising (smaller sprites even hit the 30 fps on turbor), though we must not forget that now both cpu and vdp are fully occupied, and thats not the case for modes 0 up to mode 2. This means we would have only very limited time for the game engine.
So lets drop the frame rate whiles moving on to modes 5 & 6. The general idea of these modes are to completely restore the background of the game area. To do that with a decent frame rate, let us say 15 fps, the game area size is limitted by the vdp HMMM command. And for 15 fps it is (60/15) x 3.6 (HMMM @ 60hz) = 14.4 kb. The game area could then be for instance 200 x 140 (14kb). In mode 5 & 6 the game area is 224x128 for other reasons but the net area is approximately the same.
Now comes the fun part, since the background is updated completely this also means we can scroll a bit even whithout set adjust or hardware scroll. From blit mode 4 (and perhaps mode 3) we know that 'softblitting' the sprites (@ approx 20 fps) uses up about 3 interrupts, which means at 15 fps ( = 4 interrupts) at least 1 full interrupt is free for the game engine, player AI and such.
Down side of the scrolling is obviously that the scroll is alway 2 steps behind, but wo cares right! Wink

So this means a fighting game with relatively big fighters feasible at 15 fps on msx2.

On turbor (or even msx2+) 20 fps might be possible (using hardware scroll).

Disclaimer: Only tested it on real turbor, do not know what happens on a real msx2.

By Ivan

Ascended (9120)

Ivan's picture

02-11-2011, 23:22

oO oO oO I want that ROM image!!!

By ARTRAG

Enlighted (6276)

ARTRAG's picture

03-11-2011, 00:12

CAVEAT:
The turboR in R800 mode has a very nice "feauture" : running code from external roms will slow down the CPU at about 1/2 of its speed.

This not properly documented "feature" is almost unknown and not emulated (by bluemsx at least).

Try to move your code to RAM and redo the tests in R800 mode.
You will see what I mean.
(My raycasting engine passed from 10Fps to 20Fps when I moved it to ram)

By ARTRAG

Enlighted (6276)

ARTRAG's picture

03-11-2011, 01:41

Question: do you exploit tthe final value of vdp command registers to avoid undue vdp accesses?
On TR you can gain a lot of cpu time.
your results could impove a lot

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