Multidirectional scrolling

[tepples]

And instead of talking about mappers we should focus on making simpler game with less hardware

And "lose [your] interest right away", as you put it

so we can have some code base to work on more ambitious projects. I guess that was people in the past did indirectly anyway.

And that's what I continue to do, despite strong suggestions from someone to make something that scrolls already.

[tokumaru]

And that's what I continue to do, despite strong suggestions from someone to make something that scrolls already.

That would be me, right? =)

[qbradq]

I found scrolling to be needed for the project I want to do, unfortunately.

[tokumaru]

Scrolling is easier than most people think, specially if it's just in one axis. Horizontal scrolling is particularly easy, due to the fact that nametables are 256 pixels wide.

[Bregalad]

Yeah scrolling one direction at a time is easy but scrolling both at the same time (free-directional scrolling) is a nightmare, I got weird bugs every time I tried to do that because the update logic for one axis would interfere with the logic of the other axis.

[tepples]

Scrolling is easier than most people think

Efficiently organizing data for scrolling, on the other hand, isn't necessarily trivial. Nor is creating several km worth of map data to be scrolled over.

[Banshaku]

And "lose [your] interest right away", as you put it

Making a game with less complicated hardware doesn't mean that it's a single screen game. And with a mmc1 like from retrousb you could make something similar to Ninja Gaiden.

I don't know how you got back that post and what was the purpose in the first place to digg it up. It doesn't bring much to what I said about "let focus on games instead of making a new mapper".

[tokumaru]

Yeah scrolling one direction at a time is easy but scrolling both at the same time (free-directional scrolling) is a nightmare, I got weird bugs every time I tried to do that because the update logic for one axis would interfere with the logic of the other axis.

I'm sure you would eventually get it right if you hadn't given up. I too have found weird bugs while trying to implement free scrolling, but once I stopped and planned everything beforehand I only needed minor tweaks to get it working.

Efficiently organizing data for scrolling, on the other hand, isn't necessarily trivial. Nor is creating several km worth of map data to be scrolled over.

Even simple puzzle games can benefit from rooms slightly larger than a single screen... No being able to see everything that's going on might even add to the fun. Not all levels must be several kilometers long.

[Dwedit]

I've gotten free scrolling to work fine. Should I write a tutorial?

[3gengames]

I think free scrolling isn't that hard. I think it's combining it with compression (the "efficiently organizing" that tepples talks about) that's difficult, at least I feel like it would be.

[thefox]

I think free scrolling isn't that hard. I think it's combining it with compression (the "efficiently organizing" that tepples talks about) that's difficult, at least I feel like it would be.

So you probably haven't written an 8-way scroller yourself, have you? It IS hard, there are so many chances to be "off by one" that you really have to be very careful when designing how you're going to go about it. I'm of course talking about "real" limitless scrolling with variable scrolling speeds, not the SMB3 way (vertical scroll is limited to 2 screen heights, it only needs to update columns) or the Gauntlet way (4-screen mirroring, screen limited to 512x480).

That said, if you are systematic about it's not too bad. But it is hard in my book as far as NESDev goes.

[3gengames]

I haven't, but I've been thinking about it. [And sadly, came to the conclusion I'd probably just do it the SMB3 way to save the headach.] but I think I should rephrase. Doing it with compression and not using a ton of RAM would be hard. And to add to it, I also was thinking of a way to also update a 60 byte table to also keep track of walkable spaces. That seemed easy, but yet it uses 60 bytes of RAM. I'm not sure if anyone else has better methods, but with low CPU costs. Does anyone use a RAM table for collision on the background so you don't have to read the PPU?

[tokumaru]

Doing it with compression and not using a ton of RAM would be hard.

Map decompression and nametable updates should, in theory, be 2 different systems. Anyway, if you use fixed-size compression (i.e. not RLE, LZ and the like), decoding it in real time isn't so hard.

I'm not sure if anyone else has better methods, but with low CPU costs. Does anyone use a RAM table for collision on the background so you don't have to read the PPU?

I doubt anyone reads the PPU for collision. If they do, they certainly shouldn't. VBlank time is already too short if you're only writing to VRAM, imagine if you also had to read it in order to make game decisions...

I'm not sure if RAM tables are the best option either, because they wouldn't work well with slopes and blocks more complex than solid/empty unless they used much more than 60 bytes of RAM.

For collision decisions I just read directly from the level map. Once I have a metatile's index I have access to all of its collision information.

Now I really really think it's time for a split!

[Bregalad]

What always bugged me is that the vertical scroll and horizontal scroll routines would work fine on their own, but they would randomly interfere eachother when working at the same time.

Doing 4-way scrolling like Final Fantasy or Dragon Warrior is easy for example, as the horizontal scrolling can assume the vertical scrolling is at an integer number of metatile and vice-versa.

When you want true free-directional scrolling, the problem is that if the scrolling of the "other direction" (that is, vertical axis for the horizontal scrolling routine and vice-versa) might not be an integer number of metatiles so you don't know how you are supposed to do your updates, because it depends on what the "other" routine is doing at the moment. (I hope my english wording of the problem makes sense).

I've tried this with both metatile based maps, and maps directly stored as spearate NES screens (raw name and attribute tables) and I encountered a similar problem on both attemps.

I'm pretty sure there is a fix available but it would probably mean use a more complex algorithm where there is a signle routine doing the scroll into all directions instead of two horizontal and vertical scrolling routines called one after eachother.

There is no reason to implement compression first, you need to make it work with uncompressed maps, then adding comperssion is as simple as replace all data load from map (which should be something like a lda [Map],Y) by a subroutine that will load data from the compressed map (for this reason it's important that the compession data is randomly acessible, pseudo-randomly acessible, or that the map is entierely decompressed in RAM).

I finally lost interest in this when I figured that all NES project I'll do in the near future would anyways scroll only one direction at a time.

[clueless]

I've gotten free scrolling to work fine. Should I write a tutorial?

Yes please.