Six wrote:
How do I go from something simple like this, to actually making some form of a game?
It seems you have 2 separate things to learn: 6502 assembly and game programming. 6502 assembly is just a language, a way for you to communicate with the system and tell it what to do. Knowing *what* to tell the system is what game programming is all about.
If you think about it, the ultimate goal of a game program is to put objects in the correct positions, select the correct animation frames, control the number of lives a character has... it's all numbers. In order to calculate all those numbers, you have to simulate the game world as best as possible: you have to model everything that exists in the game world, storing their attributes in RAM. An enemy for example, needs a position (X and Y coordinates), health points, direction of movement, among other things. So, when you have every active game entity mapped in RAM, you need to make them "live". This is accomplished by processing a step for every object each frame. Every frame you have to loop through all of the objects and calculate what they'll do next - very small actions, like moving one pixel forward or initiating a a jump. At 60 frames per section, these small actions create the animations you see while playing.
The actions of the player are usually dictated by the data you read from the controller, along with whatever external forces you have acting upon him. For example, if gravity is pushing the player down, there are certain things he can't do even if the commands are given through the controller. You have to manually check for all of these exceptions, so you need to have a lot of attention to detail in order to foresee all these possible situations. Other objects are controlled by the external forces, and their own AI routines. AI routines are groups of rules that dictate how objects behave... whether they walk from side to side or follow the player, when to jump, and so on.
This is the most basic breakdown I can make of how a game works. Once you success in displaying simple objects on the screen, hopefully you'll realize that in order to control them and give them life you'll have to simulate them at a deeper level, in addition to worrying about their visual appearance.
Quote:
Whenever I write a short piece of code, compile it, and then try and emulate it, it either says "Invalid File" or "Corrupt File".
There might be some inconsistency between the information contained in the header and the rest of the ROM file. For example, if the header says that there are 2 PRG-ROM banks, you need to have 32KB of PRG-ROM... anything different than that and the emulator gets confused, and can't do anything other than declare the ROM corrupt.
Since you're beginning, I assume you're trying to make the simplest ROM possible: 16KB of PRG-ROM + 8KB or CHR-ROM, so the ROM file should be 16 bytes (header) + 16384 bytes (CHR-ROM) + 8192 bytes (PRG-ROM) = 24592 bytes. In windows, to see the exact sizes of the files in bytes, right-click them and select "Properties" (ignore "Size on disk", you want "Size"). 32KB of PRG-ROM is also common for beginners, in which case the file should be 40976 bytes.
Quote:
What's the correct header for Asm6? (Is there even one?)
My
ASM6 templates generate the header in a very straightforward way, with .db statements before the start of the program.
Quote:
What emulator is compatible with Asm6? (Right now, I'm using Nestopia.)
There's no such thing. No matter the assembler you use, the result SHOULD be an 100% valid NES program, capable of running on an actual NES console or any emulator that faithfully recreates that console.