The NES vs. its contemporary competition

[cyc]

In Flimbo's Quest (which has parallax scrolling unlike anything I've ever seen in any NES game)

this one is even more impressive

[OneCrudeDude]

That's amazing, the background and foreground elements are about equally complex.

[TailChao]

Interesting, thanks for the info.
Another sound chip that uses type of synthesis was in the Atari Lynx. It's LFSR, but for each channel it lets you select the taps and seed value, and I think that is a really cool idea. But I've played some Lynx games (not a lot of them), and I've only ever heard the music use square waves and noise.

Thought I'd chime in since I regularly work with this platform:

The cool thing is that the LFSR feeds into another unit which can either output the LFSR state directly (a pulse with an amplitude specified by the volume register) or integrate it (either add/lfsr[0]=1 or subtract/lfsr[0]=0 the value in the volume register from the current output amplitude). The latter allows you to get nice triangles as well as some incredibly bizarre waveforms.
You can also disable the waveform generator for any of the four channels and just write to its DAC directly.
One issue is that the LFSR is only 12-Bits. So your percussion will sound a little metallic (especially hi-hats). All things considered though, the hardware gets you great sound for its low complexity.

Most (if not all) of the Lynx games released during the console's life used Atari/Epyx's sound driver and tools, which had the odd restriction of not allowing the use of integrate mode for instruments (only in sound effects). I used these for my first game, and they're not bad tools by any means. But they weren't made with complicated instruments in mind (i.e. vibrato, arpeggios, etc).

I wrote a new driver and toolset for my upcoming game, and did a few covers as practice/tests (warning, I am not a music/audio guy). They might give a better idea of what the Lynx can do.

[tepples]

One issue is that the LFSR is only 12-Bits. So your percussion will sound a little metallic (especially hi-hats).

One thing that has worked for me for hi-hats on NES is alternating between 93- and 32767-step sequences on successive frames. I wonder if alternating 63- and 4095-step LFSRs might work for you.

[TailChao]

One thing that has worked for me for hi-hats on NES is alternating between 93- and 32767-step sequences on successive frames. I wonder if alternating 63- and 4095-step LFSRs might work for you.

I did not even think to try that. Thanks!

[tokumaru]

this one is even more impressive

The background looks pretty weird near rounded edges in the foreground though... Flimbo's Quest simply avoids rounded objects (anything non-rectangle, actually) where the foreground overlaps the background (you can only see such shapes in front of the sky).

[thefox]

In Flimbo's Quest (which has parallax scrolling unlike anything I've ever seen in any NES game)

this one is even more impressive

Looks cool, although it hard tell in some parts because of the bad quality video. It's probably using the same technique as Flimbo's Quest.

[OneCrudeDude]

Since we're on the Atari and C64 note, I wonder if any of you who are familiar with NES development have dabbled into development for those machines. They share the same 6502 based CPU, so maybe the main code would be similar across platforms. How each console handles graphics, controls, and other data differs from one to one. Or is adapting to the uniqueness of each platform the biggest challenge, despite using the same (well, similar) CPU?

[Dwedit]

Atari 2600 is like the opposite of the NES. You run your game logic during Vblank, and spend all your other CPU time drawing to the screen during rendering. Whereas on the NES, you draw during vblank, and spend all the other CPU time running the game logic while the screen is rendering.

[tokumaru]

They share the same 6502 based CPU, so maybe the main code would be similar across platforms.

Maybe the C64 and the NES have more in common, but things are very different with the 2600. With the 2600, you have about 5320 CPU cycles per frame for game logic (this can vary as you make the picture shorter or taller), versus ~27280 on the NES. This severely limits the amount of calculations you can perform per frame, so you won't be seeing on the 2600 the kind of complex code used for physics, collision detection, etc. you'd commonly find on the NES.

The small amount of RAM (128 bytes vs. 2KB - plus an extra 8KB that wasn't so uncommon) also limits how complex the world model can be. You can't track many objects with several unique attributes, so you end up with simpler/fewer/cloned enemies.

The consequence is that you end up making more extensive use of the Atari 2600 hardware. It has pixel perfect collision detection, so very few games would do it in software. It can automatically clone sprites once or twice, so you can control (and keep track of) a single object that looks like 3 individual objects on the screen (even though they all move together).

In the end, the abstraction from the hardware is not as big as in platforms with more RAM and CPU time.

[ccovell]

I am not a music/audio guy.

Nor were most of the Lynx game developers, which was part of the problem...

[Sik]

The small amount of RAM (128 bytes vs. 2KB - plus an extra 8KB that wasn't so uncommon) also limits how complex the world model can be. You can't track many objects with several unique attributes, so you end up with simpler/fewer/cloned enemies.

Don't forget that ROM was limited to 4KB (later there were mappers but for a long time they were stuck with 4KB). Can you even afford to have look-up tables when the ROM is so tiny?

[OneCrudeDude]

Interesting. What about the 7800, Lynx, or PC-Engine? Those all use some variant of the 6502 (some even say the PC-Engine was essentially an NES on steroids), and IIRC the Lynx got one homebrew game a few years back. I am aware that no two consoles have the exact video or audio controllers, and data regarding the control input would need to be changed accordingly, but could one build an engine for, say, an NES game and then port it (with the needed alterations) to another 6502 based machine? The 7800 would be a challenge since it works much like the 2600 did, and completely backwards from the NES, and the C64 would need a different code to get scrolling to work. As you can tell, I don't know much about how different these machines are.

[tokumaru]

could one build an engine for, say, an NES game and then port it (with the needed alterations) to another 6502 based machine?

Sure, as long as the machine the game is being ported to is similar enough to (or a superset of) the original machine. The key is to isolate everything that deals directly with the hardware. For example, you shouldn't have the object AI routines write directly to the OAM for rendering sprites, instead you should have the objects call a "DrawSprite" routine, which deals with the sprite data and formatting it for the sprite hardware. This way, all you have to do when porting the game is rewrite this specific routine, instead of messing with the inner workings of the game.

When you think about it, very little of a game program is about dealing with the hardware (except in extreme cases like the 2600), so as long as those parts are isolated, porting the game to similar platforms is relatively straightforward.

[lidnariq]

By way of analogy ... the original Macintosh, the Genesis, the Neo Geo, the Amiga, the Atari ST, NeXT machines, really early Sun workstations (everything before the Sun 4), earlier Palm PDAs, and many other things, all used the 68000 or its descendants. Yet I don't think anyone would assert that it would be significantly easier to port a program from one to another solely because they use the same CPU.