Street Fighter 2 - MSX - Who plays this game ?

Pagina 6/8
1 | 2 | 3 | 4 | 5 | | 7 | 8

Van iamweasel2

Paladin (678)

afbeelding van iamweasel2

21-03-2021, 13:49

Grauw wrote:

Don’t worry iamweasel2, I read your message the way you intended: The game doesn’t need to be an exact clone Smile.

GhostwriterP: Cool stuff, thanks!

Thanks, written messages sometimes can be hard to understand.

Anyway, being a coder too, I can say that whatever path the developer decides to choose to this game, I'll respect and buy the game, as I said before. But I really wish he can bring something different to make the MSX port unique, of course it can be something small, it doesn't need to be in the Monty Python way ("and now for something completely different"). Tongue

Van Grauw

Ascended (9824)

afbeelding van Grauw

21-03-2021, 14:13

GhostwriterP wrote:
Grauw wrote:

Was there a thread on msx.org about it or something? If so, got a link?

It is the same norakomi gave in the beginning.
But for anyone interested I placed the related test roms I could find in my archive on google drive (since old links will probably not work anymore) SF2
The sft.rom is the inital test covering different blitmodes (use space bar to step through the different modes and enter to toggle character size) see text file for some details.
In sfighter.rom there are two modes, static background and scrolling (toggle with space)
In sf2.rom you can move ryu with left and right and chun li with up and down (use lot of blur too smooth out the dittering)

I read the thread and it’s a nice approach with the line list! The extra (relatively low) overhead of writing bitmap data with the CPU is compensated by not having to blit the transparent pixels in a square area. I wonder if IN (98H) was used to skip over pixels in the empty spaces between blits? Could be faster than setting a new VRAM address when there are only a couple transparent pixels, though maybe not worth the hassle in the big picture.

It’s definitely a technique I will have to keep in mind for future projects if I want to render large bitmapped characters. People focus too much on VDP commands while CPU drawing has a lot of potential. In my tiletile engine I switched to CPU drawing for the background tiles, which is equally fast for smaller copies and can use unlimited ROM space for the tiles. And in a 3D rendering project I used line segments to describe full-screen frames, and calculating the delta between two to only draw the pixels affected. Could be used to make STNICCC2000 for MSX.

p.s. Looks like hit9918 and ARTRAG also deserve some credit for the ideas :). Where’s hit9918 lately, I miss having him around with his unconventional ideas!

Van Sandy Brand

Master (229)

afbeelding van Sandy Brand

21-03-2021, 13:59

I think these are excellent case studies to show the power of a machine by actually trying to port a real-world product to an older platform and compare them.

I would even argue that this is at the same level of demo-coding: it shows how clever coding can by-pass perceived limitations. What's not to like about that? Smile

Van GhostwriterP

Hero (590)

afbeelding van GhostwriterP

21-03-2021, 14:21

Grauw wrote:

it’s a nice approach with the line list

Indeed, and the fun part is there is also a bit of compression on the sprite data which does not even require extra time decoding Smile

Grauw wrote:

I wonder if IN was used to skip over pixels in the empty spaces between blits?

I do not remember all the details, but briefly looked at it... I think. As far as I do remember using IN to skip adds a additional condition to check in the stream as it also will slowdown for other conditions and benefit may be gone or worse... Wink

Van Grauw

Ascended (9824)

afbeelding van Grauw

21-03-2021, 14:34

That makes sense. Maybe if the code for each animation frame would be generated.

Van journey

Hero (515)

afbeelding van journey

21-03-2021, 14:50

journey wrote:
norakomi wrote:

I worked several months on it, and got to this point:
Downloadable Rom:
https://www.dropbox.com/s/1mzs4ia5itikril/streetfighter.rom?dl=0

I've tried the rom with MFRSCC+ RomType AUTO (SCC type).

Is it normal that the opponent is always "garbage"?

AH, I've also tried the game with MIDI-PAC V2. WOW!!!!!

Ok, with Zemmix Neo no problem...

Van GhostwriterP

Hero (590)

afbeelding van GhostwriterP

21-03-2021, 14:52

Grauw wrote:

That makes sense. Maybe if the code for each animation frame would be generated.

Me like that approach Smile, with embedded data (i.e. ld hl,sliceaddress instead of pop hl, or if h does not change save some cycles there too) could potentially speed up on R800 quite a bit.

However, when we bring sprite clipping in the mix that could become really challenging, as I remember clearly from those days that is already quite complicated enough. As results sprites are limited to 128 pixel wide and each clipping left right up down (and diagonal cases) have there own 'blitter' routine.

Van iamweasel2

Paladin (678)

afbeelding van iamweasel2

21-03-2021, 15:51

The crooked energy bar, was an artistic decision to not have a straight line energy bar or it was a requirement due to the way the engine works?

Van Sebbeug

Champion (314)

afbeelding van Sebbeug

21-03-2021, 19:18

I play Pointless Fighting regulary... Really...
I like SF3.3 on my arcade cabinet, probably the game i play most often.
And really, i like to launch pointless fighting with my Sega gamepad. too too funny !
Please finish this game, your work is so awesome !!!

Van Daemos

Paragon (1948)

afbeelding van Daemos

21-03-2021, 20:42

Pointless fighting is awesome and (I am serious) the intro screen is just awesome. When I saw it I could not stop laughing. I could imagine how some would find it funny and some would start complaining. It made the game legendary and to be eternally be remembered. However pointless fighting while being a very good game is not as complete as the original idea intended it. The time I guess has finally arrived for that idea to become reality.

Pagina 6/8
1 | 2 | 3 | 4 | 5 | | 7 | 8