This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Just an Idea

Just an Idea
by on (#108201)
For the penultimate boss in my game, I didn't know if the idea I had would be possible because i don't know how well the NES can split up regions to scroll. I tried reading the wiki about scroll regions but I wasn't sure if I was clear on what it said.

For the first part of the boss, I simply want it to be two huge robotic legs that are comprised of background tiles (since it would be impossible to do with sprites) and they independently move up, to the side, and then down as the robot steps around. This would mean the screen's scrolling regions would have to be split up like an upside down T, the horizontal line for the ground and the vertical line of the T for a leg on each side. Then when the legs are destroyed, the body of the robot comes crashing down and you have to fight it after that, which I haven't thought out yet, but that's beside the point.

I should note my game isn't being made in an NES rom, I'm simply making a Windows game that I'm trying to keep the NES limitations on as much as possible.
Re: Just an Idea
by on (#108203)
If you sacrifice the background (i.e. make it just a solid color) you can make all kinds of huge objects out of background tiles. The main problem with this idea is that the robot has two legs, and the NES only has 1 background plane. You'd not be able to move each leg up, to the side and down independently from the other one.

Can you provide a mock-up image of what you have in mind? I can't really see how you came to the "upside down T" scrolling regions.
Re: Just an Idea
by on (#108204)
Here's a mockup image of what I meant. I need region 1 to stay put while regions 2 and 3 move around horizontally and vertically, independently of each other.
Re: Just an Idea
by on (#108206)
This is completely impossible, as Scrolling Region 2 and 3 are at the same location vertically.
You'd need the SNES to be able to do something like that.
Re: Just an Idea
by on (#108207)
Damn, well OK, glad I checked with you guys before I did it.
Re: Just an Idea
by on (#108208)
Note that if your scrolling regions 2 and 3 scrolls only vertically, you could so something similar to what's done in the Mega Man 2 intro to fake different scrolling regions.
However if you want them to be "completely independent", then no, it's not possible.
Re: Just an Idea
by on (#108209)
What if you didn't even use scrolling though?

Depending on how much detail and repetiveness was in the legs/feet seems like something the MMC2/4 could handle fairly well.
Re: Just an Idea
by on (#108211)
infiniteneslives wrote:
What if you didn't even use scrolling though?

Depending on how much detail and repetiveness was in the legs/feet seems like something the MMC2/4 could handle fairly well.


Do it the NeoGeo way! Lots and lots of of Memory for graphics! You can do anything then.
Re: Just an Idea
by on (#108213)
infiniteneslives wrote:
What if you didn't even use scrolling though?

Depending on how much detail and repetiveness was in the legs/feet seems like something the MMC2/4 could handle fairly well.


How would it be pulled off without scrolling? Moving it tile by tile?
Re: Just an Idea
by on (#108214)
Two independently moving legs this large would be pretty hard to pull off. The NES doesn't have any means of splitting the screen horizontally, and although mappers could do it (the MMC5 does it to some extent), none of the existing ones can do something like this.

IMO, the best option would be to not use the scroll at all, and just redraw the legs every time they move. With a highly optimized drawing routine you could draw one of the legs in a single VBlank. The downside, which is relevant to your game, is that the precision of the movements would be restricted to 8 pixels (or 16, if you have different palettes in the same leg). Also, since there's only time to update one of them in a single VBlank you wouldn't be able to move both at the same time, but I guess that's OK.

If the body is a single piece, once the legs are destroyed you can use a split to animate its fall with full pixel precision, it can accelerate and even bounce once it hits the floor.
Re: Just an Idea
by on (#108215)
Yeah the legs are only supposed to move one at a time and I think it'd be perfectly acceptable if they move 8 pixels at a time if the movement is done quickly enough so it doesn't look jerky to the player.
Re: Just an Idea
by on (#108222)
tokumaru wrote:
The downside, which is relevant to your game, is that the precision of the movements would be restricted to 8 pixels (or 16, if you have different palettes in the same leg). Also, since there's only time to update one of them in a single VBlank you wouldn't be able to move both at the same time, but I guess that's OK.


Why artificially limit the mapper and CHR data available? Imagine a MMC2/4 with 1KB background banks and unlimited CHR. As long as you could fit each leg/foot in 1KB while still you could shift that and have 16 different version of the same tile assuming you had more than 32 banks to play with. You could move the leg 2 pixels in any direction including diagonally with a single bankswitch. You'd only have to redraw a handful of tiles whenever you crossed a tile boundary. You could use the other two banks for other items one for still objects and the other for bankswitched animated objects. Even a left to right scrolling floor if you wanted.
Re: Just an Idea
by on (#108224)
corlenbelspar wrote:
Yeah the legs are only supposed to move one at a time

By "one at a time" I meant that they can't both move in the same FRAME... it would still be possible to update them in alternating frames and make it look like both are moving. This is why I said this limitation wasn't a big deal.

infiniteneslives wrote:
Why artificially limit the mapper and CHR data available?

Because he's trying to make this look authentic.

Quote:
As long as you could fit each leg/foot in 1KB

Have you seen the size of those legs?! 1KB is just 64 tiles, a small 8x8 tile area. Tile repetition gets very tricky with animated patterns, because the wrong tiles can bleed into each other, so in order to move the leg only with bankswitching you'd need unique tiles for many of the parts that look the same. The tile variations for all the possible vertical and horizontal positions would amount to a lot of tiles: for pixel-perfect precision you'd need 64 variations of each tile. Even if you can magically fit each leg into 1KB, that's 128KB of CHR just for them. Also, after 8 pixels moved in any direction, you'd have to redraw the whole thing, not just a handful of tiles.

If someone can do the math and prove that something like this can be done with existing mappers without eating 2/3 of the CHR for the whole game, then I think it would be acceptable to make these legs move smoothly around the screen. Otherwise, it would be much more realistic to move them 8 pixels at a time, which IMO wouldn't even look bad for an object this size.

Quote:
Even a left to right scrolling floor if you wanted.

Yeah, this can be done no matter the mapper.
Re: Just an Idea
by on (#108235)
tokumaru wrote:
infiniteneslives wrote:
Why artificially limit the mapper and CHR data available?

Because he's trying to make this look authentic.

It could still be done on the NES. Now that I think about it more you could do it with MMC3 and 64-256KB CHR-RAM. Sure it was never used in a production game, but it's not that much of a stretch.

Quote:
As long as you could fit each leg/foot in 1KB

Have you seen the size of those legs?! 1KB is just 64 tiles, a small 8x8 tile area. [/quote]
It's not about the size of the legs, it's about how many unique tiles are in a single frame. He currently only has one tile, I assume he'd add some detail, but you could make a leg with 12 different tiles and the foot with it's entire border including the bottom of the leg with less than 40 tiles pretty easily having room to spare.

Quote:
Tile repetition gets very tricky with animated patterns, because the wrong tiles can bleed into each other, so in order to move the leg only with bankswitching you'd need unique tiles for many of the parts that look the same. The tile variations for all the possible vertical and horizontal positions would amount to a lot of tiles: for pixel-perfect precision you'd need 64 variations of each tile.

I was suggesting 2pixel precision for 16 versions, but I think you could still do 64 if you really wanted to. I was assuming 128KB 256KB CHR-RAM isn't hard to do, and doesn't stray far from production hardware.

Quote:
Even if you can magically fit each leg into 1KB, that's 128KB of CHR just for them.

Not if you're using CHR-RAM. You only need one copy of each tile used on a single frame. Just process and shift the tiles before copying it to CHR-RAM before the fight starts. You could even compress it futher since most of the tiles on the each legs could be the same or mirrored. You're only talking about 1-2KB of actual unique data.


Quote:
Also, after 8 pixels moved in any direction, you'd have to redraw the whole thing, not just a handful of tiles.

I guess you're right depending on how much detail there was. No biggie, you have atleast 2 name tables. Prep the one not in use beforehand over several frames and switch to it when the time comes.

Quote:
If someone can do the math and prove that something like this can be done with existing mappers without eating 2/3 of the CHR for the whole game, then I think it would be acceptable to make these legs move smoothly around the screen. Otherwise, it would be much more realistic to move them 8 pixels at a time, which IMO wouldn't even look bad for an object this size.

Even 4 pixel precision would be a worth while improvement IMO.
Re: Just an Idea
by on (#108285)
Well I made it move 8 pixels at a time and even with a delay in moving each tile, it still looks pretty smooth. It's kinda tricky to avoid it stomping around, too.