Forums

Hello. Here's a suggestion for Ken's stage, inspired by the colors of the CPS2 version of Champion Edition.

I edited it from the last screenshot posted here. By the way, I'm not sure if this edit matches the SMS specs.

I'm also uploading an image showing the areas which were edited.

sms_sf2ce_ken.png (14.62 KB)

sms_sf2ce_ken_diff.png (4.21 KB)

I think the Genesis/MegaDrive has an orange sky, while the arcade and snes have a yellow sky.

So it's a matter of preference. Imho yellow looks a little better.

Well, the SMS version will always be different no matter what. The difference between both consoles is roughly the same (or more!) than the difference between the Genesis and the CPS1 arcade board.

The key is to make things just good enough to match the overall feeling of the original game, even if the details aren't the same.

Great work so far on improving the visuals of the game.

One quick confirmation though. I get it from working on MS/GG hardware that you cannot flip sprites. I guess that SFII confirms (as any other game) that all sprites are present in the ROM facing both directions ?

This would mean by definition that the MS requires quite a bit of ROM space for fighting games.

@cireza

Actually you can *easily* flip a sprites before uploading it in VRAM. Just a little LUT needed. It will take 2 times more cycles.

As the SMS can't flip by default these data, it can be a good choice to have both side different (like always have the sword or shield in the same hand) ;)

ichigobankai wrote

@cireza

Actually you can *easily* flip a sprites before uploading it in VRAM. Just a little LUT needed. It will take 2 times more cycles.

As the SMS can't flip by default these data, it can be a good choice to have both side different (like always have the sword or shield in the same hand) ;)

I don't want to derail the thread but I am curious. Can you flip a tile with a look-up table ? Meaning writing the rows of 8 pixels reversed ? If you have some examples or explanations of this, I would be curious (I don't actually need it, but I have starting looking at all MS/GG games trying to understand how they work since I began developing lol). Thanks :)

As an exercise, convert two 8x8 tiles with BMP2Tiles.

1 facing right, the other facing left (flipped),
check/compare binaries ;)
you'll find a 256 bytes LUT.

For performances (and simplicity), the LUT must be copied/aligned in RAM (at a clean address), like 0xD100.
Data will be readable from D100 to D1FF. As they are aligned you'll only have to update the LSB part of the address (00 - FF) to get the flipped value.

the LUT will look like this:
(asm, i've generated mine with few lines of C)
.db $00; $00
.db $80; $01
.db $40; $02
.db $C0; $03
.db $20; $04
.db $A0; $05
.db $60; $06
...
.db $3F; $FC
.db $BF; $FD
.db $7F; $FE
.db $FF; $FF

Then, the code itself to flip the tile
in ASM it will looks like that ;

HL = Source (tile data)
DE = LUT
ps. a tile is 32 bytes.
for performances - better to unroll the loop (= repeat 32 times = 1 tile).
...
ld e, (hl) ;7
ld a, (de) ;7
out(#0xBE), a ;11
inc hl ;6 //31 cycles
...

ichigobankai wrote

As an exercise, convert two 8x8 tiles with BMP2Tiles.
...

I think I get it, thanks for taking the time :)

mankrip wrote

Hello. Here's a suggestion for Ken's stage, inspired by the colors of the CPS2 version of Champion Edition.

I edited it from the last screenshot posted here. By the way, I'm not sure if this edit matches the SMS specs.

I'm also uploading an image showing the areas which were edited.

The release candidate for this hack had light yellow originally (Still available, if you want to play it that way). I received a few messages to have it changed to orange, because of various reasons. Someone even made a whole mock up like you did, but using orange. Each color blends in a bit, orange seemed closer to the source material, so it won out.

There are tools available on the first post of this topic that you can use to change the game graphics however you want it. Everyone has their preferences.

cireza wrote

Great work so far on improving the visuals of the game.

One quick confirmation though. I get it from working on MS/GG hardware that you cannot flip sprites. I guess that SFII confirms (as any other game) that all sprites are present in the ROM facing both directions ?

This would mean by definition that the MS requires quite a bit of ROM space for fighting games.

The rom only has left facing resources. They do dynamically flip the graphics it seems, but that's for the BG tiled fighter I believe (It's been awhile), as one is comprised of sprites, and the other is BG tile merged in software.

Derailments are welcomed, always something interesting that shows up, always something new to learn

Continuing with the derailment (sorry), one thing to consider is that ROM space is almost infinite nowadays, but CPU cycle aren't. So it's usually best to have the tiles flipped in rom already

kusfo wrote

Continuing with the derailment (sorry), one thing to consider is that ROM space is almost infinite nowadays, but CPU cycle aren't. So it's usually best to have the tiles flipped in rom already

quoting on this, because it's important. You can 'quickly' copy a few tiles to VRAM with a single OUTI block, it will cost 16 cycles/byte (devkitSMS' SMSlib supports this using the UNSAFE_SMS_load<n>Tile(s) functions) but if you choose to flip bytes it will take much more.

So, unless ROM size is an issue (for instance, you plan on releasing on a 32 KiB ROM cartridge with no mapper) then you'll find convenient to save CPU cycles for more important tasks.

Also, there are mappers that can do byte flipping (and I suspect it's not that hard to create a SEGA compatible mapper that supports this too)

its "only" 31 cycles vs. 16.
So takes 992 cycles for a complete flipped tiles instead of 512 with OUTIs.

adding this directly on the mapper could be a nice addition.
(there's few unused bits on some registers)

Since many month its hard to have electronic at decent price (talk about new parts, not aliexpress refurbished things). Some CPLD refs. are not available until... end of 2024. lol.

But honestly, filling a 512Kb rom is already a big challenge.

ichigobankai wrote

its "only" 31 cycles vs. 16.

yes, but again this means going from being able to stream 24 tiles in a single vblank at 60Hz to just 12 - so once more I think it can be either totally fine or totally unacceptable depending on the specific circumstances.

Exactly, really depends on circumstances/needs.

ichigobankai wrote

its "only" 31 cycles vs. 16.
So takes 992 cycles for a complete flipped tiles instead of 512 with OUTIs.

adding this directly on the mapper could be a nice addition.
(there's few unused bits on some registers)

Since many month its hard to have electronic at decent price (talk about new parts, not aliexpress refurbished things). Some CPLD refs. are not available until... end of 2024. lol.

But honestly, filling a 512Kb rom is already a big challenge.

Remember that we have 227 z80 clock cycles per horizontal scanline. The average instruction takes about 5-6 cycles, so you have about 32 instructions that can be executed in each scanline.

On the NES, limit pushers had to actually count clock cycles because they don't even have a scanline counter. It turns out, though, that fewer cycles are wasted than the SMS approach of using horizontal interrupts because of the overhead involved. In fact, I think that there are SMS demos where the Z80 just runs in parallel with the 14MHz, 16-bit Video Display Processor.

maxxoccupancy wrote

The average instruction takes about 5-6 cycles

I/O instructions on the Z80 take 11-16 cycles (or even 21 if using OTIR) for each byte output.

I just noticed this game has no hit pause, which is a big reason why the attacks feels so weightless.

Is there any way to implement hit pause in this? Maybe detect when the little spark sprite is rendered, and pause the game for 0.15 seconds when it shows up? I don't know the exact timing of the arcade game, but when I coded my own fighting game 0.1 seconds was good for light attacks, and 0.2 seconds was good for heavy attacks.

xfixium wrote

abstract text

Wow. I had no idea.

Man, makes me feel my age.haha When I worked for Sega the joke around the office was, where are all the fans? Guess it would be our kids!

I'm more of the old school SMS type if that's even a thing anymore but always wished for some love for other older games other than the token Phantasy Star release we get every so often.

I have no programming experience, unfortunately, but I do have a taste for this as a connoisseur of sorts.

Can I humbly make a couple of fun suggestions? From my wish list or dream list as it were?

I think you are the only one in this scene I can see actually doing God's work. Thank you for keeping the spirit alive!! My life wasn't wasted after all.lol

JohnSauer wrote

xfixium wrote

abstract text

Wow. I had no idea.

Man, makes me feel my age.haha When I worked for Sega the joke around the office was, where are all the fans? Guess it would be our kids!

I'm more of the old school SMS type if that's even a thing anymore but always wished for some love for other older games other than the token Phantasy Star release we get every so often.

I have no programming experience, unfortunately, but I do have a taste for this as a connoisseur of sorts.

Can I humbly make a couple of fun suggestions? From my wish list or dream list as it were?

I think you are the only one in this scene I can see actually doing God's work. Thank you for keeping the spirit alive!! My life wasn't wasted after all.lol

A wild (and maybe legitimate?) John Sauer appears!

Perhaps this needs its own thread, but I've been proposing the Jang Pong 3 approach to creating SF2-style fighting games on the SMS. You build both characters out of sprites, but correct flicker by setting torso sprites to low priority, then replace them with background tiles when necessary to prevent flicker.

You take four sprites from the character that are flickered out of existence, then take four of the adjusted sprites from the character's torso and use those to replace the background tiles.

This approach is recommended for one or two frames at 60 fps. Because it would be difficult to store 8x8 examples of the entire torso (shoulder to knees) for every available fighter, (about 4,000 tiles, or 128KB, one megabit) just to prevent flicker, AFAIK, no game did this. However, there are many examples in Metroid, Aleste, etc, where a few background tiles do get precalculated in the ROM cart to simulate parallax scrolling. To use this technique for fighters, we'd have to limit ourselves to a few torso sprites that have no boundary line. To save on memory, I propose that we draw 8 horizontal examples, but only 2 or 4 vertical examples of each background tile. We might even use a single generic approximation of that torso sprite and then just color match it for all of the fighters.

Reference video for anyone who doesn't know these games:

sverx wrote

maxxoccupancy wrote

The average instruction takes about 5-6 cycles

I/O instructions on the Z80 take 11-16 cycles (or even 21 if using OTIR) for each byte output.

Using the stack, we can get it down to 14 cycles per byte, or about 255KB/sec, or roughly 8,000 tiles per second (133 tiles per frame):

ld sp,src
pop hl
ld [dest+0],hl
pop hl
ld [dest+2],hl
...

https://retrocomputing.stackexchange.com/questions/4744/how-fast-is-memcpy-on-th...

Using push and pop, we can cut the overhead even a bit more, getting down to 10.5 cycles/byte, or 341KB/sec, for small, 14 byte transfers. Since a single tile is 32 bytes, I don't count that as a tool that we can use for much--other than compressed/decompressed audio samples.

Effectively, we're kept below a cruising speed of 256KB/sec, or a video block of 92x92, if the machine is doing nothing else. Since the SMS VDP is designed as a powerful sprite moving engine (14MHz, 16-bit), the Z80 is a pretty good match for it, IMHO.

Your enthusiasm is appreciated, but please stop posting nonsense about hardware you clearly do not (fully) understand. Your wild claims vastly (!) overestimate what the SMS can actually do.

How about, instead of trying to convince someone to do the work for you and implement the ideas you got from ..somewhere, you learn some z80 assembly and start coding? Start with simple things, get a feel for the machine and what it can do, then move on to more complicated stuff and maybe eventually to the kind of tricks you have in mind. The friendly and helpful forum members here will happily support you if you get stuck.

Kagesan wrote

Your enthusiasm is appreciated, but please stop posting nonsense about hardware you clearly do not (fully) understand. Your wild claims vastly (!) overestimate what the SMS can actually do.

How about, instead of trying to convince someone to do the work for you and implement the ideas you got from ..somewhere, you learn some z80 assembly and start coding? Start with simple things, get a feel for the machine and what it can do, then move on to more complicated stuff and maybe eventually to the kind of tricks you have in mind. The friendly and helpful forum members here will happily support you if you get stuck.

Because these big projects are not one-man shows. I've been chatting with xfixium about different ways of drawing the characters for a few months now.

maxxoccupancy wrote

Because these big projects are not one-man shows.

They can be, it just takes longer to complete them. As numerous members here have proven time and again, complete SMS games are well within the scope of a single individual.

However, there’s absolutely no reason to tackle something big as a first project anyway. I would never suggest that to anyone just starting out. A small prove-of-concept demo demonstrating a technique would be a nice achievement already.

maxxoccupancy wrote

sverx wrote

maxxoccupancy wrote

The average instruction takes about 5-6 cycles

I/O instructions on the Z80 take 11-16 cycles (or even 21 if using OTIR) for each byte output.

Using the stack, we can get it down to 14 cycles per byte

No, you can't make any I/O opcode go faster than what an I/O opcode takes, you're not understanding what I wrote.

Also:

pop hl
out (c),l
out (c),h

would take 34 cycles to output 2 bytes, which is slower than 2 OUTIs, which would require 32 cycles only.

So no savings to be made by using the stack in this case.

mankrip wrote

I just noticed this game has no hit pause, which is a big reason why the attacks feels so weightless.

Is there any way to implement hit pause in this? Maybe detect when the little spark sprite is rendered, and pause the game for 0.15 seconds when it shows up? I don't know the exact timing of the arcade game, but when I coded my own fighting game 0.1 seconds was good for light attacks, and 0.2 seconds was good for heavy attacks.

Does anybody here know how to implement hit pauses in this game?

You know what I mean, right? Here's Masahiro Sakurai's video on it.

mankrip wrote

Does anybody here know how to implement hit pauses in this game?

This is a purely cosmetic hack that exchanges the poor visuals of the original with (much) better ones. Altering the way it actually plays goes far beyond the scope of a hack like this and would probably require disassembling and rewriting the game logic.

Author	Message
mankrip Joined: 02 Mar 2023 Posts: 4	Posted: Thu Mar 02, 2023 12:24 pm
mankrip Joined: 02 Mar 2023 Posts: 4	Hello. Here's a suggestion for Ken's stage, inspired by the colors of the CPS2 version of Champion Edition. I edited it from the last screenshot posted here. By the way, I'm not sure if this edit matches the SMS specs. I'm also uploading an image showing the areas which were edited. sms_sf2ce_ken.png (14.62 KB) sms_sf2ce_ken_diff.png (4.21 KB)

slogra Joined: 09 Jun 2014 Posts: 308	Posted: Thu Mar 02, 2023 1:22 pm
slogra Joined: 09 Jun 2014 Posts: 308	I think the Genesis/MegaDrive has an orange sky, while the arcade and snes have a yellow sky. So it's a matter of preference. Imho yellow looks a little better.

mankrip Joined: 02 Mar 2023 Posts: 4	Posted: Thu Mar 02, 2023 4:08 pm
mankrip Joined: 02 Mar 2023 Posts: 4	Well, the SMS version will always be different no matter what. The difference between both consoles is roughly the same (or more!) than the difference between the Genesis and the CPS1 arcade board. The key is to make things just good enough to match the overall feeling of the original game, even if the details aren't the same.

cireza Joined: 27 Feb 2023 Posts: 51 Location: France	Posted: Thu Mar 02, 2023 4:08 pm
cireza Joined: 27 Feb 2023 Posts: 51 Location: France	Great work so far on improving the visuals of the game. One quick confirmation though. I get it from working on MS/GG hardware that you cannot flip sprites. I guess that SFII confirms (as any other game) that all sprites are present in the ROM facing both directions ? This would mean by definition that the MS requires quite a bit of ROM space for fighting games.

ichigobankai Joined: 04 Jul 2010 Posts: 465 Location: Angers, France	Posted: Thu Mar 02, 2023 5:56 pm
	@cireza Actually you can easily flip a sprites before uploading it in VRAM. Just a little LUT needed. It will take 2 times more cycles. As the SMS can't flip by default these data, it can be a good choice to have both side different (like always have the sword or shield in the same hand) ;)

cireza Joined: 27 Feb 2023 Posts: 51 Location: France	Posted: Thu Mar 02, 2023 7:42 pm
cireza Joined: 27 Feb 2023 Posts: 51 Location: France	ichigobankai wrote @cireza Actually you can easily flip a sprites before uploading it in VRAM. Just a little LUT needed. It will take 2 times more cycles. As the SMS can't flip by default these data, it can be a good choice to have both side different (like always have the sword or shield in the same hand) ;) I don't want to derail the thread but I am curious. Can you flip a tile with a look-up table ? Meaning writing the rows of 8 pixels reversed ? If you have some examples or explanations of this, I would be curious (I don't actually need it, but I have starting looking at all MS/GG games trying to understand how they work since I began developing lol). Thanks :)

ichigobankai Joined: 04 Jul 2010 Posts: 465 Location: Angers, France	Posted: Thu Mar 02, 2023 8:59 pm
	As an exercise, convert two 8x8 tiles with BMP2Tiles. 1 facing right, the other facing left (flipped), check/compare binaries ;) you'll find a 256 bytes LUT. For performances (and simplicity), the LUT must be copied/aligned in RAM (at a clean address), like 0xD100. Data will be readable from D100 to D1FF. As they are aligned you'll only have to update the LSB part of the address (00 - FF) to get the flipped value. the LUT will look like this: (asm, i've generated mine with few lines of C) .db $00; $00 .db $80; $01 .db $40; $02 .db $C0; $03 .db $20; $04 .db $A0; $05 .db $60; $06 ... .db $3F; $FC .db $BF; $FD .db $7F; $FE .db $FF; $FF Then, the code itself to flip the tile in ASM it will looks like that ; HL = Source (tile data) DE = LUT ps. a tile is 32 bytes. for performances - better to unroll the loop (= repeat 32 times = 1 tile). ... ld e, (hl) ;7 ld a, (de) ;7 out(#0xBE), a ;11 inc hl ;6 //31 cycles ...

cireza Joined: 27 Feb 2023 Posts: 51 Location: France	Posted: Thu Mar 02, 2023 10:07 pm
cireza Joined: 27 Feb 2023 Posts: 51 Location: France	ichigobankai wrote As an exercise, convert two 8x8 tiles with BMP2Tiles. ... I think I get it, thanks for taking the time :)

xfixium Joined: 18 Jul 2020 Posts: 327	Posted: Thu Mar 02, 2023 10:21 pm
xfixium Joined: 18 Jul 2020 Posts: 327	mankrip wrote Hello. Here's a suggestion for Ken's stage, inspired by the colors of the CPS2 version of Champion Edition. I edited it from the last screenshot posted here. By the way, I'm not sure if this edit matches the SMS specs. I'm also uploading an image showing the areas which were edited. The release candidate for this hack had light yellow originally (Still available, if you want to play it that way). I received a few messages to have it changed to orange, because of various reasons. Someone even made a whole mock up like you did, but using orange. Each color blends in a bit, orange seemed closer to the source material, so it won out. There are tools available on the first post of this topic that you can use to change the game graphics however you want it. Everyone has their preferences. cireza wrote Great work so far on improving the visuals of the game. One quick confirmation though. I get it from working on MS/GG hardware that you cannot flip sprites. I guess that SFII confirms (as any other game) that all sprites are present in the ROM facing both directions ? This would mean by definition that the MS requires quite a bit of ROM space for fighting games. The rom only has left facing resources. They do dynamically flip the graphics it seems, but that's for the BG tiled fighter I believe (It's been awhile), as one is comprised of sprites, and the other is BG tile merged in software. Derailments are welcomed, always something interesting that shows up, always something new to learn

kusfo Joined: 29 Mar 2012 Posts: 833 Location: Spain	Posted: Fri Mar 03, 2023 8:26 am
kusfo Joined: 29 Mar 2012 Posts: 833 Location: Spain	Continuing with the derailment (sorry), one thing to consider is that ROM space is almost infinite nowadays, but CPU cycle aren't. So it's usually best to have the tiles flipped in rom already

sverx Joined: 05 Sep 2013 Posts: 3454 Location: Torino, then London, now Stockholm	Posted: Fri Mar 03, 2023 10:12 am
	kusfo wrote Continuing with the derailment (sorry), one thing to consider is that ROM space is almost infinite nowadays, but CPU cycle aren't. So it's usually best to have the tiles flipped in rom already quoting on this, because it's important. You can 'quickly' copy a few tiles to VRAM with a single OUTI block, it will cost 16 cycles/byte (devkitSMS' SMSlib supports this using the UNSAFE_SMS_load<n>Tile(s) functions) but if you choose to flip bytes it will take much more. So, unless ROM size is an issue (for instance, you plan on releasing on a 32 KiB ROM cartridge with no mapper) then you'll find convenient to save CPU cycles for more important tasks. Also, there are mappers that can do byte flipping (and I suspect it's not that hard to create a SEGA compatible mapper that supports this too)

ichigobankai Joined: 04 Jul 2010 Posts: 465 Location: Angers, France	Posted: Fri Mar 03, 2023 1:11 pm
	its "only" 31 cycles vs. 16. So takes 992 cycles for a complete flipped tiles instead of 512 with OUTIs. adding this directly on the mapper could be a nice addition. (there's few unused bits on some registers) Since many month its hard to have electronic at decent price (talk about new parts, not aliexpress refurbished things). Some CPLD refs. are not available until... end of 2024. lol. But honestly, filling a 512Kb rom is already a big challenge.

sverx Joined: 05 Sep 2013 Posts: 3454 Location: Torino, then London, now Stockholm	Posted: Fri Mar 03, 2023 1:50 pm
	ichigobankai wrote its "only" 31 cycles vs. 16. yes, but again this means going from being able to stream 24 tiles in a single vblank at 60Hz to just 12 - so once more I think it can be either totally fine or totally unacceptable depending on the specific circumstances.

ichigobankai Joined: 04 Jul 2010 Posts: 465 Location: Angers, France	Posted: Fri Mar 03, 2023 2:12 pm
	Exactly, really depends on circumstances/needs.

maxxoccupancy Joined: 05 Mar 2022 Posts: 118 Location: Seabrook, New Hampshire	Posted: Mon Mar 06, 2023 2:34 am
	ichigobankai wrote its "only" 31 cycles vs. 16. So takes 992 cycles for a complete flipped tiles instead of 512 with OUTIs. adding this directly on the mapper could be a nice addition. (there's few unused bits on some registers) Since many month its hard to have electronic at decent price (talk about new parts, not aliexpress refurbished things). Some CPLD refs. are not available until... end of 2024. lol. But honestly, filling a 512Kb rom is already a big challenge. Remember that we have 227 z80 clock cycles per horizontal scanline. The average instruction takes about 5-6 cycles, so you have about 32 instructions that can be executed in each scanline. On the NES, limit pushers had to actually count clock cycles because they don't even have a scanline counter. It turns out, though, that fewer cycles are wasted than the SMS approach of using horizontal interrupts because of the overhead involved. In fact, I think that there are SMS demos where the Z80 just runs in parallel with the 14MHz, 16-bit Video Display Processor.

sverx Joined: 05 Sep 2013 Posts: 3454 Location: Torino, then London, now Stockholm	Posted: Mon Mar 06, 2023 8:49 am
	maxxoccupancy wrote The average instruction takes about 5-6 cycles I/O instructions on the Z80 take 11-16 cycles (or even 21 if using OTIR) for each byte output.

mankrip Joined: 02 Mar 2023 Posts: 4	Posted: Sun Mar 19, 2023 3:21 pm
mankrip Joined: 02 Mar 2023 Posts: 4	I just noticed this game has no hit pause, which is a big reason why the attacks feels so weightless. Is there any way to implement hit pause in this? Maybe detect when the little spark sprite is rendered, and pause the game for 0.15 seconds when it shows up? I don't know the exact timing of the arcade game, but when I coded my own fighting game 0.1 seconds was good for light attacks, and 0.2 seconds was good for heavy attacks.

JohnSauer Joined: 19 Mar 2023 Posts: 1	Posted: Sun Mar 19, 2023 6:01 pm
JohnSauer Joined: 19 Mar 2023 Posts: 1	xfixium wrote abstract text Wow. I had no idea. Man, makes me feel my age.haha When I worked for Sega the joke around the office was, where are all the fans? Guess it would be our kids! I'm more of the old school SMS type if that's even a thing anymore but always wished for some love for other older games other than the token Phantasy Star release we get every so often. I have no programming experience, unfortunately, but I do have a taste for this as a connoisseur of sorts. Can I humbly make a couple of fun suggestions? From my wish list or dream list as it were? I think you are the only one in this scene I can see actually doing God's work. Thank you for keeping the spirit alive!! My life wasn't wasted after all.lol

kusfo Joined: 29 Mar 2012 Posts: 833 Location: Spain	Posted: Mon Mar 20, 2023 9:15 am
kusfo Joined: 29 Mar 2012 Posts: 833 Location: Spain	JohnSauer wrote xfixium wrote abstract text Wow. I had no idea. Man, makes me feel my age.haha When I worked for Sega the joke around the office was, where are all the fans? Guess it would be our kids! I'm more of the old school SMS type if that's even a thing anymore but always wished for some love for other older games other than the token Phantasy Star release we get every so often. I have no programming experience, unfortunately, but I do have a taste for this as a connoisseur of sorts. Can I humbly make a couple of fun suggestions? From my wish list or dream list as it were? I think you are the only one in this scene I can see actually doing God's work. Thank you for keeping the spirit alive!! My life wasn't wasted after all.lol A wild (and maybe legitimate?) John Sauer appears!

maxxoccupancy Joined: 05 Mar 2022 Posts: 118 Location: Seabrook, New Hampshire	SMS Street Fighter 2 ROM Hack Posted: Tue Mar 21, 2023 4:58 pm
	Perhaps this needs its own thread, but I've been proposing the Jang Pong 3 approach to creating SF2-style fighting games on the SMS. You build both characters out of sprites, but correct flicker by setting torso sprites to low priority, then replace them with background tiles when necessary to prevent flicker. You take four sprites from the character that are flickered out of existence, then take four of the adjusted sprites from the character's torso and use those to replace the background tiles. This approach is recommended for one or two frames at 60 fps. Because it would be difficult to store 8x8 examples of the entire torso (shoulder to knees) for every available fighter, (about 4,000 tiles, or 128KB, one megabit) just to prevent flicker, AFAIK, no game did this. However, there are many examples in Metroid, Aleste, etc, where a few background tiles do get precalculated in the ROM cart to simulate parallax scrolling. To use this technique for fighters, we'd have to limit ourselves to a few torso sprites that have no boundary line. To save on memory, I propose that we draw 8 horizontal examples, but only 2 or 4 vertical examples of each background tile. We might even use a single generic approximation of that torso sprite and then just color match it for all of the fighters. Reference video for anyone who doesn't know these games:

maxxoccupancy Joined: 05 Mar 2022 Posts: 118 Location: Seabrook, New Hampshire	Posted: Tue Mar 21, 2023 5:39 pm
	sverx wrote maxxoccupancy wrote The average instruction takes about 5-6 cycles I/O instructions on the Z80 take 11-16 cycles (or even 21 if using OTIR) for each byte output. Using the stack, we can get it down to 14 cycles per byte, or about 255KB/sec, or roughly 8,000 tiles per second (133 tiles per frame): ld sp,src pop hl ld [dest+0],hl pop hl ld [dest+2],hl ... https://retrocomputing.stackexchange.com/questions/4744/how-fast-is-memcpy-on-th... Using push and pop, we can cut the overhead even a bit more, getting down to 10.5 cycles/byte, or 341KB/sec, for small, 14 byte transfers. Since a single tile is 32 bytes, I don't count that as a tool that we can use for much--other than compressed/decompressed audio samples. Effectively, we're kept below a cruising speed of 256KB/sec, or a video block of 92x92, if the machine is doing nothing else. Since the SMS VDP is designed as a powerful sprite moving engine (14MHz, 16-bit), the Z80 is a pretty good match for it, IMHO.

Kagesan Joined: 01 Feb 2014 Posts: 775	Posted: Tue Mar 21, 2023 6:31 pm
Kagesan Joined: 01 Feb 2014 Posts: 775	Your enthusiasm is appreciated, but please stop posting nonsense about hardware you clearly do not (fully) understand. Your wild claims vastly (!) overestimate what the SMS can actually do. How about, instead of trying to convince someone to do the work for you and implement the ideas you got from ..somewhere, you learn some z80 assembly and start coding? Start with simple things, get a feel for the machine and what it can do, then move on to more complicated stuff and maybe eventually to the kind of tricks you have in mind. The friendly and helpful forum members here will happily support you if you get stuck.

maxxoccupancy Joined: 05 Mar 2022 Posts: 118 Location: Seabrook, New Hampshire	Posted: Tue Mar 21, 2023 6:46 pm
	Kagesan wrote Your enthusiasm is appreciated, but please stop posting nonsense about hardware you clearly do not (fully) understand. Your wild claims vastly (!) overestimate what the SMS can actually do. How about, instead of trying to convince someone to do the work for you and implement the ideas you got from ..somewhere, you learn some z80 assembly and start coding? Start with simple things, get a feel for the machine and what it can do, then move on to more complicated stuff and maybe eventually to the kind of tricks you have in mind. The friendly and helpful forum members here will happily support you if you get stuck. Because these big projects are not one-man shows. I've been chatting with xfixium about different ways of drawing the characters for a few months now.

Kagesan Joined: 01 Feb 2014 Posts: 775	Posted: Wed Mar 22, 2023 9:27 am
Kagesan Joined: 01 Feb 2014 Posts: 775	maxxoccupancy wrote Because these big projects are not one-man shows. They can be, it just takes longer to complete them. As numerous members here have proven time and again, complete SMS games are well within the scope of a single individual. However, there’s absolutely no reason to tackle something big as a first project anyway. I would never suggest that to anyone just starting out. A small prove-of-concept demo demonstrating a technique would be a nice achievement already.

sverx Joined: 05 Sep 2013 Posts: 3454 Location: Torino, then London, now Stockholm	Posted: Wed Mar 22, 2023 1:06 pm
	maxxoccupancy wrote sverx wrote maxxoccupancy wrote The average instruction takes about 5-6 cycles I/O instructions on the Z80 take 11-16 cycles (or even 21 if using OTIR) for each byte output. Using the stack, we can get it down to 14 cycles per byte No, you can't make any I/O opcode go faster than what an I/O opcode takes, you're not understanding what I wrote. Also: pop hl out (c),l out (c),h would take 34 cycles to output 2 bytes, which is slower than 2 OUTIs, which would require 32 cycles only. So no savings to be made by using the stack in this case.

mankrip Joined: 02 Mar 2023 Posts: 4	Posted: Wed Mar 22, 2023 9:35 pm
mankrip Joined: 02 Mar 2023 Posts: 4	mankrip wrote I just noticed this game has no hit pause, which is a big reason why the attacks feels so weightless. Is there any way to implement hit pause in this? Maybe detect when the little spark sprite is rendered, and pause the game for 0.15 seconds when it shows up? I don't know the exact timing of the arcade game, but when I coded my own fighting game 0.1 seconds was good for light attacks, and 0.2 seconds was good for heavy attacks. Does anybody here know how to implement hit pauses in this game? You know what I mean, right? Here's Masahiro Sakurai's video on it.

Kagesan Joined: 01 Feb 2014 Posts: 775	Posted: Thu Mar 23, 2023 10:57 am
Kagesan Joined: 01 Feb 2014 Posts: 775	mankrip wrote Does anybody here know how to implement hit pauses in this game? This is a purely cosmetic hack that exchanges the poor visuals of the original with (much) better ones. Altering the way it actually plays goes far beyond the scope of a hack like this and would probably require disassembling and rewriting the game logic.

Forums

View topic - SMS Street Fighter 2 ROM Hack