Topic: @Uzo or any1 similar: How did vertical scrolling work in CV3?

[TheouAegis]

In DokiDoki Panic/Mario 2, the vertical scrolling involved moving the player across the screen and changing the backgrounds as it went (i think, from what I read accidentally just now on some site). I think it was the same mechanic used in Mega Man games.

But in Dracula's Curse, the vertical scrolling was smooth. When you look at vertical stages in ReVamp with the V-Scroll Mask enabled, the section of the stage with the mask (a latticework 16x256 pixels in size), the tiles covered up are not in the game when you play it. So if you took screenshots of the stage (like they do for SpritersResource) and tried to make TSA's from that, you'll have twice as many as you should because of that overlap.

I'm considering adding this mechanic into my CV engine, but I won't do it if I can't understand it. Here are pics of what I'm talking about if you can't be assed to download a CV3 ROM and ReVamp:

[uzo]

All I know is that Castlevania 3 used a special mapper chip to do what it does. Though honestly, I'm not sure why it needed that. There are plenty of games with horizontal and vertical smooth scrolling, like Star Tropics, Zelda 2, Crystalis, and so forth. Not really an NES expert on mappers.

For your game maker project, I don't see why you cant just do it normally?

[TheouAegis]

I'm trying to add TSA compatibility. That is, if someone wants to make 32x32 tiles ahead of time rather than placing 8x8 or 16x16 tiles in the room, they could just place their pre-mades instead. But in order to do that, they would either need twice as many TSAs (since the vertical room would shift half the tiles 16 pixels down) or my program would have to compensate for it somehow. And by the looks of it, the v-scroll mappers are at regular intervals in each stage, so ... um... If I got any more detailed, you'd think I'm nuts.

I guess I'll have to try to crack it myself or figure out some alternative. Thanks, Uzi.

[bucky]

All I know is that Castlevania 3 used a special mapper chip to do what it does. Though honestly, I'm not sure why it needed that. There are plenty of games with horizontal and vertical smooth scrolling, like Star Tropics, Zelda 2, Crystalis, and so forth. Not really an NES expert on mappers.

For your game maker project, I don't see why you cant just do it normally?

I'm not an expert on this either, but the reason they probably 'needed' the MMC5 is because it did a lot more than just the vertical scrolling. The same is true for other mappers, but the MMC5 was even more advanced and was probably utilized in other aspects of CV3. Here's what wikipedia says-

"The MMC5 was Nintendo's largest mapper. It was also the most expensive, making developers avoid it. Only Koei seemed to use this chip regularly in their games once it was released. The chip has 1 KB of extra RAM, extra sound channels (two square waves), supports vertical split screen scrolling, improved graphics capabilities (making 16,384 different tiles available per screen rather than only 256, and allowing each individual 8x8-pixel background tile to have its own color assignment instead of being restricted to one color set per 2x2 tile group), highly configurable program ROM and character ROM bank switching, and a scanline-based IRQ counter"

I'll see if I can get some feedback on this topic from a friend. Or you could try asking over at the NESdev forums.

[Inccubus]

My question is why try to emulate the stuff in the original that makes the process of stage construction a pain in the butt for the end user? GM already lets you select tiles in groups of any size so why bother emulating the god-awful TSA system Konami used? The only reason they used TSA is to save space on the cart and that isn't an issue with GM. Besides wouldn't it clash a bit with the system you created for generating the block objects? It seems like using a TSA system would be adding an extra step to stage building that is not necessary.