Scrolling?

JeffPack

New member
Hello,

There was a brilliant answer given somewhere in regards to 8 directional scrolling that makes perfect sense, but will there be 2 directional scrolling support added at some point? I know that this stuff could be pulled off with advanced techniques I was just wondering if there was going to be "native" support for it, and by native I guess I mean as part of a module? Maybe even with an option for vertical or horizontal? The platformer my brother and I are trying to create could really benefit from it.

Cheers
 

850

New member
I'm surprised it wasn't included in this module, or at least mentioned in the tutorial. But I assume scrolling was what he was referring to at the beginning disclaimer, without actually saying it.
 

Bucket Mouse

Active member
There have been scrolling routines buried within NESMaker since Build 3.1.4 in May. I'm shocked it wasn't ready for this release, because Horizontal Shooter is next, and there's no way they can implement that module at ALL without functional scrolling. It would've made sense to get it working in Platform so it would be ready for Shooter, but I guess they really needed that extra week.
 
Bucket Mouse said:
There have been scrolling routines buried within NESMaker since Build 3.1.4 in May. I'm shocked it wasn't ready for this release, because Horizontal Shooter is next, and there's no way they can implement that module at ALL without functional scrolling. It would've made sense to get it working in Platform so it would be ready for Shooter, but I guess they really needed that extra week.

Yeah, I feel like things are moving a bit too fast. I would rather have each module a bit late than have them going head over heels just to get us a module each WedNESday. I'm afraid they are going to burn themselves.
 

RadJunk

Administrator
Staff member
Scrolling is entirely possible with NESmaker.

Right now, there are so many particulars to the sort of scrolling you'd want with a platform game, you'd have to be neck deep in ASM, and we haven't found a great way to put in WYSIWYG form. In short, you guys aren't ready to run yet...you're still learning to crawl...not ready to run yet. If you ARE ready to run, then you could perfectly figure out how to manipulate what's there to make scrolling work... :)
 

RadJunk

Administrator
Staff member
The goal with these wedNESday tutorials is to get every dipping their toes in, seeing the breadth of what can be done, and learning the interface. If anyone is trying to create their opus at this point, they're doing it wrong. But I haven't been mysterious about that, I've been pretty overt about it. :)
 

WolfMerrik

New member
Let's look at this and break it down, together we can all do this.
Assuming we are making the most basic horizontal scrolling.

We can change the scroll with xScroll (that doesn't do much aside from moving the BG around, but it is fun to mess around with, add an INC xScroll to the move right)
This also moves the HUD, so next, we need to edit the HUD rendering to be offset by the same amount as the xScroll.
We also have to accommodate for collisions based on this, since we aren't actually moving all of the objects over, so we need to adjust this value when we detect our collisions as well.
We also need to load the next map segment (the one to the right would make sense)
Lets just for simplicity do one-way scrolling, like kid niki
So we would want to load this next nametable, (to $2400 I think)
We also need to look at how the sprites are drawn and offset their positions and values (I think) to accommodate for this scroll value.

What else?
 

softerimage

New member
TheNew8bitHeroes said:
The goal with these wedNESday tutorials is to get every dipping their toes in, seeing the breadth of what can be done, and learning the interface. If anyone is trying to create their opus at this point, they're doing it wrong. But I haven't been mysterious about that, I've been pretty overt about it. :)

I'm just glad you're finally acknowledging we will get scrolling. I have to admit I've been put off for the longest time because every time someone brings it up, the response usually sounds like it's not something planned for the tool to ever have. I certainly intend to go a bit deeper with the tool and also keep up with people's code they share, but scrolling has been talked about as if it won't be an implemented feature which honestly puts me off since how many games did people play that don't have scrolling?

I'm not trying to sound mad, btw. I'm actually pretty excited. :lol: Next step is being able to have bosses that use BG tiles (and move), which as I understand it is another huge hurdle.

BTW, would anyone be able to exactly go into detail about what different scrolling types there are and exactly what "compromises" there are for each? I don't understand exactly what has to be sacrificed, especially when so many great games have scrolling and I don't notice anything that makes them seem below games that lack scrolling, and thus don't have to make said compromises. Seems like the exact opposite, actually.
 

CutterCross

Active member
I'm hoping we can get vertical scrolling as a feature as well as horizontal scrolling. To be fair, horizontal scrolling is more ubiquitous and has a lot more uses than vertical scrolling, but I'd personally like to see vertical scrolling as it would help with my own projects.
 
CutterCross said:
I'm hoping we can get vertical scrolling as a feature as well as horizontal scrolling. To be fair, horizontal scrolling is more ubiquitous and has a lot more uses than vertical scrolling, but I'd personally like to see vertical scrolling as it would help with my own projects.

that's what I'm hoping for too - why not both in the same script in case you have a platformer game that needs vertical scrolling if it's not needed then split it so it can talk to the screens you have and boom as one map
 

CutterCross

Active member
Scythe&GenGames said:
that's what I'm hoping for too - why not both in the same script in case you have a platformer game that needs vertical scrolling if it's not needed then split it so it can talk to the screens you have and boom as one map
From what I've read, Mapper30 can't switch between Vertical and Horizontal mirroring on the fly like Metroid or MegaMan do. It's either permanently Vertical mirroring, or permenantly Horizontal mirroring, so having both Horizontal and Vertical scrolling would be VERY complicated, and not be as optimized as well as other mappers that can switch mirroring types on the fly.
 

Kasumi

New member
First off, this requires understanding of 16bit math.

You'd add how far to scroll to the low and high byte of the scroll variable.

You'd load the new column data and write it to a buffer. (That's the hardest part. Figuring out where and how NES Maker stores its screens and what format its buffer requires. Or adding a buffer if it doesn't have one sufficient for the task.)
This includes collision info because objects that are near the border between screens need access to both screen's data.
Update the general background collision subroutines to safely access this data. (Possibly not even required, it depends how all the buffers are set up.)

You write a 0 to $2005 twice in your NMI, then clear the lowest two bits of $2000. (To keep the HUD from moving).

You wait a specific amount of time (perhaps with sprite 0), and then fix the scroll for the rest of the level. This isn't too bad for horizontal only scrolling. I believe you just need to write the low byte of your 16bit scrolling variable to $2005, then use the lowest bit of the high scroll byte for the lowest bits of $2000. (Tweaking the timing may help it look slightly less glitchy, but you can also do it on the last black line of the HUD and there will be no visual errors if I'm understanding the wiki correctly.)

Change all sprite position's to 16bit (if this was not already done in preparation for scrolling being added.)
An object's final on screen position is just its position minus the scroll.

Fix sprite/sprite collision detection to work with the new 16bit positions. I recommend this algorithm: http://atariage.com/forums/topic/71120-6502-killer-hacks/page__st__50#entry1054049
To extend it to 16 bits, just add a high byte operation to each step.

Edit2: Oh yeah.
Add code to properly destroy things when they go off screen.

Add code to properly spawn things when they're scrolled on screen.

Add code that avoids spawning multiple copies of the same object. (If you're into preventing that.)

CutterCross said:
having both Horizontal and Vertical scrolling would be VERY complicated, and not be as optimized as well as other mappers that can switch mirroring types on the fly.
It's only really harder if you do both at the same time (like in the same frame, not just in the same game). The thing that makes "8-way" scrolling hard is the nametables (individual screens that map up the internal map) not being aligned. Metroid's mapper does allow mirroring to be switched, but it doesn't make anything too much easier than if it couldn't. What it does do is allow easier hiding of "color glitches" that you can usually see at the edges of one axis of scrolling in games.

Samus goes through a door and the scrolling direction switches, but since the width and height of each room is the same as the screen the nametables are always aligned.

Vertical scrolling is a bit harder if one has a background HUD, though. (Even if you only do vertical scrolling.) Changing the hardware vertical scroll position mid screen requires way more math and understanding of the hardware than just writing to $2005.

You also have to track things a bit differently because the screen is 240 pixels tall rather than 256. My own data is stored in 256x256 "screens" rather than 256x240 screens so that this affects much less in the engine.

Edit:
TheNew8bitHeroes said:
If you ARE ready to run, then you could perfectly figure out how to manipulate what's there to make scrolling work... :)
I disagree with the spirit of this statement. If it's not supported by the tool, you would not be manipulating what's there, so much as writing the entire thing by yourself in a way that no longer makes the actual tool helpful. It's similar to adding DPCM. Even if I know how, adding it makes the music import part of the tool stop being useful, which is relied on for setting which music plays in the first place on the screens. As well, (and my main issue) is that future updates will always break it. Once I make a large change, when the next asm pack comes I have to make the changes again and again. Users can add small things, but you kind of have to add this big stuff officially or the tool gets in the way of progress rather than helping it.
softerimage said:
BTW, would anyone be able to exactly go into detail about what different scrolling types there are and exactly what "compromises" there are for each?
Sure. If you scroll one way like Super Mario Bros. you get access to LOTS of destructibility. In the underground levels you can destroy absolutely every block and the CPU doesn't really have to "remember" what you did once it goes offscreen because you can't go back. If you could go back, you'd need more RAM (or be okay with the CPU "forgetting" what you did there). It also lets you compress the levels in a way that doesn't require "random" access which can make data smaller.

Most games are not as destructible as Super Mario Bros. and its one way scrolling is why.

If you scroll in two directions, like Metroid, you lose out on some of that extreme destructibility. (Or you have to add RAM to get it, which Metroid does.) You also lose out on certain ways to store levels since you have to be able to access level data at an arbitrary place. Beyond that it's not really different from Super Mario Bros.

If you scroll in all directions, your level format may get larger. You can no longer easily avoid color issues on at least one border of the screen. Even then it's not terribly different from two directions, it's just much harder to get working without issue. (Leaving half updated tiles in the middle of the screen and things like that.) One difference is that it makes accessing collision data a little slower (usually), because the point can be on any one of four screen rather than just any one of two. This means every point that every object checks takes more time to access, which means you have to be more careful about optimization throughout.

Shorter:
If you want EXTREME destructibility you want 1 way scrolling. (Or extra RAM.)
If you want scrolling, but don't want to spend a month or two getting it working, you want 2 way scrolling. It also lets you be a little lazy about optimization.
8 way scrolling will keep you on your toes throughout the entire project, and just getting it working (not entirely bug free) in the first place is a hassle.

Edit: Scrolling vertically with a background HUD is harder than scrolling horizontally with a background HUD. Scrolling vertically is a little harder in general. Checking when things goes above 255 (the width of the screen minus one) is a feature of the CPU. Checking when things go above 239 (the height of the screen minus one) is not. It sounds simple, but that has further reaching consequences than it seems when you get down to it.
 

fearspork

New member
yeah agreed super disappointing there's no side scrolling , even in one direction. i'm sure i could spend then next few days scrolling through the user made stuff or figure out the asm but i dont have time for that, one direction side scrolling is day one mario bros packed with the system , its one of the most basic parts of a platformer
 

Mihoshi20

Member
CutterCross said:
Scythe&GenGames said:
that's what I'm hoping for too - why not both in the same script in case you have a platformer game that needs vertical scrolling if it's not needed then split it so it can talk to the screens you have and boom as one map
From what I've read, Mapper30 can't switch between Vertical and Horizontal mirroring on the fly like Metroid or MegaMan do. It's either permanently Vertical mirroring, or permenantly Horizontal mirroring, so having both Horizontal and Vertical scrolling would be VERY complicated, and not be as optimized as well as other mappers that can switch mirroring types on the fly.

MegaMan 1 is UNROM/Mapper 02 so it essentially has the same capabilities as UNROM-512/Mapper 30. If you play MegaMan 1 or watch a playthrough of it you'll notice when the character is moving from left to right it's smooth scrolling but when moving up or down it's screen to screen like how the engine works right now. It was the only MegaMan game to use UNROM though as the other installments in the series used other cart PCBs/mappers.

Castlevania 1 which is also UNROM tends to avoid moving vertically at all costs, opting to do screen freshes on stairs to make the change when it does, but at one point it has a full vertical drop or at least the illusion of it at one point in the game though I suspect trickery was involved as it's used once and only once.
 
Top Bottom