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.

Hi, I'm finishing a remake of the Ken stage, but the game is having some issues (see screenshot).

Is there any way to fix this without removing the color 1 of the stage palette (which I changed from black to yellow)?

Also, some stage tiles are being flipped when Ken goes in front of them.

Edit: Fixed Ken's tiles having a black background in front of the horizon.

Street Fighter II' Remaster System (Brazil) (En)-03.png (10.13 KB)

mankrip wrote

Hi, I'm finishing a remake of the Ken stage, but the game is having some issues (see screenshot).

Is there any way to fix this without removing the color 1 of the stage palette (which I changed from black to yellow)?

Also, what's up with Ken's tiles having a black background in front of the horizon?

You'll have to reindex all of Ken's graphics to use the yellow color, that was once his outline color. Typically the first 10-12 BG colors are reserved for the fighter belonging to the stage (Ken). 0 is reserved for the tile merging code as a "transparent" color. You could reimport through SMS Editor. The palette planning is a little delicate, as fire damage and hadoukens will also have to arranged sensibly.

Do you have a black tile in the beginning of Ken's Stage tileset? If not, add one. That typically is the reason why the black blocking happens. SMS Editor has a Add Tile button to do that, if you're using it.

Edit:

Quote

Also, some stage tiles are being flipped when Ken goes in front of them.

This happens if vertical flipping is used to optimize the tileset. The game's merging code only supports horizontal flipping.

Well, I've eliminated the extra yellow color to fix Ken's colors, and fixed the horizon tile blacking out. This comparison image is from before the extra yellow color was removed.

The buggy vertical flipping would take too many sacrifices to fix, so I'm going to release this version as is. I'm releasing it as the SMS Editor project file.

I've also improved Ryu's stage a little bit.

Truth be told, TecToy developers sucks at programming. This game has major collision and input recognition bugs besides the choppy movement, and the lack of support for vertical flipping is simply dumb.

I've edited Ken's stage as a challenge to myself, to see how much I could improve it, and I was also going to do some major edits to the ocean waves at the bottom part of the image, but since the game doesn't support vertical flipping of tiles there's no point in going further.

Feel free to use my changes in any way you want. Would be nice if someone created a new SF2 port for the SMS from the ground up, to make it as good as the SMS can handle.

Ken Stage comparison big.png (59.4 KB)

sf2_RemasterSystem.7z (1005.03 KB)

mankrip wrote

Well, I've eliminated the extra yellow color to fix Ken's colors, and fixed the horizon tile blacking out. This comparison image is from before the extra yellow color was removed.

The buggy vertical flipping would take too many sacrifices to fix, so I'm going to release this version as is. I'm releasing it as the SMS Editor project file.

I've also improved Ryu's stage a little bit.

Truth be told, TecToy developers sucks at programming. This game has major collision and input recognition bugs besides the choppy movement, and the lack of support for vertical flipping is simply dumb.

I've edited Ken's stage as a challenge to myself, to see how much I could improve it, and I was also going to do some major edits to the ocean waves at the bottom part of the image, but since the game doesn't support vertical flipping of tiles there's no point in going further.

Feel free to use my changes in any way you want. Would be nice if someone created a new SF2 port for the SMS from the ground up, to make it as good as the SMS can handle.

I like what you did with it. Adding back in some of the lost details. Like the life preservers, the cleat hitches, tire, etc.. etc... The smoke stack is very nicely done. The dithering on the dark parts of the main boat. AA on the white paneling. The shading done on the bottom half of the boat reminds me of what Mondo did for the Castlevania stage floor tiles recently. Overall, it looks cleaner.

I think a good way to create a new fighting game engine for the SMS would be to do it mostly with sprites, like Jang Pung 3 did, and only use background tiles for the stationary actions.

For example, Ryu's hadouken animation could be entirely done with background tiles since he doesn't move around while doing it, but his shoryuken and tatsumaki sempukyaku would have to be done using sprites. Likewise, grounded punches and kicks could be done with background tiles, while aerial punches and kicks would have to be done with sprites. Damage animations would have to be done using sprites, but the last frame of the beaten player lying down in the floor could be done with background tiles.

Some logic would have to be implemented to keep the physics constrained to 8x8 tile movements, while interpolating sprite-based movements between tile positions.
Maybe it could be done the other way around, by making the physics pixel-perfect but rounding the stationary positions to 8x8 pixels (this would require some extra logic to round up higher sub-tile precision, while rounding down lower sub-tile precision; could be done with a lookup table).

Doing it this way would eliminate most cases of sprite flickering, while allowing for smooth gameplay.

fusionning tiles & sprites is a very slow process (heavy cpu eating), so your gameplay will always suck.

Unless you're using an advanced mapper with some new functions to pre calculate data for you...

Can you explain why it would be slow? The hardware supports using sprites as tiles. Is it really that slow to use that feature? I see games manipulating the tiles to create parallax scrolling at 60fps.

Doing things like this on the Gameboy is super fast if it's just a few tiles.

You'd also have to only have one palette of 16 colours for the whole game I understand that limit.

I meant "smooth gameplay" in space, not time. It's about being able to move at multiples of 1 pixel instead of being forced to move 8 pixels at a time.

Anyway, a way to minimize the amount of processing required for merging a player's background tiles is to track the amount of sprites per tile row, and only generate enough background tiles to prevent flickering, instead of generating background tiles for the entire player's frame. This way, the same player would be partially made of sprites, and partially made of background tiles.

So, in the end the logic would be more or less like this:
1) If stationary, allow the player to be made of background tiles.
2) If the player is allowed to be made of background tiles, compute the amount of tiles actually needed per row.
3) Draw the needed background tiles, and use sprites for the rest.

So you've not understand/dig how Street Fighter 2 or Mortal Kombat or Golden Axe are made on SMS ;)

Sprites are "movable" tiles, but only using pal 2 (index 16-31)
move ±1px

tiles are fix, based on a 8x8px grid and can use pal 1 & 2 (0 to 31)

to be short more than 8 sprites on a line show flickering (disappear)

so to make 2 huge sprites for a vs. fighting game, somes have the idea to fusion a background tile (8x8 bloc behind the sprite) and the sprite itself, using the transparent color (index 0) as a mask.

- problems :
* your sprite can be anywhere on screen
* to fusion the background and the sprite, the sprite should also use the same pal (only 1 pal can be used on a 8x8 tile)
* as your sprite is not on a 8x8 grid, you'll certainly have few tiles to generate with the background behind him (more than the sprite itself)
so you should keep many free VRAM.
* time to generate each fusionned tile is far to be free
• ultimately you'll have to update the tilemap with the tiles freshly generated
...
* then all the rest of the game engine.

parallax have nothing to do with this sort of things, far easier and controlled by the hardware (simple / fast)

mankrip wrote

I meant "smooth gameplay" in space, not time. It's about being able to move at multiples of 1 pixel instead of being forced to move 8 pixels at a time.

Pretty sure they have deliberately chosen a movement on 8px to compensate the huge time taken by the fusion process and the size in VRAM (easier to estimate)

ichigobankai, you did not pay attention to what I said in this reply. Everything you said was already taken into consideration here.

mankrip wrote

I think a good way to create a new fighting game engine for the SMS would be to do it mostly with sprites, like Jang Pung 3 did, and only use background tiles for the stationary actions.

For example, Ryu's hadouken animation could be entirely done with background tiles since he doesn't move around while doing it, but his shoryuken and tatsumaki sempukyaku would have to be done using sprites. Likewise, grounded punches and kicks could be done with background tiles, while aerial punches and kicks would have to be done with sprites. Damage animations would have to be done using sprites, but the last frame of the beaten player lying down in the floor could be done with background tiles.

Some logic would have to be implemented to keep the physics constrained to 8x8 tile movements, while interpolating sprite-based movements between tile positions.
Maybe it could be done the other way around, by making the physics pixel-perfect but rounding the stationary positions to 8x8 pixels (this would require some extra logic to round up higher sub-tile precision, while rounding down lower sub-tile precision; could be done with a lookup table).

Doing it this way would eliminate most cases of sprite flickering, while allowing for smooth gameplay.

yes i've read what you've wrote earlier.

time to code my friend.

Funny how new members think that know more than experts here.
IMHO, Jang Pung 3 is the best fighting vs game for SMS. Better even that some 16 bits games in genre. It have flicker? Yes, but i prefer a game with fllcker and very good gameplay than a with no flicker and poor game moves. If somebody want do something good is better hack it Jang Pung 3 or Sangokuchi 3 and put SF sprites on it. @xfixium already did miracles with SF2.

There's also the very nice Masters of Combat on SMS ;)

and +1 for xfixium work !
The base material was far to be good and he did an impressive cosmetic job.

I've made an advanced mapper weeks ago that can surely do some miracles on games likes SF2 or MK (as i've added DMA transfert, precalc fusion tiles/sprites, decompressing zx7 / psgaiden...), but I didn't made it for ports, repro or hacks.

ichigobankai wrote

I've made an advanced mapper weeks ago that can surely do some miracles on games likes SF2 or MK (as i've added DMA transfert, precalc fusion tiles/sprites, decompressing zx7 / psgaiden...), but I didn't made it for ports, repro or hacks.

Sorry to derail this topic but - would you care to explain the 'precalc fusion tiles/sprites' feature? :)

you have to send sprite bank/adr, tile bank/adr, sram bank/adr (for the adr result) to a register.

The 32 bytes fusion thing is available on slot 2.
Like SF2 etc, it will use the sprite color 0 as a mask for the background tile.
It take only few cycles to generate.

This feature is more a POC than a real thing (as 8x8 based), it can be ameliorated.

There's 6 x 16ko sram banks, so you can prepare/uncompress a lot of things.

so it basically it lays down one tile on top of another to create a third one using color 0 transparency in hardware? but tiles need to be perfectly aligned I guess...?

Exactly like golden axe, sf2 or mk
Unaligned sprite will be harder to generate but faisible with the mcu (btw you'll need to keep far more vram free)

Can't wait to see GG Paprium....😉

Since no one mentioned it yet-there is a new 2023 opensource 1 vs 1 fighting game engine it is called Chibi fighter 2 and works on the master system as mentioned in the few youtube videos and below about it

as the author Chibiakumas explains in detail it not a ROM hack but coded from scratch.Both the players move 1 pixel at a time I can see from the you tube video.I didnt find the master system ROM for ChibiFighter 2 yet. But as can be seen from the Chibiakumas youtube videos it works on the master system.

mankrip wrote

I think a good way to create a new fighting game engine for the SMS would be to do it mostly with sprites, like Jang Pung 3 did, and only use background tiles for the stationary actions.

For example, Ryu's hadouken animation could be entirely done with background tiles since he doesn't move around while doing it, but his shoryuken and tatsumaki sempukyaku would have to be done using sprites. Likewise, grounded punches and kicks could be done with background tiles, while aerial punches and kicks would have to be done with sprites. Damage animations would have to be done using sprites, but the last frame of the beaten player lying down in the floor could be done with background tiles.

Some logic would have to be implemented to keep the physics constrained to 8x8 tile movements, while interpolating sprite-based movements between tile positions.
Maybe it could be done the other way around, by making the physics pixel-perfect but rounding the stationary positions to 8x8 pixels (this would require some extra logic to round up higher sub-tile precision, while rounding down lower sub-tile precision; could be done with a lookup table).

Doing it this way would eliminate most cases of sprite flickering, while allowing for smooth gameplay.

Jolene wrote

Since no one mentioned it yet-there is a new 2023 opensource 1 vs 1 fighting game engine it is called Chibi fighter 2 and works on the master system as mentioned in the few youtube videos and below about it

as the author Chibiakumas explains in detail it not a ROM hack but coded from scratch.Both the players move 1 pixel at a time I can see from the you tube video.I didnt find the master system ROM for ChibiFighter 2 yet. But as can be seen from the Chibiakumas youtube videos it works on the master system.

mankrip wrote

I think a good way to create a new fighting game engine for the SMS would be to do it mostly with sprites, like Jang Pung 3 did, and only use background tiles for the stationary actions.

For example, Ryu's hadouken animation could be entirely done with background tiles since he doesn't move around while doing it, but his shoryuken and tatsumaki sempukyaku would have to be done using sprites. Likewise, grounded punches and kicks could be done with background tiles, while aerial punches and kicks would have to be done with sprites. Damage animations would have to be done using sprites, but the last frame of the beaten player lying down in the floor could be done with background tiles.

Some logic would have to be implemented to keep the physics constrained to 8x8 tile movements, while interpolating sprite-based movements between tile positions.
Maybe it could be done the other way around, by making the physics pixel-perfect but rounding the stationary positions to 8x8 pixels (this would require some extra logic to round up higher sub-tile precision, while rounding down lower sub-tile precision; could be done with a lookup table).

Doing it this way would eliminate most cases of sprite flickering, while allowing for smooth gameplay.

Judging from the video, it seems pretty choppy.
Also, there's no tile merging: please notice the black borders around the sprites.
Here's their source code:
https://www.chibiakumas.com/z80/chibifighter.php#LessonCF4

BTW,one way to completely avoid tile merging would be to use the trick used on Rise of The Robots on Game Gear: the backgrounds are a solid color, with some color variation obtained by using the raster ints for changing the background color:
%3D%3D
Not sure if this is an advisable design, though.. :P

mankrip wrote

I think a good way to create a new fighting game engine for the SMS would be to do it mostly with sprites, like Jang Pung 3 did, and only use background tiles for the stationary actions.

For example, Ryu's hadouken animation could be entirely done with background tiles since he doesn't move around while doing it, but his shoryuken and tatsumaki sempukyaku would have to be done using sprites. Likewise, grounded punches and kicks could be done with background tiles, while aerial punches and kicks would have to be done with sprites. Damage animations would have to be done using sprites, but the last frame of the beaten player lying down in the floor could be done with background tiles.

Some logic would have to be implemented to keep the physics constrained to 8x8 tile movements, while interpolating sprite-based movements between tile positions.
Maybe it could be done the other way around, by making the physics pixel-perfect but rounding the stationary positions to 8x8 pixels (this would require some extra logic to round up higher sub-tile precision, while rounding down lower sub-tile precision; could be done with a lookup table).

Doing it this way would eliminate most cases of sprite flickering, while allowing for smooth gameplay.

I feel like I've said this before. A few times even.

Jang Pang 3 uses all sprites and accepts flicker. However, when flicker occurs (disappearing sprites), we could replace those sprites only, drawing them as background tiles. This would only require a handful of sprites to be redrawn once in a while, and we would not need to get them exact. For example, we might only replace a few body tiles with a standard, more or less solid background tile of the color/pattern of the character's outfit. Since there are only a few colors or patterns, we'd only need a few.

By replacing body tile sprites with background tiles, we could minimize the number of tiles to be redrawn and minimize the need to mix them with actual backgrounds.

So the framerate would certainly drop from 60fps to 30fps to avoid flicker, albeit with flicker blanking replaced with a few solid, correctly colored blocks.

And in rare instances where that's not clear enough, we could take the sprite tiles from the ROM cart and manually mix them with background tiles, ala Tectoy's SF2, dropping down to 10-15 fps.

maxxoccupancy wrote

By replacing body tile sprites with background tiles, we could minimize the number of tiles to be redrawn and minimize the need to mix them with actual backgrounds.

Tile merging must indeed be the most costly operation performed by the SF2 renderer.

Prioritizing tiles without transparent colors in the background tile replacement process, and using sprites for the rest would indeed be much faster to render.

In this mockup, the tiles on the left should be rendered as sprite tiles, while the tiles on the right could be rendered as background tiles. This alone frees enough sprite tiles for both players to do this move without flickering, and without tile merging (just straightforward tile copying instead).

To achieve that, I changed the tiling offsets to maximize the amount of tiles without transparent pixels. However, this would affect the game's physics since the collision would have to be adjusted to the new offsets.

Anyway, the point of the idea mentioned in my previous posts was not to completely eliminate flickering, and wasn't to achieve high framerates either. My point is to reach a middle ground, where flickering would be reduced to a minimum (but would still exist), and the performance would be increased just enough to allow for pixel-accurate movement.

Another idea on how to deal with flickering is to focus the flickering on the sprite tiles from the back to the front of the characters. So, when you kick someone, your butt may disappear but your foot will still be visible, allowing players to keep their focus on the parts of the body where the combat physics actually happens.

SMS sprites and tiles.png (1.33 KB)

I would go even further, given the game genre: I would rather have a flickering nightmare WORSE than Jang Pong 3 and R-Type combined that try to play a fighting game at 10-15 FPS... even if it otherwise looked exactly like the arcade.

I would even squish the two characters down to 4 tiles wide each to achieve this. Fighting games need to run and take input at 60fps or better. That's 9,000 Z80 instructions per frame. Big, brutal fighting games are what finally killed the 8-bit market for good, though the SMS held out the longest. It's the lack of cpu power and sprite handling that sank the NES and its nadir. Whatever can't be done in 16ms just shouldn't even be attempted in fighting games, flicker or width be damned. Throw the details above and below the two characters so that we can merge background tiles more quickly.

SEGA has always suffered from the desire to push graphics and image fidelity above playability. Obviously, Ni****do went completely the other way, and we've seen the results in the marketplace.

Author	Message
mankrip Joined: 02 Mar 2023 Posts: 14	Posted: Thu Mar 02, 2023 12:24 pm
mankrip Joined: 02 Mar 2023 Posts: 14	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: 411	Posted: Thu Mar 02, 2023 1:22 pm
slogra Joined: 09 Jun 2014 Posts: 411	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: 14	Posted: Thu Mar 02, 2023 4:08 pm
mankrip Joined: 02 Mar 2023 Posts: 14	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: 148 Location: France	Posted: Thu Mar 02, 2023 4:08 pm
cireza Joined: 27 Feb 2023 Posts: 148 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: 546 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: 148 Location: France	Posted: Thu Mar 02, 2023 7:42 pm
cireza Joined: 27 Feb 2023 Posts: 148 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: 546 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: 148 Location: France	Posted: Thu Mar 02, 2023 10:07 pm
cireza Joined: 27 Feb 2023 Posts: 148 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: 392	Posted: Thu Mar 02, 2023 10:21 pm
xfixium Joined: 18 Jul 2020 Posts: 392	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: 900 Location: Spain	Posted: Fri Mar 03, 2023 8:26 am
kusfo Joined: 29 Mar 2012 Posts: 900 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: 3941 Location: Stockholm, Sweden	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: 546 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: 3941 Location: Stockholm, Sweden	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: 546 Location: Angers, France	Posted: Fri Mar 03, 2023 2:12 pm
	Exactly, really depends on circumstances/needs.

maxxoccupancy Joined: 05 Mar 2022 Posts: 129 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: 3941 Location: Stockholm, Sweden	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: 14	Posted: Sun Mar 19, 2023 3:21 pm
mankrip Joined: 02 Mar 2023 Posts: 14	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: 900 Location: Spain	Posted: Mon Mar 20, 2023 9:15 am
kusfo Joined: 29 Mar 2012 Posts: 900 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: 129 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: 129 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: 895	Posted: Tue Mar 21, 2023 6:31 pm
Kagesan Joined: 01 Feb 2014 Posts: 895	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: 129 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: 895	Posted: Wed Mar 22, 2023 9:27 am
Kagesan Joined: 01 Feb 2014 Posts: 895	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: 3941 Location: Stockholm, Sweden	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: 14	Posted: Wed Mar 22, 2023 9:35 pm
mankrip Joined: 02 Mar 2023 Posts: 14	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: 895	Posted: Thu Mar 23, 2023 10:57 am
Kagesan Joined: 01 Feb 2014 Posts: 895	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.

mankrip Joined: 02 Mar 2023 Posts: 14	Posted: Wed Aug 30, 2023 8:10 pm
mankrip Joined: 02 Mar 2023 Posts: 14	Hi, I'm finishing a remake of the Ken stage, but the game is having some issues (see screenshot). Is there any way to fix this without removing the color 1 of the stage palette (which I changed from black to yellow)? Also, some stage tiles are being flipped when Ken goes in front of them. Edit: Fixed Ken's tiles having a black background in front of the horizon. Street Fighter II' Remaster System (Brazil) (En)-03.png (10.13 KB)

xfixium Joined: 18 Jul 2020 Posts: 392	Posted: Wed Aug 30, 2023 9:17 pm
xfixium Joined: 18 Jul 2020 Posts: 392	mankrip wrote Hi, I'm finishing a remake of the Ken stage, but the game is having some issues (see screenshot). Is there any way to fix this without removing the color 1 of the stage palette (which I changed from black to yellow)? Also, what's up with Ken's tiles having a black background in front of the horizon? You'll have to reindex all of Ken's graphics to use the yellow color, that was once his outline color. Typically the first 10-12 BG colors are reserved for the fighter belonging to the stage (Ken). 0 is reserved for the tile merging code as a "transparent" color. You could reimport through SMS Editor. The palette planning is a little delicate, as fire damage and hadoukens will also have to arranged sensibly. Do you have a black tile in the beginning of Ken's Stage tileset? If not, add one. That typically is the reason why the black blocking happens. SMS Editor has a Add Tile button to do that, if you're using it. Edit: Quote Also, some stage tiles are being flipped when Ken goes in front of them. This happens if vertical flipping is used to optimize the tileset. The game's merging code only supports horizontal flipping.

mankrip Joined: 02 Mar 2023 Posts: 14	Posted: Wed Aug 30, 2023 11:28 pm
mankrip Joined: 02 Mar 2023 Posts: 14	Well, I've eliminated the extra yellow color to fix Ken's colors, and fixed the horizon tile blacking out. This comparison image is from before the extra yellow color was removed. The buggy vertical flipping would take too many sacrifices to fix, so I'm going to release this version as is. I'm releasing it as the SMS Editor project file. I've also improved Ryu's stage a little bit. Truth be told, TecToy developers sucks at programming. This game has major collision and input recognition bugs besides the choppy movement, and the lack of support for vertical flipping is simply dumb. I've edited Ken's stage as a challenge to myself, to see how much I could improve it, and I was also going to do some major edits to the ocean waves at the bottom part of the image, but since the game doesn't support vertical flipping of tiles there's no point in going further. Feel free to use my changes in any way you want. Would be nice if someone created a new SF2 port for the SMS from the ground up, to make it as good as the SMS can handle. Ken Stage comparison big.png (59.4 KB) sf2_RemasterSystem.7z (1005.03 KB)

xfixium Joined: 18 Jul 2020 Posts: 392	Posted: Thu Aug 31, 2023 1:13 am
xfixium Joined: 18 Jul 2020 Posts: 392	mankrip wrote Well, I've eliminated the extra yellow color to fix Ken's colors, and fixed the horizon tile blacking out. This comparison image is from before the extra yellow color was removed. The buggy vertical flipping would take too many sacrifices to fix, so I'm going to release this version as is. I'm releasing it as the SMS Editor project file. I've also improved Ryu's stage a little bit. Truth be told, TecToy developers sucks at programming. This game has major collision and input recognition bugs besides the choppy movement, and the lack of support for vertical flipping is simply dumb. I've edited Ken's stage as a challenge to myself, to see how much I could improve it, and I was also going to do some major edits to the ocean waves at the bottom part of the image, but since the game doesn't support vertical flipping of tiles there's no point in going further. Feel free to use my changes in any way you want. Would be nice if someone created a new SF2 port for the SMS from the ground up, to make it as good as the SMS can handle. I like what you did with it. Adding back in some of the lost details. Like the life preservers, the cleat hitches, tire, etc.. etc... The smoke stack is very nicely done. The dithering on the dark parts of the main boat. AA on the white paneling. The shading done on the bottom half of the boat reminds me of what Mondo did for the Castlevania stage floor tiles recently. Overall, it looks cleaner.

mankrip Joined: 02 Mar 2023 Posts: 14	Posted: Thu Aug 31, 2023 10:53 am
mankrip Joined: 02 Mar 2023 Posts: 14	I think a good way to create a new fighting game engine for the SMS would be to do it mostly with sprites, like Jang Pung 3 did, and only use background tiles for the stationary actions. For example, Ryu's hadouken animation could be entirely done with background tiles since he doesn't move around while doing it, but his shoryuken and tatsumaki sempukyaku would have to be done using sprites. Likewise, grounded punches and kicks could be done with background tiles, while aerial punches and kicks would have to be done with sprites. Damage animations would have to be done using sprites, but the last frame of the beaten player lying down in the floor could be done with background tiles. Some logic would have to be implemented to keep the physics constrained to 8x8 tile movements, while interpolating sprite-based movements between tile positions. Maybe it could be done the other way around, by making the physics pixel-perfect but rounding the stationary positions to 8x8 pixels (this would require some extra logic to round up higher sub-tile precision, while rounding down lower sub-tile precision; could be done with a lookup table). Doing it this way would eliminate most cases of sprite flickering, while allowing for smooth gameplay.

ichigobankai Joined: 04 Jul 2010 Posts: 546 Location: Angers, France	Posted: Thu Aug 31, 2023 12:39 pm
	fusionning tiles & sprites is a very slow process (heavy cpu eating), so your gameplay will always suck. Unless you're using an advanced mapper with some new functions to pre calculate data for you...

rotherss Joined: 26 Dec 2022 Posts: 8	Posted: Thu Aug 31, 2023 4:02 pm
rotherss Joined: 26 Dec 2022 Posts: 8	Can you explain why it would be slow? The hardware supports using sprites as tiles. Is it really that slow to use that feature? I see games manipulating the tiles to create parallax scrolling at 60fps. Doing things like this on the Gameboy is super fast if it's just a few tiles. You'd also have to only have one palette of 16 colours for the whole game I understand that limit.

mankrip Joined: 02 Mar 2023 Posts: 14	Posted: Thu Aug 31, 2023 4:33 pm
mankrip Joined: 02 Mar 2023 Posts: 14	I meant "smooth gameplay" in space, not time. It's about being able to move at multiples of 1 pixel instead of being forced to move 8 pixels at a time. Anyway, a way to minimize the amount of processing required for merging a player's background tiles is to track the amount of sprites per tile row, and only generate enough background tiles to prevent flickering, instead of generating background tiles for the entire player's frame. This way, the same player would be partially made of sprites, and partially made of background tiles. So, in the end the logic would be more or less like this: 1) If stationary, allow the player to be made of background tiles. 2) If the player is allowed to be made of background tiles, compute the amount of tiles actually needed per row. 3) Draw the needed background tiles, and use sprites for the rest.

ichigobankai Joined: 04 Jul 2010 Posts: 546 Location: Angers, France	Posted: Thu Aug 31, 2023 4:39 pm
	So you've not understand/dig how Street Fighter 2 or Mortal Kombat or Golden Axe are made on SMS ;) Sprites are "movable" tiles, but only using pal 2 (index 16-31) move ±1px tiles are fix, based on a 8x8px grid and can use pal 1 & 2 (0 to 31) to be short more than 8 sprites on a line show flickering (disappear) so to make 2 huge sprites for a vs. fighting game, somes have the idea to fusion a background tile (8x8 bloc behind the sprite) and the sprite itself, using the transparent color (index 0) as a mask. - problems : * your sprite can be anywhere on screen * to fusion the background and the sprite, the sprite should also use the same pal (only 1 pal can be used on a 8x8 tile) * as your sprite is not on a 8x8 grid, you'll certainly have few tiles to generate with the background behind him (more than the sprite itself) so you should keep many free VRAM. * time to generate each fusionned tile is far to be free • ultimately you'll have to update the tilemap with the tiles freshly generated ... * then all the rest of the game engine. parallax have nothing to do with this sort of things, far easier and controlled by the hardware (simple / fast) mankrip wrote I meant "smooth gameplay" in space, not time. It's about being able to move at multiples of 1 pixel instead of being forced to move 8 pixels at a time. Pretty sure they have deliberately chosen a movement on 8px to compensate the huge time taken by the fusion process and the size in VRAM (easier to estimate)

mankrip Joined: 02 Mar 2023 Posts: 14	Posted: Thu Aug 31, 2023 5:33 pm
mankrip Joined: 02 Mar 2023 Posts: 14	ichigobankai, you did not pay attention to what I said in this reply. Everything you said was already taken into consideration here. mankrip wrote I think a good way to create a new fighting game engine for the SMS would be to do it mostly with sprites, like Jang Pung 3 did, and only use background tiles for the stationary actions. For example, Ryu's hadouken animation could be entirely done with background tiles since he doesn't move around while doing it, but his shoryuken and tatsumaki sempukyaku would have to be done using sprites. Likewise, grounded punches and kicks could be done with background tiles, while aerial punches and kicks would have to be done with sprites. Damage animations would have to be done using sprites, but the last frame of the beaten player lying down in the floor could be done with background tiles. Some logic would have to be implemented to keep the physics constrained to 8x8 tile movements, while interpolating sprite-based movements between tile positions. Maybe it could be done the other way around, by making the physics pixel-perfect but rounding the stationary positions to 8x8 pixels (this would require some extra logic to round up higher sub-tile precision, while rounding down lower sub-tile precision; could be done with a lookup table). Doing it this way would eliminate most cases of sprite flickering, while allowing for smooth gameplay.

ichigobankai Joined: 04 Jul 2010 Posts: 546 Location: Angers, France	Posted: Thu Aug 31, 2023 5:40 pm
	yes i've read what you've wrote earlier. time to code my friend.

segarule Joined: 23 Jan 2010 Posts: 458	Posted: Fri Sep 01, 2023 12:36 am
segarule Joined: 23 Jan 2010 Posts: 458	Funny how new members think that know more than experts here. IMHO, Jang Pung 3 is the best fighting vs game for SMS. Better even that some 16 bits games in genre. It have flicker? Yes, but i prefer a game with fllcker and very good gameplay than a with no flicker and poor game moves. If somebody want do something good is better hack it Jang Pung 3 or Sangokuchi 3 and put SF sprites on it. @xfixium already did miracles with SF2.

ichigobankai Joined: 04 Jul 2010 Posts: 546 Location: Angers, France	Posted: Fri Sep 01, 2023 7:21 am
	There's also the very nice Masters of Combat on SMS ;) and +1 for xfixium work ! The base material was far to be good and he did an impressive cosmetic job. I've made an advanced mapper weeks ago that can surely do some miracles on games likes SF2 or MK (as i've added DMA transfert, precalc fusion tiles/sprites, decompressing zx7 / psgaiden...), but I didn't made it for ports, repro or hacks.

sverx Joined: 05 Sep 2013 Posts: 3941 Location: Stockholm, Sweden	Posted: Fri Sep 01, 2023 9:03 am
	ichigobankai wrote I've made an advanced mapper weeks ago that can surely do some miracles on games likes SF2 or MK (as i've added DMA transfert, precalc fusion tiles/sprites, decompressing zx7 / psgaiden...), but I didn't made it for ports, repro or hacks. Sorry to derail this topic but - would you care to explain the 'precalc fusion tiles/sprites' feature? :)

ichigobankai Joined: 04 Jul 2010 Posts: 546 Location: Angers, France	Posted: Fri Sep 01, 2023 10:24 am
	you have to send sprite bank/adr, tile bank/adr, sram bank/adr (for the adr result) to a register. The 32 bytes fusion thing is available on slot 2. Like SF2 etc, it will use the sprite color 0 as a mask for the background tile. It take only few cycles to generate. This feature is more a POC than a real thing (as 8x8 based), it can be ameliorated. There's 6 x 16ko sram banks, so you can prepare/uncompress a lot of things.

sverx Joined: 05 Sep 2013 Posts: 3941 Location: Stockholm, Sweden	Posted: Fri Sep 01, 2023 1:27 pm
	so it basically it lays down one tile on top of another to create a third one using color 0 transparency in hardware? but tiles need to be perfectly aligned I guess...?

ichigobankai Joined: 04 Jul 2010 Posts: 546 Location: Angers, France	Posted: Fri Sep 01, 2023 2:19 pm
	Exactly like golden axe, sf2 or mk Unaligned sprite will be harder to generate but faisible with the mcu (btw you'll need to keep far more vram free)

law81 Joined: 21 Oct 2015 Posts: 304	Posted: Fri Sep 01, 2023 2:38 pm
law81 Joined: 21 Oct 2015 Posts: 304	Can't wait to see GG Paprium....😉

Jolene Joined: 31 Dec 2022 Posts: 30	Posted: Sun Sep 03, 2023 12:22 am
Jolene Joined: 31 Dec 2022 Posts: 30	Since no one mentioned it yet-there is a new 2023 opensource 1 vs 1 fighting game engine it is called Chibi fighter 2 and works on the master system as mentioned in the few youtube videos and below about it as the author Chibiakumas explains in detail it not a ROM hack but coded from scratch.Both the players move 1 pixel at a time I can see from the you tube video.I didnt find the master system ROM for ChibiFighter 2 yet. But as can be seen from the Chibiakumas youtube videos it works on the master system. mankrip wrote I think a good way to create a new fighting game engine for the SMS would be to do it mostly with sprites, like Jang Pung 3 did, and only use background tiles for the stationary actions. For example, Ryu's hadouken animation could be entirely done with background tiles since he doesn't move around while doing it, but his shoryuken and tatsumaki sempukyaku would have to be done using sprites. Likewise, grounded punches and kicks could be done with background tiles, while aerial punches and kicks would have to be done with sprites. Damage animations would have to be done using sprites, but the last frame of the beaten player lying down in the floor could be done with background tiles. Some logic would have to be implemented to keep the physics constrained to 8x8 tile movements, while interpolating sprite-based movements between tile positions. Maybe it could be done the other way around, by making the physics pixel-perfect but rounding the stationary positions to 8x8 pixels (this would require some extra logic to round up higher sub-tile precision, while rounding down lower sub-tile precision; could be done with a lookup table). Doing it this way would eliminate most cases of sprite flickering, while allowing for smooth gameplay.

haroldoop Joined: 25 Feb 2006 Posts: 904 Location: Belo Horizonte, MG, Brazil	Posted: Sun Sep 03, 2023 12:11 pm
	Jolene wrote Since no one mentioned it yet-there is a new 2023 opensource 1 vs 1 fighting game engine it is called Chibi fighter 2 and works on the master system as mentioned in the few youtube videos and below about it as the author Chibiakumas explains in detail it not a ROM hack but coded from scratch.Both the players move 1 pixel at a time I can see from the you tube video.I didnt find the master system ROM for ChibiFighter 2 yet. But as can be seen from the Chibiakumas youtube videos it works on the master system. mankrip wrote I think a good way to create a new fighting game engine for the SMS would be to do it mostly with sprites, like Jang Pung 3 did, and only use background tiles for the stationary actions. For example, Ryu's hadouken animation could be entirely done with background tiles since he doesn't move around while doing it, but his shoryuken and tatsumaki sempukyaku would have to be done using sprites. Likewise, grounded punches and kicks could be done with background tiles, while aerial punches and kicks would have to be done with sprites. Damage animations would have to be done using sprites, but the last frame of the beaten player lying down in the floor could be done with background tiles. Some logic would have to be implemented to keep the physics constrained to 8x8 tile movements, while interpolating sprite-based movements between tile positions. Maybe it could be done the other way around, by making the physics pixel-perfect but rounding the stationary positions to 8x8 pixels (this would require some extra logic to round up higher sub-tile precision, while rounding down lower sub-tile precision; could be done with a lookup table). Doing it this way would eliminate most cases of sprite flickering, while allowing for smooth gameplay. Judging from the video, it seems pretty choppy. Also, there's no tile merging: please notice the black borders around the sprites. Here's their source code: https://www.chibiakumas.com/z80/chibifighter.php#LessonCF4 BTW,one way to completely avoid tile merging would be to use the trick used on Rise of The Robots on Game Gear: the backgrounds are a solid color, with some color variation obtained by using the raster ints for changing the background color: %3D%3D Not sure if this is an advisable design, though.. :P

maxxoccupancy Joined: 05 Mar 2022 Posts: 129 Location: Seabrook, New Hampshire	Posted: Sat Sep 09, 2023 11:07 pm
	mankrip wrote I think a good way to create a new fighting game engine for the SMS would be to do it mostly with sprites, like Jang Pung 3 did, and only use background tiles for the stationary actions. For example, Ryu's hadouken animation could be entirely done with background tiles since he doesn't move around while doing it, but his shoryuken and tatsumaki sempukyaku would have to be done using sprites. Likewise, grounded punches and kicks could be done with background tiles, while aerial punches and kicks would have to be done with sprites. Damage animations would have to be done using sprites, but the last frame of the beaten player lying down in the floor could be done with background tiles. Some logic would have to be implemented to keep the physics constrained to 8x8 tile movements, while interpolating sprite-based movements between tile positions. Maybe it could be done the other way around, by making the physics pixel-perfect but rounding the stationary positions to 8x8 pixels (this would require some extra logic to round up higher sub-tile precision, while rounding down lower sub-tile precision; could be done with a lookup table). Doing it this way would eliminate most cases of sprite flickering, while allowing for smooth gameplay. I feel like I've said this before. A few times even. Jang Pang 3 uses all sprites and accepts flicker. However, when flicker occurs (disappearing sprites), we could replace those sprites only, drawing them as background tiles. This would only require a handful of sprites to be redrawn once in a while, and we would not need to get them exact. For example, we might only replace a few body tiles with a standard, more or less solid background tile of the color/pattern of the character's outfit. Since there are only a few colors or patterns, we'd only need a few. By replacing body tile sprites with background tiles, we could minimize the number of tiles to be redrawn and minimize the need to mix them with actual backgrounds. So the framerate would certainly drop from 60fps to 30fps to avoid flicker, albeit with flicker blanking replaced with a few solid, correctly colored blocks. And in rare instances where that's not clear enough, we could take the sprite tiles from the ROM cart and manually mix them with background tiles, ala Tectoy's SF2, dropping down to 10-15 fps.

mankrip Joined: 02 Mar 2023 Posts: 14	Posted: Sun Sep 10, 2023 1:44 am
mankrip Joined: 02 Mar 2023 Posts: 14	maxxoccupancy wrote By replacing body tile sprites with background tiles, we could minimize the number of tiles to be redrawn and minimize the need to mix them with actual backgrounds. Tile merging must indeed be the most costly operation performed by the SF2 renderer. Prioritizing tiles without transparent colors in the background tile replacement process, and using sprites for the rest would indeed be much faster to render. In this mockup, the tiles on the left should be rendered as sprite tiles, while the tiles on the right could be rendered as background tiles. This alone frees enough sprite tiles for both players to do this move without flickering, and without tile merging (just straightforward tile copying instead). To achieve that, I changed the tiling offsets to maximize the amount of tiles without transparent pixels. However, this would affect the game's physics since the collision would have to be adjusted to the new offsets. Anyway, the point of the idea mentioned in my previous posts was not to completely eliminate flickering, and wasn't to achieve high framerates either. My point is to reach a middle ground, where flickering would be reduced to a minimum (but would still exist), and the performance would be increased just enough to allow for pixel-accurate movement. Another idea on how to deal with flickering is to focus the flickering on the sprite tiles from the back to the front of the characters. So, when you kick someone, your butt may disappear but your foot will still be visible, allowing players to keep their focus on the parts of the body where the combat physics actually happens. SMS sprites and tiles.png (1.33 KB)

maxxoccupancy Joined: 05 Mar 2022 Posts: 129 Location: Seabrook, New Hampshire	SMS Street Fighter 2 ROM Hack Posted: Sun Sep 10, 2023 6:15 am
	I would go even further, given the game genre: I would rather have a flickering nightmare WORSE than Jang Pong 3 and R-Type combined that try to play a fighting game at 10-15 FPS... even if it otherwise looked exactly like the arcade. I would even squish the two characters down to 4 tiles wide each to achieve this. Fighting games need to run and take input at 60fps or better. That's 9,000 Z80 instructions per frame. Big, brutal fighting games are what finally killed the 8-bit market for good, though the SMS held out the longest. It's the lack of cpu power and sprite handling that sank the NES and its nadir. Whatever can't be done in 16ms just shouldn't even be attempted in fighting games, flicker or width be damned. Throw the details above and below the two characters so that we can merge background tiles more quickly. SEGA has always suffered from the desire to push graphics and image fidelity above playability. Obviously, Ni****do went completely the other way, and we've seen the results in the marketplace.

Forums

View topic - SMS Street Fighter 2 ROM Hack