Lessons on NES

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
Lessons on NES
by on (#59675)
People complain about developers not giving back to the community, so as of about a year ago I started writing non-technical explanations of how the NES works. These have been geared more towards gamers then programmers, I generally don't give code samples or that kind of thing.

I don't pretend that these are the best methods, or that what i'm posting even works. But they're generally real world examples straight from my own code.

I've covered things like meta-tiles, palettes, nametables, physics, and even general game theory.

Here's an article I wrote today on data compression: http://cinematicbazaar.com/?p=80

by on (#59679)
I am adding your site to my list of stuff I really need to read. Plus your layout makes mine look like crap. :x

by on (#59682)
I learned about RLE by hacking Dragon Warrior 1, then Zelda 2. Then I saw other variants of RLE in DW2/3/4, then finally decided that LZ was the way to go if you can pull it off, unless you really have something that's very RLEable.

by on (#59685)
A couple of my attribute tables got knocked down to 4 bytes. I'm certainly open to other methods though, RLE certainly isn't the best out there.

by on (#59692)
Nice Site! It's very interesting to read about this since I'm working on a little nametable compression utility.

by on (#59715)
Your lessons are really great, you have all my congratulations.

I'd like to comment a few things :
Quote:
You take the player’s height (x location) and subtract a certain number of pixels (let’s say 10). Then in the next frame you subtract 9, then 8, then 7, then 6… etc. Then when the number hits 0, you just add them back on until you get back to 10. This doesn’t tie exactly to actual physics, you’d really want to change the value by a multiple of about 1.33 per frame, but it’s close enough for government work.

In fact it IS like real physics, see uniform acceleration. The value you add to the position is speed (position is integral of speed over time) and the value you remove to the speed is the acceleration (speed is integral of acceleration over time). The only reason player can jump higher than their own height in video games is that 1) the gravity is always much lower in video games than on earth and 2) characters are often super-deformed

Quote:
The NES’s processor doesn’t do multiplication, so if you want to multiply numbers, you have to add them together a bunch of times

This is WRONG !! Because the NES processor doesn't have an instruction that does the multiplication automatically doesn't mean it can't compute multiplications without LUT. Addind a number a bunch of times is a SHIT way to do it. You just have to perform a multiplication by colum, do a loop that shifts and add numbers.

Quote:

How does this play into Grand Theftendo? I’m colorblind, so i can’t tell if the screenshots abide by the 13 color limit, but it certainly doesn’t abide by the 16×16 grid layout for the background palettes. There are a few other problems with the screenshots, mostly involving how the game’s sprites are arranged. The NES does not have sprite rotation, what you draw is what you get. If you look at the screenshots, there are cars twisted every which way. While it’s possible to store all of those rotations in the CHR ROM, no programmer would ever do it because it’s a huge waste of space.

I think grand theftendo was going to use the MMC5, which has an optional mode called EX-Graphix or something like that which allows you to trick the NES to have each tile use it's own color (instead of 2x2 tiles like usual). Very few games used this, Just Breed and Metal Slader Glory are the only examples I can think off right now.
It's true the NES have no sprite rotation, but nobody prevents you to pre-rotate sprites. Solar Jetman did this so it's definitely acceptable in wases of spaces. I did a program to rotate an image on the NES, but it was SO FREAKING SLOW taking about 150 frames to scale/rotate a 32x32 image, which obviously would have no use in a game. The reason is is this slow is because it needed 32x32 matrix multiply, which means 32x32x4 = 4096 16-bit multiplications to be done.

by on (#59719)
Bregalad wrote:
Quote:
The NES’s processor doesn’t do multiplication, so if you want to multiply numbers, you have to add them together a bunch of times

This is WRONG !! Because the NES processor doesn't have an instruction that does the multiplication automatically doesn't mean it can't compute multiplications without LUT. Addind a number a bunch of times is a SHIT way to do it. You just have to perform a multiplication by colum, do a loop that shifts and add numbers.


I certainly could have phrased that better, you're right. My background in assembly comes mostly from MK68000 which has a multiplication instruction, 6502 obviously does not. That's really all I was trying to say. I have to go back and redo some of the posts since my other webhost nuked my pictures directory by mistake, so I'll make some edits while i'm in there.

As for grandtheftendo, it's not so much a matter of "could he have done it" as "why would you do it that way?". No one would fault an NES game where the cars driving slid left and right instead of rotated. When you're trying to cram that much data into an NES rom, why would you waste all that CHR space with the little bits of car that wouldn't fit in an 8x8 sprite during the rotation?

It wouldn't be difficult to draw those screens on an NES, a few hours at most if you already have the engine put together. But going from that to making a full fledged game with missions and AI and everything else just seems crazy. If you were going to do it, i don't think having the cars rotating would be the first thing you did. That's why i think the screenshots are just mockups.

Remember, this was a project that was started in 2002. Emulators were still pretty shitty back then, could someone have even pulled off a game like that with the level of knowledge back then? I look at GBAguy's tutorial and try to imagine someone writing grandtheftendo based off of that.

Even if the game wasn't an outright hoax, I don't think it ever had any chance of succeeding.

Someone asked for code on how to write the RLE compression into an NES game, someone else asked for code for GBA so I split the difference and wrote it in pseudocode. As always this may not be the most efficient way to pull this off, but it should work.

http://cinematicbazaar.com/?p=89

by on (#59721)
ProgrammingAce wrote:
As for grandtheftendo, it's not so much a matter of "could he have done it" as "why would you do it that way?". No one would fault an NES game where the cars driving slid left and right instead of rotated. When you're trying to cram that much data into an NES rom, why would you waste all that CHR space with the little bits of car that wouldn't fit in an 8x8 sprite during the rotation?

I don't see how that is wasting. You set some goals for the game and try to get to those goals within the limitations of the system. There's simply no other feasible way to get rotating sprites than to store them pre-rotated in the ROM.
Quote:
Remember, this was a project that was started in 2002. Emulators were still pretty shitty back then, could someone have even pulled off a game like that with the level of knowledge back then? I look at GBAguy's tutorial and try to imagine someone writing grandtheftendo based off of that.

There was plenty of information in 2002, just not as well organized (wikified) as today. Nobody is going to write a good game based on GBAguy's tutorials alone.

Personally I think Grandtheftendo was legit. The guy that was making it, Brian Provinciano, seemed very knowledgeable in both software and hardware stuff from what I could gather from reading his website. He has finished many big projects like SCI Studio. If you haven't seen his website I can't blame you for calling it a hoax though. Unfortunately his site has been down for some time now.

by on (#59722)
Quote:
Even if the game wasn't an outright hoax, I don't think it ever had any chance of succeeding.


It definitely was not a hoax, but when I saw that it got it's own website, without any kind of release, and tons of publicity, I figured then it would never be seen even if it ever was finished.

The author had a really interesting website that seems to be taken down, here's one example of some of the hardware info on there: http://web.archive.org/web/20071025062352/www.bripro.com/low/hardware/devtendo/index.php

by on (#59724)
I certainly can't argue with his technical knowledge. His breakdown of the MMC5 nametable exram certainly shows he could have pulled it off.

by on (#59725)
Quote:
Remember, this was a project that was started in 2002. Emulators were still pretty shitty back then, could someone have even pulled off a game like that with the level of knowledge back then? I look at GBAguy's tutorial and try to imagine someone writing grandtheftendo based off of that.


This is a joke, right?

What knowledge is new since 2002 that would have prevented grand theftendo? Ofcourse there have been new discoveries, but most of the stuff was known.

Brian was a guy who actually knew stuff. He wouldn't have used some newbie tutorial.

Also, his game was never aimed at emulators. He even intended to use a custom mapper iirc. So wheter emulators were shit or not in 2002 doesn't matter to his project.

by on (#59726)
Grandtheftendo was most certainly real. It was just the typical case of "programmer working on a very ambitious project that never gets done because of lack of time and motivation, not talent or knowledge". Several of us fall in that category.

by on (#59727)
tokumaru wrote:
Grandtheftendo was most certainly real. It was just the typical case of "programmer working on a very ambitious project that never gets done because of lack of time and motivation, not talent or knowledge". Several of us fall in that category.


Reading the wayback archive, i wholeheartedly agree. It's certainly not a lack of skill or understanding that killed the project. I've already removed that section from our site.

by on (#59728)
Quote:
The NES’s processor doesn’t do multiplication, so if you want to multiply numbers, you have to add them together a bunch of times


Sorry for jumping in a little late (can't access the site in school) but you CAN do multiplication and division by 2 doing bit shifts. 01 = 1 in binary, but shifting it over one would give you 10 which is two, same principle with division. Once again sorry for the lateness..