Enjoying your froyo?

[Near]

> Does this thread have anything at all to do with froyo?

They replaced the Cuzzin's chains up here with this "#froyo" place that is absolutely terrible. Nothing but ridiculous, gimmicky flavors now like "strawberry cheesecake", "oreo cookies", "triple fudge cake", etc. If I wanted those dessert flavors, I would eat those things.

Probably for the best that I eat less of it anyway. No fat, but I'm sure it was an obscene amount of sugar.

[tepples]

Does this thread have anything at all to do with froyo? What is going on? Why did you do this?

Because it has even less to do with "SNES Tilemap Editor", the topic from which it was split.

[Stef]

I thought that was a relatively new discovery, (coined "phantom bitmap" as I think tepples told me) and I'm 99% percent certain that Sonic 2 doesn't use it which they are showing off in the video.

A new discovery for homebrew scene but not for Sega developers The term blast processing just comes from the sentence the developer used back in time "by blasting data with DMA in CRam you can modify color fast enough to produce a full colored line" or something close to that... The marketing guys liked the "blast" word and decided to use it just as a reference about the general power of the machine and not about a specific feature.
Nothing to do with sonic 2 so, no game uses this trick.

I'm not denying this is a very impressive feat, and would have increased the look of Sega CD games greatly so we wouldn't have terrible looking ones like Road Avenger that use one palette (which isn't the systems fault, but having access to all 512 colors sure as heck looks better than only 61).

On Megadrive using that trick is not much of interest, it requires a lot of memory (you can only fill half of the screen with genesis ram) and it consumes many CPU time as it requires continuous DMA during the active bitmap display... Indeed it would have been much more interesting with the SegaCD where the sub CPU could prepare rendering in a part of of the word ram while the second part is being transfered by DMA to CRam.

I won't say I'll deny the SNES of similar marketing, like how I remember reading an article where the people made it seem like the SNES could run every video mode put together, like saying 4 BG layers and then 512x448 resolution. The specifications would but the GBA to shame. I can't help but feel that things like 64x64 sized sprites and high resolution mode where only put in for bragging rights, as they are terribly impractical. Doesn't the Turbographics 16 actually have 256x224, 320x224, and 512x448 resolution modes?

A lot of the SNES features appears to exist just to exhibit bigger numbers, and honestly back in time that worked :-p
We didn't known the constraints applying to these numbers...

Wow. Good job! I've always wanted to see someone try to fix that game.

So long time I wanted to fix it and honestly it was not difficult at all, the most difficult part was just to integrate well in their code.

I've always felt the same way. I always thought of it as unfair how the Genesis got shatted on with SF2 in that it uses the same small graphics as the SNES port, which wasn't even that great to begin with either. (tiny sprites even for the resolution, bad voice samples, worse music relative to the arcade, (whoever says otherwise is deaf)) Heck, I just now made this, showing how they could have just horizontally squashed the sprites (The middle is for the SNES. For the Genesis, use something exactly in between the CPS1 and SNES ones in size. I didn't touch anything up) and it would have looked better than what they did (I could only find Ken, but close enough)
...
... I bet they just wanted to get it done in time and knew it would sell like hotcakes regardless.

Honestly there is weird things in the code of this game. For instance it can transfer data at same location in VRam twice during a single frame, a real waste of bandwidth, I guess that explain why they needed to extend vblank (it's even worst on the SNES version). Another funny thing in the code of the MD version, when you enter the option screen then exit it, the stack pointer is not restored to initial position (some parameters never got released probably) meaning that you can potentially get the game to crash if you try to enter/exit the option many many time :-p

[Drew Sebastino]

> Does this thread have anything at all to do with froyo?They replaced the Cuzzin's chains up here with this "#froyo" place that is absolutely terrible. Nothing but ridiculous, gimmicky flavors now like "strawberry cheesecake", "oreo cookies", "triple fudge cake", etc. If I wanted those dessert flavors, I would eat those things.Probably for the best that I eat less of it anyway. No fat, but I'm sure it was an obscene amount of sugar.

And costs an obscene amount money... I'd simply try the Splatoon froyo because it's Splatoon froyo, even though it looks terrible.

Man, too bad I don't live in Canada. I would have gotten my picture taken by this statue of an inkling with Thomas the Tank Engine's face superimposed on it.

So the proper factor when squashing from CPS to SNES is 135/176/(8/7), which is very close to two-thirds, and for CPS to Genesis it's 135/176/(32/35), which is close to five-sixths.

I did 2/3 and 5/6. It's convenient the vertical resolution is exactly the same.

What annoys me the most about Street Fighter 2 is the huge-ass bars on top and bottom of the screen. There's just not enough stuff on-screen for SF2 to need extrea v-blank.

Exactly. They could easily double buffer to fit everything in the available vblank. I think they take something like 16 pixels off the top and the bottom.

Edit: I know why. They recycled code from Final Fight.

I'm somehow not surprised, although this is a new low for Capcom... For such an anticipated game, you would have though/hoped they would have put more time into it. Has the sourcecode for the original CPS1 SF2 ever been released?

Because it has even less to do with "SNES Tilemap Editor", the topic from which it was split.

I think most of my threads turn into "anything goes". (And I'm usually the one that makes it that way...) I don't mind though.

On Megadrive using that trick is not much of interest, it requires a lot of memory (you can only fill half of the screen with genesis ram) and it consumes many CPU time as it requires continuous DMA during the active bitmap display... Indeed it would have been much more interesting with the SegaCD where the sub CPU could prepare rendering in a part of of the word ram while the second part is being transfered by DMA to CRam.

I wonder if the reason it was never done on the Sega CD is how much memory it would use, even for a CD. You know, how are color entries stored in C(G)RAM? (It's kind of odd there isn't a standard as to what to call these types of things...) I'd imagine it's like 64 bytes for 64 colors, plus 8 more bytes for the 9th bit, kind of like high oam on the SNES for 72 bytes total. The most convenient way I can think of to store this giant bitmap would be to have every pixel by 2 bytes, but that would be unnecessarily large.

A lot of the SNES features appears to exist just to exhibit bigger numbers, and honestly back in time that worked :-p
We didn't known the constraints applying to these numbers...

I think we know they forgot a pretty important number for marketing...

Honestly there is weird things in the code of this game. For instance it can transfer data at same location in VRam twice during a single frame, a real waste of bandwidth, I guess that explain why they needed to extend vblank (it's even worst on the SNES version). Another funny thing in the code of the MD version, when you enter the option screen then exit it, the stack pointer is not restored to initial position (some parameters never released probably) meaning that if you can potentially get the game to crash if you try to enter/exit the option many many time :-p

Expert programing. (I think you've already heard psychopathicteen's views on Capcom in that regard...)

[psycopathicteen]

Edit: I know why. They recycled code from Final Fight.

I'm somehow not surprised, although this is a new low for Capcom... For such an anticipated game, you would have though/hoped they would have put more time into it. Has the sourcecode for the original CPS1 SF2 ever been released?

I was just making an educated guess, since Final Fight has the same bars.

[Stef]

I wonder if the reason it was never done on the Sega CD is how much memory it would use, even for a CD. You know, how are color entries stored in C(G)RAM? (It's kind of odd there isn't a standard as to what to call these types of things...) I'd imagine it's like 64 bytes for 64 colors, plus 8 more bytes for the 9th bit, kind of like high oam on the SNES for 72 bytes total. The most convenient way I can think of to store this giant bitmap would be to have every pixel by 2 bytes, but that would be unnecessarily large.

Oh yeah of course it would have consumed a lot of memory but they could (and have to) compress it somehow.
The 9bits color is encoded in a word (16 bits) : 0000 BBB0 GGG0 RRR0
Very straightforward to work with and generate bitmap rendering, not so well in term of raw size (2 bytes per pixel).

Expert programing. (I think you've already heard psychopathicteen's views on Capcom in that regard...)

Actually I can understand the code is not the best one, they had time and money constraints and I will say at soon the game is good enough we can accept it. They probably spotted the option screen memory leak but just didn't care about it as nobody will ever notice it... Honestly I think the SNES version is definitely not bad, even not bad at all. The MD version is OK (it could have redrawed graphics for the higher resolution but costly definitely) and the palette work is not that bad... But the voices, just not acceptable !

[Drew Sebastino]

The 9bits color is encoded in a word (16 bits) : 0000 BBB0 GGG0 RRR0

I thought the main reason they had 9 bit instead of 15 or 16 bit color is that it would have taken up almost twice the space in cram. Well, apparently not.

the palette work is not that bad...

I was honestly impressed too for what they had in that regard. Is it like both fighters have their own palette, and the BGs and the status bar have the remaining two?

But the voices, just not acceptable !

It's unfortunate that examples like this have led people to believe that the Genesis has very poor sound hardware when it's really just lazy programing. You may disagree with me, but I feel the same way about the SNES and games like Gradius 3 and Super R-Type that come to a crawl when there are 4+ objects onscreen. R-Type 3 makes up for it though, even though there is still a little bit of slowdown. It only really when the stage spins in level 1 (I'm assuming it's some sort of fancy collision detection?) and on some parts in the second run where there are 16+ enemies with 32+ projectiles. (It's actually wanted here).

Regarding the giant black bars on the top and bottom of the screen, I arranged the picture I posted into 18 sprites (I could have done it in a third as much and used about 4 more tiles, but there's only ever two characters anyway) and 45 tiles, less than a third of the DMA bandwidth.

SF2 Sprite Tiles.png (4.51 KiB) Viewed 2435 times

[93143]

18 sprites and 45 tiles, less than a quarter of the DMA bandwidth.

Fixed that for you.

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?

[Stef]

I thought the main reason they had 9 bit instead of 15 or 16 bit color is that it would have taken up almost twice the space in cram. Well, apparently not.

The CRAM is internal to the VPD die and as it's static RAM it requires lot of space. Even if the information is "presented" in word format it looks like internally only the 9 meaningful bits are really stored, when you read the CRAM useless bits are usually set to random values.

I was honestly impressed too for what they had in that regard. Is it like both fighters have their own palette, and the BGs and the status bar have the remaining two?

Exactly, which is the reason why definitely 4 palettes is really limiting ! Only 2 palettes availables for the background and status bar :-/

but I feel the same way about the SNES and games like Gradius 3 and Super R-Type that come to a crawl when there are 4+ objects onscreen. R-Type 3 makes up for it though, even though there is still a little bit of slowdown. It only really when the stage spins in level 1 (I'm assuming it's some sort of fancy collision detection?) and on some parts in the second run where there are 16+ enemies with 32+ projectiles. (It's actually wanted here).

These games could have been better coded but remember they are first generation games and honestly the SNES sprites "features" (understand constraints) coupled to the "slow CPU" probably made it hard to sort quickly (to get things released in time).
If you look at SNES Konami games you can see they really improved with time... still even on their last released Parodius game you experience important slowdowns when many stuffs happens on the screen. In this case you cannot do really much about it, you can always optimize your code more but that's true for any systems, at the end you still cannot animate as much sprites with the SNES CPU than with the MD one and that counts for shump type games.

Regarding the giant black bars on the top and bottom of the screen, I arranged the picture I posted into 18 sprites (I could have done it in a third as much and used about 4 more tiles, but there's only ever two characters anyway) and 45 tiles, less than a third of the DMA bandwidth.

Definitely we are far from the bandwidth limit, even for zangief or honda character. But you cannot use the whole bandwidth for sprites, you have to consider you need a bit of the VBlank for the SAT update, BG animations (tilemap udpate) and stuff like that. But still they could have done a lot better overall (even better on the MD with the H40 mode).

[Stef]

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...

[psycopathicteen]

For some reason the earlier Konami SNES games are better known than their later games.

Some strange observation I've made is the more obscure an SNES game is, the less likely it is to have slowdown.

[mikejmoffitt]

I thought the main reason they had 9 bit instead of 15 or 16 bit color is that it would have taken up almost twice the space in cram. Well, apparently not.

The CRAM is internal to the VPD die and as it's static RAM it requires lot of space. Even if the information is "presented" in word format it looks like internally only the 9 meaningful bits are really stored, when you read the CRAM useless bits are usually set to random values.

I theorize that VDP was supposed to operate on 4 bits per channel, like much arcade hardware at the time, and the decision to give it 3-bit color was last minute. I think this because it's weird that the LSB of each color nybble is disregarded.

Right now we have

xxxx bbbx gggx rrrx

If 9-bit color was planned, you would expect this more sane configuration:

xxxx xbbb xggg xrrr

So, I think that was a last minute snip from

xxxx bbbb gggg rrrr

[Stef]

Yeah they considered it... too bad they came with 9 bits RGB finally...
I think it would have been far better to have 12 bits RGB with 4+4 palettes instead of highlight / shadow effect and interlace mode for instance... They really under estimated impact of these choices. Anyway, past is past

[mikejmoffitt]

The past is the past indeed.

I have been hard at work on a neat Megadrive port using SGDK... stay tuned

[Stef]

that sounds intriguing and interesting at same time =)