Street Fighter Alpha Mockup

Announce (tech) demos or games releases

Moderator: Mask of Destiny

hotrodx
Interested
Posts: 49
Joined: Thu Mar 21, 2019 1:23 pm

Street Fighter Alpha Mockup

Post by hotrodx » Wed Oct 23, 2019 5:59 pm

Someone in the Sega-16 boards asked whether the MegaDrive can do a game like Street Fighter Alpha. There was an SFA2 port on the SNES, and I guess if someone uses those assets, probably it can minus some effects (like the Z animation intro in every battle).

Still, I tried experimenting with a SFA mockup. 320x224 resolution (instead of the 256x192 letterboxed in SFA2 SNES). Arcade-ripped character sprites. SNES-style background. Somehow, now I can appreciate the effort Capcom did with SF2 (but the SSF2 music is still awful).

In hindsight, I do think a 256x224 screen resolution is the way to go. With the smaller screen you can have smaller sprites so that you'd still have allowance for the bigger characters. Plus, the tile memory saved can go into the picturesque BGs of SFA, which doesn't lend well to optimizations such as flipping and duplicate tiles.
Attachments
sfa_test.zip
(159.22 KiB) Downloaded 299 times

haroldoop
Very interested
Posts: 113
Joined: Sun Apr 29, 2007 10:04 pm
Location: Belo Horizonte, MG, Brazil

Re: Street Fighter Alpha Mockup

Post by haroldoop » Wed Oct 23, 2019 11:32 pm

Looks nice!

vnsbr
Interested
Posts: 40
Joined: Sun Dec 17, 2017 4:13 pm

Re: Street Fighter Alpha Mockup

Post by vnsbr » Thu Oct 24, 2019 12:31 am

Great port so far!

Stef
Very interested
Posts: 2990
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Re: Street Fighter Alpha Mockup

Post by Stef » Fri Oct 25, 2019 9:33 am

It looks great ! I always though SFA2 could have receive a better port on MD than on SNES using the H40 mode.
Here you used the full resolution but i believe 320x200 would be better so you can update big sprites with the higher DMA capacity and also for before arcade aspect ratio conservation.

Sik
Very interested
Posts: 899
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Street Fighter Alpha Mockup

Post by Sik » Fri Oct 25, 2019 10:25 am

You can work around the sprite update issue by making sure only one updates at a time (e.g. if both need to update at once, then delay one of the players by one frame). Keep hitbox processing and momentum and such all working as normal, this only affects the sprite being shown on screen. I've tried it and in practice it's not noticeable.

Note that it's an issue only in NTSC as PAL has a much bigger vblank time, so you probably would want to do that only if the console is NTSC (and allow loading both at the same time in PAL, which also nicely balances out against the slower framerate). And of course, in the very first frame (before fading in) you also need to force both sprites to load.
Sik is pronounced as "seek", not as "sick".

Mauro Flores
Newbie
Posts: 5
Joined: Fri Feb 16, 2018 10:25 pm

Re: Street Fighter Alpha Mockup

Post by Mauro Flores » Fri Oct 25, 2019 1:12 pm

I would love to watch what would be possible with a Fighting Engine build in SGDK, keep it brother!

hotrodx
Interested
Posts: 49
Joined: Thu Mar 21, 2019 1:23 pm

Re: Street Fighter Alpha Mockup

Post by hotrodx » Fri Oct 25, 2019 1:34 pm

The CPS-2's resolution is tricky. Usually it's 384x224. It's got the same pixel height as an NTSC MD, but wider. Though was it treated as wide-screen or was it 4:3 in the arcades?

320x224 with 20% narrower sprites would be ok, but yeah 320x200 would be better. But how would you do letterboxing? Add black tiles on PRIORITY on PLAN_A? Might be uneven, though (2 tiles on top, 1 tile at the bottom), which is probably why we got the usual 192 pixel height in SF2 on 16-bit consoles.

In the previous build I tried applying flicker to the fireball and shadow to avoid going over the scanline sprite limit. Basically, player one's shadow and fireball flickers at even updates, while player two's at odd updates. That way, they don't both count to the limit at the same time. Though, it doesn't look as nice as I thought it would.

On the new build, I've removed the flickering, and adjusted the fireball sprites a bit. It's alright, but if you time it you can see it's hitting the scanline sprite limit.

Also, to clarify, I'm not porting SFA. However, it's been a nice experience because I got to experiment some stuff:
1. VRAM defragmenation
The animations were of different sizes and speeds, so switching between sprites was needed. But it was leaving too many "holes" in the VRAM. Eventually it will defrag (with the safe option), but it has a slight "glitchy" appearance to some sprites as it rearranges the sprite memory location.
For this kind of game, I think it's better to allocate a fixed area for a player's sprite. Newly switched animation will occupy the same location to avoid fragmenting the memory. It's not as efficient, as you have to preallocate each player's VRAM sprite memory for the largest possible tile count. But it's better than randomly filling the sprite VRAM.

2. Palette Consideration
Normally, you would need unique palettes for: PLAYER 1, PLAYER 2, BACKGROUND 1, PARALLAX BACKGROUND 2, UI, PROJECTILES. The MD's 4 palette limit is really restrictive.
So, if I were to make a fighting game, I would have to share some palette among elements. In here, I tried sharing the palette for PLAN_A, 8 colors for the far parallax BG, shared 8 colors for UI and projectiles. The far background can even use the 8 UI colors if necessary, as it is always "in there".
Something also to consider: White or Black colors may need two entries each in the palette. For example, Ryu has white clothes. He also has white in the eyes. If you palette swap his clothes, his eyes better not change as well.
I was thinking of switching palettes using H-Interrupt. The top UI can have its own 8 color. The projectiles, which never overlaps with the top and bottom UIs, can have it's own 8. While the bottom UI can have it's own 8 as well. They all share the BG's 8 colors (for a total of 16 color entries) because the BG overlaps them all. I haven't tried this idea, so I'm wondering if it's feasible.
Attachments
sfa_no_fireball_and_shadow_flicker.zip
(158.71 KiB) Downloaded 108 times

Sik
Very interested
Posts: 899
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Street Fighter Alpha Mockup

Post by Sik » Fri Oct 25, 2019 3:11 pm

hotrodx wrote:
Fri Oct 25, 2019 1:34 pm
The CPS-2's resolution is tricky. Usually it's 384x224. It's got the same pixel height as an NTSC MD, but wider. Though was it treated as wide-screen or was it 4:3 in the arcades?
It was 4:3 (with non-square pixels).
hotrodx wrote:
Fri Oct 25, 2019 1:34 pm
320x224 with 20% narrower sprites would be ok, but yeah 320x200 would be better. But how would you do letterboxing? Add black tiles on PRIORITY on PLAN_A? Might be uneven, though (2 tiles on top, 1 tile at the bottom), which is probably why we got the usual 192 pixel height in SF2 on 16-bit consoles.
Enable display at the 13th line and disable display at the 213th line (this requires raster effects), you can also ditch the vblank interrupt in favor of the interrupt that does the latter. The idea is to gain extra blanking time to be able to transfer more graphics in time.

I'm not sure it's really needed, but if you're going to trim lines you may as well do that.
hotrodx wrote:
Fri Oct 25, 2019 1:34 pm
In the previous build I tried applying flicker to the fireball and shadow to avoid going over the scanline sprite limit. Basically, player one's shadow and fireball flickers at even updates, while player two's at odd updates. That way, they don't both count to the limit at the same time. Though, it doesn't look as nice as I thought it would.

On the new build, I've removed the flickering, and adjusted the fireball sprites a bit. It's alright, but if you time it you can see it's hitting the scanline sprite limit.
For sprites that are used while on the ground, you should try baking the shadow into the sprites themselves. That way you reduce the bandwidth waste caused by overlapping sprites.
hotrodx wrote:
Fri Oct 25, 2019 1:34 pm
2. Palette Consideration
Normally, you would need unique palettes for: PLAYER 1, PLAYER 2, BACKGROUND 1, PARALLAX BACKGROUND 2, UI, PROJECTILES. The MD's 4 palette limit is really restrictive.
So, if I were to make a fighting game, I would have to share some palette among elements. In here, I tried sharing the palette for PLAN_A, 8 colors for the far parallax BG, shared 8 colors for UI and projectiles. The far background can even use the 8 UI colors if necessary, as it is always "in there".
Samurai Shodown assigns them as player 1, player 2, HUD+items and background (not in that order but doesn't matter).

Note that they actually had it more restrictive because of the referee and the guy tossing items into the field (and the items themselves), otherwise they could have probably given some more colors to the background. Projectiles use either their player's or the HUD+items palette, depending which one has more fitting colors available.
hotrodx wrote:
Fri Oct 25, 2019 1:34 pm
I was thinking of switching palettes using H-Interrupt. The top UI can have its own 8 color. The projectiles, which never overlaps with the top and bottom UIs, can have it's own 8. While the bottom UI can have it's own 8 as well. They all share the BG's 8 colors (for a total of 16 color entries) because the BG overlaps them all. I haven't tried this idea, so I'm wondering if it's feasible.
Now you're just straight up copying Samurai Shodown :​P (which swaps six colors where the health bars are) The character select is even more absurd (showing a grand total of eight unique palettes on screen that way). There are CRAM dots visible on screen, they just tried to make sure to leave them where you're least likely to be paying attention.
Sik is pronounced as "seek", not as "sick".

hotrodx
Interested
Posts: 49
Joined: Thu Mar 21, 2019 1:23 pm

Re: Street Fighter Alpha Mockup

Post by hotrodx » Fri Oct 25, 2019 3:38 pm

Thank you. That was very informative. I hope the other readers can pick up bits of info as well.

Miquel
Very interested
Posts: 469
Joined: Sat Jul 30, 2016 12:33 am

Re: Street Fighter Alpha Mockup

Post by Miquel » Fri Oct 25, 2019 6:51 pm

I can’t download the ROM so I can’t tell how exactly you did thinks but if I have to do something similar my approach will be clear:

During vblank around 7.4KB per frame can be upload to the VDP, so I will reserve a 2x 7KB on VRAM for each character and upload on every frame next character animation, if needed; even frames are reserved for player-0, odd frames for player-1. You definitely want (almost) all vblank period available ONLY for this.

Or even every 4 frames, the first 2 are reserved for top player-0, bottom player-0, then the last 2 for top player-1, bottom player-1. Will this be detectable? I don’t know.

That’s how NTSC works, I believe, anyway you should check this, even more if you crop the screen, since bandwidth is the sprite size limit factor. Definitely write your own vblank routine (screen off routine).
Help. Spanish TVs are brain washing people to be hostile to me.

Sik
Very interested
Posts: 899
Joined: Thu Apr 10, 2008 3:03 pm
Contact:

Re: Street Fighter Alpha Mockup

Post by Sik » Fri Oct 25, 2019 8:19 pm

You realize that 2×7KB×2 = 28KB which is almost half of VRAM, right? And also some of the bandwidth needs to be put aside for stuff like the sprite and scroll tables.

Incidentally the method I described goes by the assumption that each character isn't uploading a new image every frame, and when they do they aren't usually doing it at the same time — i.e. most of the time, the game only needs to upload either zero or one image, and in the case where both would try to update their graphics, usually the next frame is free (hence the "delay the other player's update" part).
Sik is pronounced as "seek", not as "sick".

Miquel
Very interested
Posts: 469
Joined: Sat Jul 30, 2016 12:33 am

Re: Street Fighter Alpha Mockup

Post by Miquel » Fri Oct 25, 2019 10:10 pm

On a fighting game both characters are the main and only focus, so half of VRAM sounds good to me; obviously it depends on game’s objectives/priorities.

When you say 2x2x7KB, I believe you are referring to uploading half character per frame; that would be the extreme case, the “definitive fighting game” so to say (if looks good doing this method).

Another thing to consider is both characters can be as big as 160x112 pixels, maximum.

My idea was to animate characters at 30fps, with one character one frame ahead, on a 60 fps game, in that case you don’t have to consider collisions at all, and its ramifications. But your idea works well too.

About uploading the sprite table, definitely the game has to have the ability to upload it per frame, but is not that big… was it 640bytes in worst case scenario?

Respect uploading the tile table is around 80bytes per frame on worst case scenario, but perhaps the table itself is big enough to fit the whole scenario. Some games go this way… I remember some basketball games doing so… don’t remember the tile.
Help. Spanish TVs are brain washing people to be hostile to me.

Mauro Flores
Newbie
Posts: 5
Joined: Fri Feb 16, 2018 10:25 pm

Re: Street Fighter Alpha Mockup

Post by Mauro Flores » Sat Nov 02, 2019 2:26 am

Is there some news about it? 😺

hotrodx
Interested
Posts: 49
Joined: Thu Mar 21, 2019 1:23 pm

Re: Street Fighter Alpha Mockup

Post by hotrodx » Sat Nov 02, 2019 4:49 am

Hi Mauro. Here's a build with a smoother fireball animation, as well as slightly faster idle animation.

Weren't you the one who makes the M.U.G.E.N.-type fighter for the MegaDrive? And also remaking the original Street Fighter? I believe you are more knowledgeable with the subject matter (creating fighting games for the MegaDrive), so perhaps you can share your insights about your experience. Like what technical hurdles you had to overcome, and what do you think you can improve upon.

Hopefully everyone can pick up some tips and ideas.
Attachments
rom_better_fireball.zip
(158.82 KiB) Downloaded 68 times

Mauro Flores
Newbie
Posts: 5
Joined: Fri Feb 16, 2018 10:25 pm

Re: Street Fighter Alpha Mockup

Post by Mauro Flores » Sat Nov 02, 2019 3:24 pm

I wrote the Genesis Fight Engine with Second Basic.
Unfortunately I don't know C language but I could help with the logic inside game loop.
I still don't use any tools to optimize sprites, I do manually using variables, and I also didn't use that binary map for physics, I made all it with X Y coordinates.

You guys can find me here 👌
https://discord.gg/Mqkamx

Post Reply