nesdev.org

hawken wrote:

Sik wrote:To be fair, many NES games avoided slopes altogether

Err, SMB3 was choc-full of slopes, Kirby too.

Giving a couple of examples doesn't really disprove the original statement. Sure, some platforming games on NES had slopes, but majority of them didn't.

thefox wrote:

hawken wrote:

Sik wrote:To be fair, many NES games avoided slopes altogether

Err, SMB3 was choc-full of slopes, Kirby too.

Giving a couple of examples doesn't really disprove the original statement. Sure, some platforming games on NES had slopes, but majority of them didn't.

To be fair those were two of the best selling games on the platform. Programming is hard in general, but you shouldn't limit capabilities by effort or majority. Slopes were 100% possible.

hawken wrote:

lidnariq wrote:As long as you can fit your entire set of parallax-ing tiles into just 64 tiles, and don't have more than ≈64 different scroll configurations that you want, that's a reasonable affordance for a NES game².

Didn't the MMC3 do away with such small tile limits?

The problem is that the larger the pattern that scrolls, the more banks you need to represent all possible rotations. If you're scrolling a pattern of 8x8 tiles (64x64 pixels, 64 tiles), you need 64 versions of those tiles if you want to animate them exclusively through bankswitching (which is the only possible way if the tiles cover a large area of the screen). This means that this pattern alone will consume 64KB of the CHR-ROM, 1/4 of what the MMC3 can handle. This means the MMC3 certainly didnt do away with such small tile limits when it comes to parallax scrolling, which needs multiple versions of the same patterns.

hawken wrote:To be fair those were two of the best selling games on the platform. Programming is hard in general, but you shouldn't limit capabilities by effort or majority. Slopes were 100% possible.

I may as well point out this then =P

Everybody says that game just uses line scrolling and bank switching over multiple backgrounds. The name table is what is being bank switched, right? There is no way the game has that many pattern sets.

Yeah it must be bank switching hell, but point stands that it looks like something the NES shouldn't be able to do at all, yet we don't go around treating that like the minimum bar for a NES game.

psycopathicteen wrote:The name table is what is being bank switched, right? There is no way the game has that many pattern sets.

IIRC, the name tables don't change... The background is always made of lines extending from the horizon to the bottom of the screen, and different CHR banks make the lines assume different colors, creating multiple one-dimensional patterns (because each line is the same color all the way). By switching banks multiple times in a frame it creates two-dimensional patterns. To animate these patterns it just changes the scanlines where the switches happen over time.

EDIT: Yup, just as I remembered. If you look at the 2 name tables in an hex editor you can clearly see the lines extending from the horizon towards the bottom of the screen. It's all solid areas and diagonal lines separating them.

Sik wrote:Yeah it must be bank switching hell, but point stands that it looks like something the NES shouldn't be able to do at all, yet we don't go around treating that like the minimum bar for a NES game.

Come on, Cosmic Epsilon is a much more extreme case than slopes. The 3D effect is achieved with a fairly complex trick, while slopes aren't any harder to implement on the NES than on the MD/Genesis, for example. The only reason why the NES has less games with slopes is because the NES is older, and older games often didn't have slopes. A lot of early MD/Genesis games didn't have slopes either (Alex Kidd is a notable example), but it wasn't because of a hardware limitation, it was just because slopes weren't very common yet, in any platform.

As slopes started to become the norm, they were extensively used on the NES during its later years. There are many, many more games than just the 2 hawken mentioned.

tokumaru wrote:

Sik wrote:Yeah it must be bank switching hell, but point stands that it looks like something the NES shouldn't be able to do at all, yet we don't go around treating that like the minimum bar for a NES game.

Come on, Cosmic Epsilon is a much more extreme case than slopes. The 3D effect is achieved with a fairly complex trick, while slopes aren't any harder to implement on the NES than on the MD/Genesis, for example. The only reason why the NES has less games with slopes is because the NES is older, and older games often didn't have slopes. A lot of early MD/Genesis games didn't have slopes either (Alex Kidd is a notable example), but it wasn't because of a hardware limitation, it was just because slopes weren't very common yet, in any platform.

As slopes started to become the norm, they were extensively used on the NES during its later years. There are many, many more games than just the 2 hawken mentioned.

The MD's flagship game had so many slopes it's hard to find a flat surface

Can we just say slopes were used extensively on NES but are hard to combine with parallax bank switching?

hawken wrote:

thefox wrote:Giving a couple of examples doesn't really disprove the original statement. Sure, some platforming games on NES had slopes, but majority of them didn't.

To be fair those were two of the best selling games on the platform. Programming is hard in general, but you shouldn't limit capabilities by effort or majority. Slopes were 100% possible.

Maybe "you shouldn't", but in practice you are limited by the amount of effort required by a feature (and the skills of the programmer, and the limitations of the hardware) when you have to finish a project in time.

Anyway, that was not really the point I was originally trying to make. I was just pointing out the flawed reasoning in "many NES games avoided slopes" => "not true, because games X and Y have slopes". Now, we can of course argue until the end of world about whether the reason for the lack of slopes in games was technical (like Sik said) or cultural (like tokumaru said). Probably it was bit of both.

Slopes are perfectly fine for NES-style games.

If you choose a single fixed angle for slopes then it's a bit easier to cheat that into a platform engine than to actually support arbitrary slopes and perform trigonometry.

Slopes are a design choice, not really about feasibility at all (any competent developer should be able to implement them). They're good for certain kinds of flow and movement, and obviously it affects level design.

It's kinda weird that there is a page of discussion here about slopes when the OP never even suggested them.

rainwarrior wrote:Slopes are a design choice, not really about feasibility at all (any competent developer should be able to implement them). They're good for certain kinds of flow and movement, and obviously it affects level design.

In the NES game Strider Capcom probably should've folded and left the slopes out of it, they're so broken. Although that is in line with the brokenness of other Capcom titles from the same era, like Trojan and Commando.

It's kinda weird that there is a page of discussion here about slopes when the OP never even suggested them.

Welcome to NesDev. But yeah, this discussion should probably be split (not that it was very interesting to start with...)

I think the common thread connecting the two was supposed to be "slopes would interfere with use of tile animations to perform parallax scrolling". Could you suggest a good split point?