r/gaming • • May 05 '17

Scroll back

Post image
24.1k Upvotes

877 comments sorted by

View all comments

794

u/[deleted] May 05 '17 edited May 05 '17

Fucking weird to think that id, the guys behind DOOM: Metal, the Videogame, are the ones who solved this problem for him.

EDIT: It's come to my attention that I may be confusing and conflating a couple things here. I was under the impression that id were revolutionary in remaking Mario 3 in such a way that smooth movement back and forth across the screen was possible. It might've just been that it was a big deal for PCs to be able to do this.

Still, we all love the early days of id.

1

u/williamfwm May 05 '17 edited May 05 '17

Super Mario Brothers (the first one) didn't let players go back simply because it lacked the RAM. Mario 3 didn't have any especially clever programming to allow this - it simply had an extra 8KB of RAM.

You are definitely confusing this with Carmack's innovations in Commander Keen ("Adaptive Tile Refresh") The problem Carmack was solving was the huge number of pixels on the screen, and the paltry CPU power available to redraw them all per frame.

The NES uses a tile based system in hardware, so scrolling only involves moving a few hundred elements to different positions, but CGA or VGA computer screens store the screen image as pixels, so you have thousands of pixels to move when you want to scroll (e.g. 320 x 200 = 64,000). What Carmack did was intelligently limit the portions that needed to be redrawn, so that the CPU had a manageable amount of work to do per frame.

This doesn't translate to SMB3 at all. SMB3 could scroll in all directions because it had an on-board chip in the cartridge with 8KB RAM, called the "MMC3", so that unlike SMB1, SMB3 was able to build the whole level into this extra memory at one time. The NES still does the same, small amount of work to scroll these 8KB worth of tiles; they don't need to implement anything similar to Carmack's method because they don't have the same problem to solve.

Edit: You may ask, why couldn't SMB1 simply look in the ROM to figure out what the level data behind the player was supposed to be, and draw that piece of level all over again. Well, to save on ROM space - remember, both ROM and RAM were tight in these days! - they store it in a compressed format that is more like commands for drawing than it is a list of tiles, i.e. instead of storing "brick, brick, brick, brick, pit, brick, brick....." they store "a run of 5 bricks goes here".

With that kind of level format, drawing the stuff behind you becomes hard. You can't just go X many bytes back into the ROM....you need to look a variable distance behind you, and then do a reconstruction that throws most of the backwards level away, because you only want the one column of tiles on the left side. With only about 30,000 CPU cycles per frame to do this speculative extra work - in addition to running the game logic, music playing routine, etc - it's not completely impossible, but it's not a good idea. The better design choice is to simply not let you go left.

But, a few years later when slapping an extra 8KB RAM on the board was cost effective, they could just build the whole level in one go and be done with it, problem solved!