Enjoying your froyo?

[psycopathicteen]

The SNES hardware is just so unbalanced and painful to develop with where the Megadrive is straightforward and cleverly designed, that is the point.

I can't actually disagree with you there. :/

I wonder if it was possible back then to have VRAM accessed a little bit faster than the pixel clock, like having it access 10 words per 8 pixels. It seems like most of the complexity came from trying to shove as many bg layers into the sPPU VRAM bandwidth as possible.

[Near]

> More than once, this is where our opinions differ. I'd rather write in machine code than C, and I'd rather have a better PPU than a better CPU.

And you are in the minority. The Genesis had a thriving unlicensed development scene. Complete games that could have easily been real official titles, not small homebrew games. Tons of great Chinese games like Fengshen Yingjiechuan and Beggar Prince. And of course, the venerable Pier Solar. Meanwhile, the SNES' most impressive unlicensed game is d4s' Super Road Blaster port. Aside from digging up games that were intended to be licensed (eg the shamefully bad Nightmare Busters) or Christian ROM hacks / loli porn rape dungeon games, the SNES hasn't seen a single, real full, substantial unlicensed game yet. And I'll probably finish FEoEZ before Project N comes out :P

> Why dick around with Final Fantasy 6 vs. Chrono Trigger when you could be playing Final Fantasy 3,000?

I already covered this. You play RPGs for their story.

And certainly, I will play "Zelda: Link's Awakening" and "Castlevania: The Adventure" when I'm out of other titles to play (and they are indeed worth playing through once); but "Zelda 3: Triforce of the Gods" and "Castlevania: Rondo of Blood" are clearly the superior, more enjoyable games.

Shmups though are a different class of game. They're more akin to pinball machines: you play the same game over, and over, and over. I've literally played through Dodonpachi at least 50-100 times. I would probably put fighting games in this same category. Whereas I have played through Chrono Trigger and Final Fantasy VI exactly once. And Zelda 3 probably four times.

So the better analogy would be, why play this: http://1stadvantagesolutions.com/32440.jpg
When you can play this? http://www.pinballpast.com/shop/files/t ... pfield.JPG

> just a bunch of slow bullets that seem to disappear for whatever reason

He's spamming bombs. But it takes forever because that boss becomes invincible while your bomb is in effect. It's basically the game's last ditch effort to steal quarters from even the most extreme players. I only showed that part to emphasize the fun of shmups not limited by a max of 64 sprites onscreen, or 20 on the same line.

The reason I like this game so much is because the bullets move at a speed that human beings can dodge them. There's certainly not a technical reason they can't move ten times faster like a Touhou game.

> I'd much rather stick to the "outdated" R-Type.

Again, suit yourself.

You seem to be arguing like I've been stating objective facts. They're just my opinions. You're welcome to share yours too, of course, but no need to be a contrarian just because I responded to someone else with mine.

[Drew Sebastino]

You seem to be arguing like I've been stating objective facts.

The "shoot em ups become outdated because you only play them for graphics" seemed kind of like you where trying to state objective facts. :/

[tepples]

(why in the world would you even choose 256 pixel mode then?)

To save VRAM, or to draw the same graphics and use them for both Super NES and Genesis versions of a game.

I think I remember that sprite information is stored in vram and that it's actually safe to update it mid screen.

Yes. Video on the Genesis VDP is most similar to S-PPU mode 2, with offset per 2 columns in the same way mode 2 has offset per tile. On the Genesis, the sprite table is inside VRAM and OPT data is in a separate VSRAM, but in S-PPU mode 2, OPT data is inside VRAM (at a position controlled by BG3's nametable base register) and the sprite table is in a separate OAM. Either way, the fetch pattern of the Genesis VDP leaves some time available for VRAM data access during active picture, which makes real-time decompression more practical as tile data can be sent directly to the VDP instead of being buffered for a vblank DMA.

Has I think about around a 4Mhz Z80 for sound and the Master System?

3.6 MHz. But the Z80 is about half as efficient clock for clock as the 6502, so it's about as fast as the NES CPU.

Has one PCM channel for sound.

Plus 5 FM channels and the 4 Master System channels. In addition, specialized Z80 code can mix multiple samples into this mono PCM channel.

Some have a bios that loads up "licensed by Sega" or something, but I think Sega ended up getting in trouble with Accolade?

The VDP is locked until the BIOS is switched in, which is done by writing the string "SEGA" to an I/O port. The BIOS looks for "SEGA" or " SEGA" at a particular place in the ROM header, and if found, it displays the license screen for a few seconds and jumps back to the cartridge.

Accolade inserted the code to call the BIOS. Sega sued, claiming that the license screen display in an unlicensed game infringed Sega's trademark. The judge ruled in Accolade's favor, holding that Sega itself was misusing its trademark as an ersatz patent.

The boot sequence in the Game Boy, Game Boy Color, and Game Boy Advance works almost identically, except its BIOS is switched in on power-up, and the magic string in the ROM header is a bitmap of the name "Nintendo".

flexible sound hardware.

Isn't the sound hardware on the Genesis less flexible? I recall hearing a story about how in Mortal Kombat III on the Genesis, samples had to be played at half quality to try to have multiple sound effects going on, which is often the case for fighting games.

Audio mixing required more CPU time, and you're probably right that professional programmers on a deadline didn't have time to optimize the soft mixer to demoscene levels of efficiency.

Can someone provide a sharp scan of the "yogurtys.com" text on a Yogurty's cup? I'd like to see what font it uses, and the cups in the photo for the Splatoon ad campaign aren't sharp enough for WhatTheFont/WhatFontIs.

That would be cool. I just noticed that I sort of made a bad pun... Should I instead say that would be "fresh"?

I ask because the font sort of reminds me of Fink Heavy, the font used for the logo of Animal Crossing and a bunch of other things, but it isn't exact.

[Drew Sebastino]

(why in the world would you even choose 256 pixel mode then?)

To save VRAM, or to draw the same graphics and use them for both Super NES and Genesis versions of a game.

I'd still kind of like 80 sprites... I wouldn't mind 256 pixel mode if the sprite capabilities where kept intact. Isn't the way this is done by lowering the clockspeed of the video chip?

half as efficient clock for clock

I can think of another processor a little above "half as efficient clock for clock" compared to another CPU, but not going to say anything...

specialized Z80 code can mix multiple samples into this mono PCM channel.

Isn't that how the GBA does it, except it has two PCM channels, one for left, and one for right if you have headphones?

Audio mixing required more CPU time, and you're probably right that professional programmers on a deadline didn't have time to optimize the soft mixer to demoscene levels of efficiency.

So really, what I thought was a fairly clever idea was really just laziness... Can you think of any games that mix the audio together? I haven't payed attention enough to notice. (You know, how feasible would it be to mix audio together with the SPC700?)

[Stef]

I get the first part of what you said, but not "belong the Megadrive".

Oh sorry, my english sucks, i meant "towards", i don't know why i'm always confusing these 2 words :p

Not too much, and I never said that whatever reason he would say would be wrong. This is basically what I know:

Has a 256x224 screen mode, and a 320x224 screen mode.
In 256 pixel mode, there are 256 sprite pixels per line.
In 320 pixel mode, there are 320 sprite pixels per line.
In 256 pixel mode, there are 64 sprites.
In 320 pixel mode, there are 80 sprites.
...
Has several (I don't know the specific number) FM channels for sound.
Has 64KB of main ram.
Has 64KB of video ram (but was potentially going to have 128KB).

Definitely you already have a good view of the Megadrive hardware but i believe you really need to try some piece of development on this system to understand why we prefer it. Of course you don't have the time for that, myself i would love to develop on more system but lack of time for that
Also you said you don't care about C and prefer using assembly directly... Writing assembly for the 68000 is really pleasant, try it for sometime and then you will have hard time getting back to 65816 assembly, trust me.

About the Megadrive hardware, I don't know where you get the 384 colors entries (arcade board ?) but at least it would have been really easy to have 4+4 palettes (4 for sprites and 4 for BG) and also 12 bits RGB color (internally color data are encoded as 0000RRRxGGGxBBBx).

Isn't the sound hardware on the Genesis less flexible? I recall hearing a story about how in Mortal Kombat III on the Genesis, samples had to be played at half quality to try to have multiple sound effects going on, which is often the case for fighting games.

Well depending the "sound driver" you can really change the sound capabilities of the system.
The Megadrive sound system is composed of the Z80 CPU (3.57 Mhz), 8 KB of dedicated memory (owning the sound driver code and its data, variables), the YM2612 chip and the PSG chip.
What i like is that you have a full dedicated CPU to handle all the sound stuff and that CPU can access the main BUS (and so the ROM) which is a big difference from the SPC700 which need any data to be pushed from external.

It's true that by default the YM2612 offers you 6 FM channels or 5 FM + 1 PCM and the PSG offer 3 square channels + 1 noise channel. Also because they wanted to maintain backward compatibility with the Master System you don't have any interrupt connected to the YM2612 timers, which is a pity and make things a bit more complex...
But then everything is up to the developer skill.
You spoke about MK3, but just take SF2... The Megadrive version is "famous" for its poor voices quality, as MK3 they actually mix 2 PCM channels in software but that is really poorly done :-/
I made a patch for this game to fix the voice quality :
https://www.youtube.com/watch?v=-iE5GJNkOqs

I just replaced the dumb default sound driver and that is... It's just unbelievable they didn't put more effort on porting this game when you think how much its (negative ?) impact was important :-/

Also i developed my own sound driver for the Megadrive for easy music and SFX handling in game development.
You can find it in my SGDK toolkit, i called it XGM driver and it basically allows you to have 5 FM + 4 PCM (@14 Khz) + 4 PSG everything handled by the Z80 cpu only.
The samples played on the 4 PCM channels doesn't have any size limit.
It really extends the Megadrive sound capabilities and this only using the Z80 CPU (so the main 68000 remain 100% available for others parts). I bet it would be really difficult to achieve something similar with the SPC700 (extra software PCM channel) and the limited data access will remains whatever happen.

That was enough for me. The SNES may not have 512 colors, and the Turbo Graphics 16 may have only had 9bit color depth, but the Genesis got hit hard. I'll also take my 256 color and 16 color BGs at 256 pixels over 2 16 color BGs at 320 pixels, but that's just personal preference.

Well for me 4 palettes is definitely not enough, even if you can share it between sprite and BG. Only having 4+4 would have make a huge difference.

https://www.youtube.com/watch?v=zlulSyBI2aY

Do you know that "blast processing" term actually came from the fact that you can DMA to CRAM fast enough to create a pseudo 16 bits (9 bits used) bitmap mode ?

Phalanx

I... guess? Of course I'm going to agree with you about R-Type 3 though. Super R-Type would be better if it weren't in slowmo, but it's still a fairly mediocre attempt. I don't like Gradius, and I think Axelay is tremendously overrated, although I only did about 1 level.

I don't like Axelay neither, nor Super Aleste or Musha aleste :p
Phalanx is really underrated for me, it has its flaws (as the slowdowns) but very enjoyable at end and one of the rare SNES shump to display more than 10 sprites at once (exaggerating but that is the idea) :p

How is collumn scrolling "painful" on the SNES? You just upload the scroll values of each column to the second row in BG3's tilemap with bit-13 set.

I didn't get it either.

Well i never understood correctly the documentation then, i though you had to update the whole BG3 tilemap to do it.

[tepples]

specialized Z80 code can mix multiple samples into this mono PCM channel.

Isn't that how the GBA does it, except it has two PCM channels, one for left, and one for right if you have headphones?

Yes, but the GBA also has an ARM CPU, with lots of registers and fast multiplication, and a pair of DMA channels to feed its sample FIFOs so that mixed audio can be fed to the DAC in the background without needing the rest of the program to be timed code.

[KungFuFurby]

Also i developed my own sound driver for the Megadrive for easy music and SFX handling in game development.
You can find it in my SGDK toolkit, i called it XGM driver and it basically allows you to have 5 FM + 4 PCM (@14 Khz) + 4 PSG everything handled by the Z80 cpu only.
The samples played on the 4 PCM channels doesn't have any size limit.
It really extends the Megadrive sound capabilities and this only using the Z80 CPU (so the main 68000 remain 100% available for others parts). I bet it would be really difficult to achieve something similar with the SPC700 (extra software PCM channel) and the limited data access will remains whatever happen.

Well done! I'm taking note of that sound driver, because I personally want a different way to make music other than VGMMM and Deflemask. Both of them suffer from desyncing with PCM (although in your case, it looks like I have fixed sample rates only... ah well, that's OK for me, as I can easily do resampling)... and I'm interested in using Kega Fusion for both creating VGM files and rendering them.

I actually understand the difficulty with emulating extra PCM channels quite well... especially in the SPC700's case when you have to render it either to BRR (in real time) or use the echo buffer. Both are quite CPU-intensive... on either end.

[Stef]

Well done! I'm taking note of that sound driver, because I personally want a different way to make music other than VGMMM and Deflemask. Both of them suffer from desyncing with PCM (although in your case, it looks like I have fixed sample rates only... ah well, that's OK for me, as I can easily do resampling)... and I'm interested in using Kega Fusion for both creating VGM files and rendering them.

I actually understand the difficulty with emulating extra PCM channels quite well... especially in the SPC700's case when you have to render it either to BRR (in real time) or use the echo buffer. Both are quite CPU-intensive... on either end.

Thanks I do have a question, you said you don't want to use VGMMM nor DefleMask, is there any other usable solution ?
Also what about this PCM desyncing issue ? i never heard about it...
XGM uses frame based timing, the 4 PCM software mixing operation eats the major part of the CPU time (about 70%) and to maintain good playback level i had to cycle count the code so no way to handle sub frame accuracy timing level for XGM instruction inside that. With the PCM mixing and buffering i can obtain some PCM timing a bit off but the delay is rarely above the frame. For SFX that is another story... (you can't avoid the internal mixing buffer delay).

[tepples]

This looks like it's gone way off-topic. If someone can pinpoint the exact post where it ceased to be about "SNES Tilemap Editor", please PM me.

[Drew Sebastino]

Do you know that "blast processing" term actually came from the fact that you can DMA to CRAM fast enough to create a pseudo 16 bits (9 bits used) bitmap mode ?

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

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?

Yes, but the GBA also has an ARM CPU, with lots of registers and fast multiplication, and a pair of DMA channels to feed its sample FIFOs so that mixed audio can be fed to the DAC in the background without needing the rest of the program to be timed code.

But can't even load a number in one instruction... I'm never going to let that go.

I made a patch for this game to fix the voice quality :

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

It's just unbelievable they didn't put more effort on porting this game when you think how much its (negative ?) impact was important :-/

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)

Street Fighter 2 Sprites.png (5.13 KiB) Viewed 2717 times

Now here's everything in the 4x3 aspect ratio (the CPS1 has a crazy 12x7 aspect ratio (384x224) despite running on a 4x3 monitor)

I know the game has vertical black bars on the top and bottom of the screen, but I don't have a clue as to why. By double buffering, you can easily have 2 Zangiefs unless they where really trying not to have to double buffer anything even though it would fit in vram. I wouldn't be surprised if it where a cost effective decision because they'd need less rom to store the smaller graphics, even though the graphics in the original SF2 SNES weren't even compressed... I bet they just wanted to get it done in time and knew it would sell like hotcakes regardless.

[Drew Sebastino]

Hell, actually, this is how it could look on the Genesis if only the color depth was reduced to 9 bit:

Ryu after his weight loss program:

Street Fighter 2 Sprites.png (5.69 KiB) Viewed 2712 times

4x3 Aspect Ratio:

[tepples]

Street Fighter 2 Sprites.png

Now here's everything in the 4x3 aspect ratio (the CPS1 has a crazy 12x7 aspect ratio (384x224) despite running on a 4x3 monitor)

Display aspect ratios aren't quite as important as pixel aspect ratios, which can be derived from the dot clock rate. Oddball pixel aspect ratios were common in the second through fourth generation because of the way NTSC's 4:3 frame was defined in Rec. 601. Atari 2600 and Apple II color have a 12:7 PAR, where each pixel is one cycle of color burst wide. ColecoVision, MSX, NES, SMS, Genesis 256px, and Super NES have a 8:7 PAR. Genesis 320px is 32:35. Commodore 64 has a narrow 3:4 PAR, and that of the CPS 1 and 2 is 135:176 which is close to C64.

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 bet they just wanted to get it done in time and knew it would sell like hotcakes regardless.

And when they did put more time into it, the result was Special Champion Edition, the Genesis counterpart to Turbo.

[psycopathicteen]

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.

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

[rainwarrior]

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