Fushek, on Wed Apr 25, 2012 1:19 PM, said:
OK ... I'm ready to start playing around have a couple of basic questions.
1) To start, I plan on breaking down some of the tutorials to get a basic understanding and then recreating in the pmach environment. Am I correct that most of the programming will take place for now in the pmach-test.asm or should I make changes directly into the asm files in the state sub-folder?
2) I thought to walk through the Hello World and Tag Along Todd tutorials on Intelliwiki. Does that make sense as a good place to start?
3) If you have a simple/basic screen background drawn (something that would just show a picture) that I could break down, it would help. I learn best by breaking down the work of others!
Thanks again ...
Fushek
Fushek,
I suggested using P-Machinery because it encapsulates the scaffolding and boilerplate code needed to get a program going, and gets it out of the way. If you go with one of the examples that come with the SDK-1600, like Tag-Along-Todd, you'll discover that a lot of the code is actually to support the "back-end" stuff, like synchronizing the "VBLANK" ISR, and stuff like that. P-machinery does all this too, but it wraps it up and puts it aside and abstracts it, so that you don't have to worry about it to begin with.
In my opinion, that gets in the way if you're learning, because it's hard to distinguish what is the boring skeleton code and what is actually the "game logic" code to get the cool things done.
That's just my opinion, though. The example programs are more like simple, one-off fragments that show off one feature; while P-Machinery strives to be a full-fledged game framework (albeit incomplete and flawed at the moment).
In P-Machinery, "pmach-test.asm" is the main file that loads all other modules, and sets up the game engine. If you add new module files, you should insert their "INCLUDE" directives in this file.
However, the interesting stuff happens in the "state" subdirectory. Each of those files contains the individual handlers for each of the machine states:
- st_dispatch.asm - This defines the dispatch table, which is the various states and sub-states in which the game can be. For instance, by default, the game starts in the "Title" state, which just shows the title screen. This state is sub-divided into "Initialization" (where the screen is drawn), and "waitkey" where the system just waits for user input. It also specifies which input-decoder will be used for each state, or none if not applicable.
- st_title.asm - Handlers for the "Title" state.
- st_level.asm - Handlers for the "Level" (game-play) state. It draws the title screen and waits for user input.
- st_over.asm - Handlers for the "Game Over" state. It waits for user input and restarts the game.
Take a look at those files. They are very short (for they do hardly anything by default) and have plenty of comments explaining what they do and how you can use them.
I can provide later today a sample of drawing a picture. Remember that there are two parts to drawing a picture: first you need to load any custom graphic tiles into GRAM, and then you need to assign those tiles to the background table (BACKTAB). P-Machinery provides some macros and functions to aid in this.
There's one more thing that P-Machinery does. It tries to handle the GRAM allocation for you. Instead of having to keep track of what you load where, you can define "blocks" of GRAM for particular purposes, like sprites, or background, or fonts. You do this in the "pmach-test.asm" file.
Take a loot at the section marked by the header, "GRAM GRAPHICS DATA."
In there, you can define your "GRAM Blocks." The point of this is that, then you can use the macros and functions offered by P-Machinery which expect such blocks as input, telling it which GRAM Block you want to load; instead of having to keep track of memory locations and segment sizes. It's just a convenience.
-dZ.