davidn | Stumbling through Little Nemo

I cannot believe that the demographics of videos uploaded on Youtube are so heavily weighted that putting the innocent word "through" in a video title immediately throws up the tag suggestions "fire" and "flames".

Anyway. I tried another NES game, this time with an elaborate recording setup that I was playing about with all day that allows me to record my voice through the headset connected to the computer, while simultaneously running the game's audio to the guitar processor thing I use and recording it on that, then editing the two together at the end. So you can now hear both Little Nemo: The Dream Master and my reactions to it.

http://www.youtube.com/watch?v=CQItDEQn69Y

I'd never so much as seen the game before I started recording this video, but as it turns out, it's a game in which you hop around a dream world lulling monsters to sleep by throwing boiled sweets at them and then hijacking their bodies to get yourself around the level. It also turns out I'm dreadful at it, even though I was very proud of myself for getting to the second level.

The method I used for recording worked out rather well, but I'm confused by how out-of-sync the sound gets in Camstudio - it seems to play my voice and the video at normal speed, and yet the voice always drifts slightly ahead or behind the video over time. The process of resynchronizing them in iMovie just got more and more difficult as it went on, having to re-import the same file multiple times to split it up, having the Trim menu disappear entirely and with it preventing me from scrolling down to the last row of thumbnails on the video to edit the end - it came to be so excruciating that I found myself wondering insane things like whether Windows Movie Maker might actually be better at it.

Flat | Top-Level Comments Only

Well, panning register just about says it! The trouble is, the NES's tilemap is only exactly twice the size of the screen - and that's literally twice, not "twice in both dimensions i.e. four times". The developer can configure the 'two screens' to be laid out horizontally or vertically, which means that if you want to scroll in BOTH directions, one axis doesn't have any spare space to switch tiles where no-one's looking. (i.e., the tile that's leaving on the left is the same tile you're seeing wrap around on the right, so one of them has to be wrong.) And, if you're wondering why a mostly horizontal game didn't choose to have the vertical scrolling be the one that suffers, it's because the NES only has one tilemap layer, so the only way to have a status bar at the bottom is to put it on the same map as the level, and just change the panning registers to jump to a position that'll show it when the screen gets to that scanline.

Actually, interestingly enough (if your interest in the subject will permit me a tangent to share some trivia) scanline interrupts weren't actually built into the NES the way they were for virtually all later hardware... so, due to the relatively slow clock speed of the processor, you could never quite nail the start of a scanline precisely; and furthermore, due to the fact that the cycle length doesn't divide evenly into the drawing speed of the screen, you can't even nail it consistently in the same wrong place... watch the little white line at the top of the status bar (http://www.youtube.com/watch?v=TdI6wM4cnNc#t=4m25s). (The fact that glitches like these don't appear in some emulators is actually driving some people to write bottom-up cycle-perfect emulators, rather than the top-down sort that reproduce the designers' intentions... even if it means that it would take a 3 GHz machine to accurately recreate a Super Nintendo (http://arstechnica.com/gaming/news/2011/08/accuracy-takes-power-one-mans-3ghz-quest-to-build-a-perfect-snes-emulator.ars).)

Oh, and if you're curious why the color always seems to be wonkier than the actual tiles when dealing with a can't-hide-the-scrolling situation, it's because (oddly enough) you can actually only define the palette for every four (2x2) actual tiles. It's kind of strange that they'd make an assumption that forces gameplay to revolve around logical pieces of a certain size, but allow you to define graphical information SMALLER than that size... I guess the idea is to be able to put bevels on corners and such?

Anyway, part of me wanted to say "why did they bother having two whole maps but only in one axis, instead of having one spare column and one spare row which is all you'd need for clean scrolling", but the fact is, the edges of these images couldn't even be seen on cathode ray TV sets; on my friend's TV, I could see some of UndoDog, but I was taking the existence of that arrow to his right on faith (http://www.youtube.com/watch?v=ki15GoFn0Io&feature=related#t=3m03s)... so, for hardware like the NES that was really counting on the glass working that way, a filter like this (http://www.youtube.com/watch?v=09jU1roDz9Y&hd=1&t=7s) might be ideal! (Although it makes me wonder why they didn't just make the deadzone on either side of the image bigger if they weren't expecting it to be seen anyway...) I guess the two-screen system was meant for Zelda-style scrolling, with the assumption that developers would want to pre-load the entire new screen rather than doing it column by column?

Anyway, I've now spent like three hours getting distracted doing research and watching youtube videos, so I think that's all I have to say on the subject for now ;) Although, the process of it has given me some interesting ideas, and I always relish the chance to get out some of the information I compulsively stuff my head with, so thank you ;)

Then thank you for doing that on my behalf! This is why I love the people that still hang around on Livejournal :)

It's fascinating how the things that you think are just random artefacts all have a reason somewhere deep down at the hardware level, like that white line that happens because you can't quite pick up on the line being drawn with completely accurate timing. I, too, wondered why there wasn't just the memory to store an additional row and column rather than an entire screen's worth of tiles... I hadn't realized that CRTs were imprecise enough for a chunk of the screen that large to go missing, when we all used them, even though I know most games of the PS era offered a "screen position" option.

I say quite often now that I realized that my impossible life's ambition was to be a game developer in the early 90s... and I'd probably have loved the puzzle-like aspects of tricking the hardware or coming up with the multi-layered workaround of the Doom engine in the absence of true 3D if there hadn't been any better way at the time, but at the same time, now I'm very glad that the abstraction exists to be able to concentrate on actual... game design.

Y'know, I felt the same way when I first started learning about how all that stuff worked.... but then I started learning about modern GPUs, and.... oh my goodness, you have no idea how much cowboy programming is still going on just to make modern games look half as good as they do. :)

When you started talking about scanline interrupts, I had thought that you were going to start talking about the "Racing The Beam" book at some point.

The only reason I can think of the horizontal or vertical method of the tilemap was due to the simplicity of games like Super Mario Bros, where you could only move to the right. My guess is that they at least gave the ability to move in two directions (left/right or up/down) but maybe never considered that developers would want all four directions (i.e. "640k should be enough for everybody"), so it required some software finagling as you've mentioned above.

Stumbling through Little Nemo

no subject

no subject

no subject

no subject