Streetfighter 2 conversion for MSX | MSX Resource Center (ページ 9/17)

Prophet (3659)

03-11-2011, 22:59

That probably because only mode-0 is fully depending on the vdp, all the others are slowed down by the cpu, either by overhead (filling the regs) or simply the outing.

That means some interesting possibilities: If the sprites show no performance impact, they can be used both to draw some parts of the player (feet and head i.e., to reduce it's height) and also the hadouken-like sprites.

By GhostwriterP

Paladin (683)

03-11-2011, 23:04

Or use sprites for the extra detail (tpset dots).

Though that could cause funny effects in player sprite priority order. No I think we better stick to just the soft sprites.
I will see if I can optimize the mode 4 blit routine, as this is probably the easiest routine.
I must and will get the 30 fps with the z80! (not aiming to high this time I hope)

By pitpan

Prophet (3155)

04-11-2011, 07:41

And what about small sprites, no background and fast action? Sounds feasible for regular MSX2, doesn't it?

By norakomi

Paragon (1140)

04-11-2011, 09:22

I like what you did in mode 5 and 6, but i think the background area is just too small.
If players would only move horizontally then this would be a perfect way to add scroll,
but since they characters are fairly big and jump very high i don't think background scrolling (in this way)
is a good idea.
You also said that the background scroll finishes later (it's behind), how much of a problem is this to you ?

@pitpan, no background at all would look bad ^__^

About color usage... It would not even be a bad idea to use only 3 colors for the background,
so both players can have a lot of colors for themselves....

By hit9918

Prophet (2932)

04-11-2011, 13:31

I must and will get the 30 fps with the z80! (not aiming to high this time I hope)

Go on aiming high!

The scroller was a big surprise! As far as this has gotten, I would hunt for the arcade gameplay with being able to walk horizontal!

The game is practically done. Except the problem that the blitter cannot blit oversize pictures.

Brainstorming: blitter does 156 pixels at the center, cpu blits 100 pixels on the borders.
With the blitter banging at the screen borders, this gives like a 356 pixel wide screen,
1.4 screens wide streetfighter.
Vertical motion comes at no cost.

By syn

Prophet (2123)

04-11-2011, 17:07

even the small sprites look too big! but maybe cuz they are too wide/fat you could go with even smaller sprites for ryu/ken/chun/guile etc and use the current size for the BIG characters like zangief/sagat/bison/vega/honda etc.

Anyway nice work!

By ARTRAG

Enlighted (6935)

04-11-2011, 19:54

@GhostwriterP
IMHO mode 4 with small sprites seems the best candidate for a true development (anyway larger sprites will be needed for some frames and other enemies).

Anyway, please cosider my remark about undue vdp access:
Now in mode 2 you are setting all vdp registers each time you do a HMMM
This is a HUGE waste of time on TR, as each time you access to vdp ports, the R800 gets halted for a lot of cycles (iirc 55 cycles)
This aspect is also emulated
Note that each time you copy an horizontal slice:
- the dy register is automatically incremented to the rigth position of the next slice
- the sy register is automatically incremented to the rigth position of the next slice if they are stored alligned
- the sx register stays rigth if slices are stored left alligned
- almost all another registers stay unchaged (there is no need to update the upper part of all the registers)
- you can point R#17 to the command register in order to save an extra out

do this and you will see mode 2 as fast as mode 4

By GhostwriterP

Paladin (683)

04-11-2011, 20:52

I like what you did in mode 5 and 6, but i think the background area is just too small.
If players would only move horizontally then this would be a perfect way to add scroll,
but since they characters are fairly big and jump very high i don't think background scrolling (in this way) is a good idea.
I do not think you fully grasp the idea here. Adding vertical scroll is also very easy. These modes work with triple buffer (i.e. using 3 screens) this means we have one screen of 256x256 pixels for the stage environment. With the mode 5 & 6 technique you can 'scroll' freely over that, by means of one simple copy instruction.
You also said that the background scroll finishes later (it's behind), how much of a problem is this to you ?
Actually it starts later. When you start the scroll it takes 1 frame before you can see it. It is due the triple buffers. In the conventional way you first restore the background and than copy the new sprites over it on the same buffer, and subsequently show that buffer. In mode 5 & 6 we see buffer [0], restore buffer [2] and softblit the sprites on buffer [1]. Next we show buffer [1], restore buffer [0], and softblit the sprites on buffer [2]. Then we show buffer [2] and at this point we see the scroll.
Does it bother me you ask? I do not know, probably look a bit funny. But you might be able to camouflage it by adding some additional shakiness, as the fight is filmed by a supporter with a handy cam (instead of steady cam)

@ARTRAG
Yes, I do see some potential gain, I will see if I can implement it. BTW does blue emulate this correctly or should I use open to test it.

By ARTRAG

Enlighted (6935)

04-11-2011, 21:21

Yes it is emulated by both blue and open

By norakomi

Paragon (1140)

04-11-2011, 22:05

I do not think you fully grasp the idea here. Adding vertical scroll is also very easy. These modes work with triple buffer (i.e. using 3 screens) this means we have one screen of 256x256 pixels for the stage environment. With the mode 5 & 6 technique you can 'scroll' freely over that, by means of one simple copy instruction.yeah but what if 1 player jumps and the other player stands still... does your camera move up ? or stay still ? and will you still be able to see both players ?
the scrolling area has to be very very big then ??? sure you can also scroll vertically, but the size of your scrolling area HAS to be big... bigger then in your example..... dont you think ?