Enjoying your froyo?

[AWJ]

What I don't get is how they managed to get Street Fighter Alpha 2 to hang for multiple seconds before every fight. Even with a 224-line active display, which they are not using, the SNES should be able to fill all of its memory (VRAM, WRAM, audio RAM) in a little over half a second. There's no SRAM. The S-DD1 can decompress graphics at the speed of DMA, and compressing BRR does nothing anyway. I can't imagine there's much precalculation to do. So what's the holdup?

I heard game is busy unpacking data at this point but why they weren't able to "hide" that unpacking process (in the versus screen for instance), no idea...

IIRC someone looked at what SFA2 is doing during the pause at the start of each round, and discovered that it's simply transferring data to the APU the entire time. The "Round... xxx... fight!" speech is quite high quality and takes up a big chunk of APU RAM; they overwrite it with the music/instrument/voice data for the match after playing it. They probably could have figured out a better way to do it without that horrible long pause, but I guess they didn't have a programmer with the SPC700 chops to do it or just didn't care.

[93143]

IIRC someone looked at what SFA2 is doing during the pause at the start of each round, and discovered that it's simply transferring data to the APU the entire time. The "Round... xxx... fight!" speech is quite high quality and takes up a big chunk of APU RAM; they overwrite it with the music/instrument/voice data for the match after playing it. They probably could have figured out a better way to do it without that horrible long pause, but I guess they didn't have a programmer with the SPC700 chops to do it or just didn't care.

I rather suspected that, considering the game hangs momentarily every time the announcer has to say something new.

I bet an HDMA audio streaming engine (plus a faster bulk APU loader) would get rid of the pauses and allow much higher-quality music. Maybe higher-quality voice samples too. I also wonder if it was really necessary to cut so much off the top and bottom of the image and still have such small sprites...

Kinda makes me want to re-port it. But that would be a gigantic task, and I'm already porting a game to the SNES, never mind that I have half a dozen other hobbies on the back burner, not to mention my actual work... and it's not like I'm a fighting game nut in the first place...

[Drew Sebastino]

Kinda makes me want to re-port it. But that would be a gigantic task, and I'm already porting a game to the SNES, never mind that I have half a dozen other hobbies on the back burner, not to mention my actual work... and it's not like I'm a fighting game nut in the first place...

I'd be more interested in the original SF2, simply because I like it more. In fact, it's probably the only fighting game I like. And yes, the small sprites are unreasonable. I cleaned up the shrinked sprite I made in about 5 minutes, and it makes me wonder why Capcom didn't just do this, considering it's considerably more work to make it look good if you shrink it both vertically and horizontally. I also added a hadoken for the heck of it, and it looks perfectly fine also.

Clean Sprite.png (6.55 KiB) Viewed 3174 times

I might resize all the Ryu sprites, which should only take about a couple of hours tops to clean them all up. The one think I would be concerned about though is the tilemap... (If the game was horizontally squashed, you could at least use hdma to keep the palette and character area proportional)

Still, no one knows about if the Street Fighter 2 source code?

Actually, who am I kidding, I've got more than enough things to do. I still think Capcom didn't need those giant bars.

[93143]

I did this a while back, the first time I contemplated Alpha 2 (new file date due to minor tweaks and a new comparison sprite from the actual port):

Dan_SNES.png (7.9 KiB) Viewed 3151 times

Dan_SNESscreen.png (20.49 KiB) Viewed 3151 times

Mind you, Zangief is quite large in this game... Birdie, Sodom Katana and Vega Bison aren't small either...

[mikejmoffitt]

What I don't get is how they managed to get Street Fighter Alpha 2 to hang for multiple seconds before every fight. Even with a 224-line active display, which they are not using, the SNES should be able to fill all of its memory (VRAM, WRAM, audio RAM) in a little over half a second. There's no SRAM. The S-DD1 can decompress graphics at the speed of DMA, and compressing BRR does nothing anyway. I can't imagine there's much precalculation to do. So what's the holdup?

I heard game is busy unpacking data at this point but why they weren't able to "hide" that unpacking process (in the versus screen for instance), no idea...

IIRC someone looked at what SFA2 is doing during the pause at the start of each round, and discovered that it's simply transferring data to the APU the entire time. The "Round... xxx... fight!" speech is quite high quality and takes up a big chunk of APU RAM; they overwrite it with the music/instrument/voice data for the match after playing it. They probably could have figured out a better way to do it without that horrible long pause, but I guess they didn't have a programmer with the SPC700 chops to do it or just didn't care.

The first change I'd make to SFA2 on SNES is the awful instruments used for the music. It is as if the music was forgotten until the last day.

[Sik]

I also wonder if it was really necessary to cut so much off the top and bottom of the image and still have such small sprites...

How much ROM space do they take up?

[tepples]

It's very likely that they made the graphics small enough to fit in the cartridges being sold at the time. The arcade games were all at least 58.5 Mbit:

• Street Fighter II for CPS1 is 8 Mbit PRG ROM, 48 Mbit CHR ROM, 2 Mbit of audio samples, and a 512 kbit APU program.
• Hyper Fighting (aka Turbo) expands PRG ROM to 12 Mbit.
• Super for CPS2 is 20 Mbit PRG ROM, 96 Mbit CHR ROM, 32 Mbit of QSound samples, and a 1 Mbit APU program.
• Super Turbo expands PRG ROM to 28 Mbit and the APU program to 2 Mbit.

The console versions were a lot smaller. The original Street Fighter II for Super NES was 16 Mbit, Turbo was 20 Mbit to support player use of boss characters plus frames for a couple new moves, and Super was 32 Mbit to support the five new characters (including a new Ken replacing what was largely a head-swapped Ryu) and more new moves.

psycopathicteen claims that console Street Fighter II shares code with console Final Fight. Prototypes of Final Fight were called Street Fighter '89. I wonder how much code arcade Street Fighter II shares with arcade Final Fight.

And no, bars aren't necessarily bad. A game with a 256x176 pixel playfield (NTSC) or a 256x208 playfield (PAL) would have huge bars but would zoom well on a modern TV without cutting off more than a couple pixels at the top and bottom, especially if it uses interlace.

[93143]

Star Ocean was released before SFA2, used the same chip plus a save RAM, and was 50% larger.

Still, I can certainly see Capcom deciding 32 Mb of fast ROM should be plenty and designing to that target...

If I were trying to improve on the port, which I'm not, it might be worth considering a two-stage effort: first, try to fix or at least ameliorate the pauses and the terrible music in the original without expanding the ROM; second, boost the size of the graphics and the quality of the sound and music by going to 48 or 64 Mb (or even higher if necessary). After all, the Nintendo 64 was out by this point - or were 8-bit ROMs more expensive for a given size?

It does seem to me that a moderate-sized S-DD1 cart (32 Mb or less?) should allow a more or less arcade-perfect Street Fighter II port, at least graphically...

...

Regarding HDMA streaming, does anyone know if it's reasonable to expect to be able to write a general-purpose audio engine capable of turning around fast enough to reliably grab a command byte and a couple bytes of sample data from the I/O ports every scanline while playing music? Or if one scanline is too fast, maybe a few bytes every two or three scanlines? I want this for my shmup port, so it's not an academic question...

...at 3 BRR bytes per shot, plus the line counter (if not firing every scanline) and an APU control byte, it seems storing audio in HDMA format is only slightly smaller than uncompressed 8-bit PCM... but it sure simplifies the CPU-side handling...

And no, bars aren't necessarily bad. A game with a 256x176 pixel playfield (NTSC) or a 256x208 playfield (PAL) would have huge bars but would zoom well on a modern TV without cutting off more than a couple pixels at the top and bottom, especially if it uses interlace.

I'm not designing for a modern "TV", still less would Capcom have been. I don't see why I should sacrifice quality for a widescreen experience at SNES resolution, besides which a lot of the games I like (including the one I'm porting) don't work well with even a little bit of lag.

(I'm sorry; I'm just really annoyed that you can't plug an old console into an HDTV and expect a usable result.

I wonder if it's possible to make an HDTV that can straight-up emulate an NTSC CRT with sub-millisecond lag, converting each scanline as it comes in, overwriting the 1080p image buffer one 240p (or 480i) line at a time and updating the display progressively to minimize the buffering delay... and of course responding properly to slightly nonstandard signals that would work perfectly on a CRT but tend to confuse modern image conversion algorithms...

And now you've got me thinking about hires modes. Since "retro" graphics are in vogue, or were last time I checked, maybe a high-resolution SNES game could be well-received. You wouldn't have enough VRAM or PPU time for the florid multilayer design aesthetic seen in high-end official SNES games, but you'd have way more real estate, and widescreen wouldn't feel cramped.)

[lidnariq]

I wonder if it's possible to make an HDTV that can straight-up emulate an NTSC CRT with sub-millisecond lag, converting each scanline as it comes in, overwriting the 1080p image buffer one 240p (or 480i) line at a time and updating the display progressively to minimize the buffering delay... and of course responding properly to slightly nonstandard signals that would work perfectly on a CRT but tend to confuse modern image conversion algorithms...

Of course it's possible. Vendors have simply decided it's not worth the effort.

[Khaz]

I wonder if it's possible to make an HDTV that can straight-up emulate an NTSC CRT with sub-millisecond lag, converting each scanline as it comes in, overwriting the 1080p image buffer one 240p (or 480i) line at a time and updating the display progressively to minimize the buffering delay... and of course responding properly to slightly nonstandard signals that would work perfectly on a CRT but tend to confuse modern image conversion algorithms...

Of course it's possible. Vendors have simply decided it's not worth the effort.

And people wonder why I still play all my games on a CRT.

[rainwarrior]

Of course it's possible. Vendors have simply decided it's not worth the effort.

And people wonder why I still play all my games on a CRT.

The biggest reasons I can think of why it's not worth the effort:
1. The people who actually realize there's a difference and would care enough to buy such a TV is a small subset of the (already relatively small) retro-gamers market.
2. Their solution would be competing with CRTs, which are currently very cheap and available.
3. Additional competition with existing partial solutions like the XRGB Framemeister.

I think the market is just too small for a TV manufacturer to want to address. There isn't enough to gain, and making TVs is a mass-market thing. The only thing that would get this done is a hobbyist who really cares about it, like what Kevtris is doing with the HD NES, or even the XRGB is in a category of devices that can be made by one person or a small company. I've never seen a hobbyist making a custom HDTV; I think that might be too big a project for such a small scale of return.

[Drew Sebastino]

And people wonder why I still play all my games on a CRT.

My mother got rid of mine.

Mind you, Zangief is quite large in this game...

Well, this is what I did:

Zangief SNES.png (3.72 KiB) Viewed 3033 times

It's 51 sprites (I could have easily done it in less than half the amount if I weren't trying to save tiles...) and in 92 tiles, which is almost exactly half. You'd definitely need to double buffer... (which it should then be perfectly fine.)

You know, just shrinking these sprites actually turned out pretty good, as I didn't even tamper with it. I honestly have no clue as to why Capcom would create an arcade machine with a crazy wide resolution when a ton of its games run on 3:4 monitors. I'd imagine they could have gone with 320x224 and added an extra BG layer or more sprite overdraw or something.

[mikejmoffitt]

And people wonder why I still play all my games on a CRT.

My mother got rid of mine.

Mind you, Zangief is quite large in this game...

Well, this is what I did:

Zangief SNES.png

It's 51 sprites (I could have easily done it in less than half the amount if I weren't trying to save tiles...) and in 92 tiles, which is almost exactly half. You'd definitely need to double buffer... (which it should then be perfectly fine.)

You know, just shrinking these sprites actually turned out pretty good, as I didn't even tamper with it. I honestly have no clue as to why Capcom would create an arcade machine with a crazy wide resolution when a ton of its games run on 3:4 monitors. I'd imagine they could have gone with 320x224 and added an extra BG layer or more sprite overdraw or something.

The game isn't "wide", it is designed for 4:3. It has a tall pixel aspect ratio, similar to how the NES has an 8:7 fat pixel aspect ratio. Conversely the CPS1/2 and similar systems can pack in a little more horizontal detail. It is intended to be "squished" to a 4:3 aspect.

[Drew Sebastino]

3:4 monitors

Oops, I meant 4:3.

Conversely the CPS1/2 and similar systems can pack in a little more horizontal detail. It is intended to be "squished" to a 4:3 aspect.

I thought the main goal was generally to have square pixels. If possible, I would have tried to cut some pixels off the sides and add them to the top and bottom for not as much horizontal detail, but more vertical detail. It would make me crazy trying to stretch out all the artwork for that aspect ratio. I suppose whatever they where using to make the artwork could have also been running at a similar aspect ratio. The main reason I thought they did this was for vertical shooters, and it looks fine squashed anyway so they didn't bother.

[lidnariq]

Square pixels were converged on solely because everything else is sillier. But there's no particular reason—especially on CRTs with "soft" pixels unlike modern LCD/plasma "hard" pixels—to pick any given PAR over any other.

Subpixel rendering on LCDs uses a PAR of 1:3.

The 256px/512px (8:7, 4:7) modes enforced by the ColecoVision, NES, SNES, and available on the Genesis, TG16, and PS1 were chosen for the convenience of having a width that was a power of 2.
The 160px/320px/640px (12:7, 6:7, 3:7) modes enforced by the Atari 2600, 5200, 7800, IBM CGA, and available on the Genesis and TG16 were chosen because then the same clock could be used for both pixels and color encoding.

The PS1's 320/370/640px (≈10:11/8:11/19:40 NTSC ; ≈10:9/5:6/21:40 PAL) modes are a little weirder, but they come from only being able to use pixel clocks that were integer divisions of (NTSC×15=53.7MHz ; PAL×12=53.2MHz)

The VIC-20 (3:2 NTSC or 5:3 PAL) and C64's (3:4 or 5:6) pixel clocks were chosen to produce an actually perfectly NTSC/PAL compliant signal (at least, other than progressive scan vs interlace), unlike the vast majority of their contemporaries.