For those who haven't seen Blazing Games yet, the final game was posted there today. While Blazing Games Inc. is closing, I do plan on continuing to develop games in my spare time. I do not feel it is appropriate to keep this blog going, as Blazing Games isn't so I have decided to start my own personal blog located at http://homebrewgamejam.blogspot.ca/ .
I am not going to go into details as to why it is closing down here, though in a few years I might write a post in my new blog about the decisions. I will say that I am going to back to university to complete my Bachelor degree. If any readers know of a Canadian company hiring part-time programmers (doesn't have to be game related) let me know.
I hope anyone reading this will join me on my new blog. If not, then so long...
Friday, August 29, 2014
Friday, August 22, 2014
NES Trivia Title and Results
From a development perspective, the title screen of the game is not that important. From a marketing perspective, it is vital as it is the first impression of the game that a player will receive. My personal opinion is somewhere between the two points of view. You want a title screen to be attractive but you do not want to spend too much time on creating the title screen. Some decent artwork and perhaps some simple animation will probably suffice for smaller projects. For larger projects with big budgets, some type of CGI may be what the project backer insists on.
For trivia, out title screen simply shows a graphical title while waiting for a button to be pressed. More elaborate games may have a menu of options. Different modes of play, options, credits, and instructions are possibilities. Handling a menu would be done similarly to how we handled answer selection in the main game. The different options simply jumping to a separate routine for handling the particular screen.
The only hard part of the title screen is displaying the graphical title. Once you realize that the graphics are just a bunch of tiles, it is not much of a leap before you realize that you can simply print graphics. The only real restrictions being that you are not able to use character 0 as that is the character that is reserved for indicating the end of a string, and that the length of the string be under 256 characters. In our case, most of the title image is empty space so we conserve ROM space by breaking the string into individual lines. It would certainly be possible to take advantage of the consecutive nature of screen memory to have multiple lines of graphical information in a string. Still, here is the code used for printing the N.E.S. part of the title.
CallClearScreen ' ',0,0
CallPrintStringAt titleNES1, 5,2,0
CallPrintStringAt titleNES2, 5,3,0
CallPrintStringAt titleNES3, 5,4,0
CallPrintStringAt titleNES4, 5,5,0
CallPrintStringAt titleNES5, 5,6,0
And here is the data for the print statements.
titleNES1 .db 30,10,32,32,32,30,32,32,32,30,30,30,30,32,32,32, 9,30,30,10,0
titleNES2 .db 30,11,10,32,32,30,32,32,32,30,32,32,32,32,32,32,11,10,32,11,0
titleNES3 .db 30,32,11,10,32,30,32,32,32,30,30,30,32,32,32,32,32,11,10,0
titleNES4 .db 30,32,32,11,10,30,32,32,32,30,32,32,32,32,32,32,10,32,11,10,0
titleNES5 .db 30,32,32,32,11,30,32,30,32,30,30,30,30,32,30,32,11,30,30, 8,32,30,0
The rest of the title screen is pretty much more of the same, though the press start and copyright messages are ASCII strings. Once the display is generated, we simply use the WaitForButtonPress and WaitForButtonPressEnd functions to wait to start the game.
The results screen is rendered pretty much the same way though has the interesting problem of having to display the score. Thankfully the score is a single digit number. This means that to display it, we only need to add 48 to the number to get the proper ASCII value for the number. For numbers greater than 9 we would need multiple digits which adds the problem of no BCD or division functions for the NES. We will be covering software multiplication and division shortly, but it is a complex topic so it is nice that we didn't need to get into it before creating this game. Here is the code for displaying the score.
LDA SCORE
CLC
ADC #48
; the cursor is already at the appropriate position in the PPU so
; simply need to send the character index to the PPU
STA $2007
And that is all there is to trivia. Of course, having randomly selected questions and mixing up the answers so they were not always in the same order would be nice. This requires quite a bit of work as we need to delve into the topics of entropy, pseudo-random numbers, and software multiplication. Software division will be covered as well as we will need it for displaying multi-digit numbers which is something the target RPG will need for sure. There is a lot to cover before we can do the full version of trivia, though I may have a couple of other simple games before we get to trivia 2. But…that will not be done on this blog as the Blazing Games Development blog is being shut down. More on that, and where future home-brew articles will appear will be covered next.
For trivia, out title screen simply shows a graphical title while waiting for a button to be pressed. More elaborate games may have a menu of options. Different modes of play, options, credits, and instructions are possibilities. Handling a menu would be done similarly to how we handled answer selection in the main game. The different options simply jumping to a separate routine for handling the particular screen.
The only hard part of the title screen is displaying the graphical title. Once you realize that the graphics are just a bunch of tiles, it is not much of a leap before you realize that you can simply print graphics. The only real restrictions being that you are not able to use character 0 as that is the character that is reserved for indicating the end of a string, and that the length of the string be under 256 characters. In our case, most of the title image is empty space so we conserve ROM space by breaking the string into individual lines. It would certainly be possible to take advantage of the consecutive nature of screen memory to have multiple lines of graphical information in a string. Still, here is the code used for printing the N.E.S. part of the title.
CallClearScreen ' ',0,0
CallPrintStringAt titleNES1, 5,2,0
CallPrintStringAt titleNES2, 5,3,0
CallPrintStringAt titleNES3, 5,4,0
CallPrintStringAt titleNES4, 5,5,0
CallPrintStringAt titleNES5, 5,6,0
And here is the data for the print statements.
titleNES1 .db 30,10,32,32,32,30,32,32,32,30,30,30,30,32,32,32, 9,30,30,10,0
titleNES2 .db 30,11,10,32,32,30,32,32,32,30,32,32,32,32,32,32,11,10,32,11,0
titleNES3 .db 30,32,11,10,32,30,32,32,32,30,30,30,32,32,32,32,32,11,10,0
titleNES4 .db 30,32,32,11,10,30,32,32,32,30,32,32,32,32,32,32,10,32,11,10,0
titleNES5 .db 30,32,32,32,11,30,32,30,32,30,30,30,30,32,30,32,11,30,30, 8,32,30,0
The rest of the title screen is pretty much more of the same, though the press start and copyright messages are ASCII strings. Once the display is generated, we simply use the WaitForButtonPress and WaitForButtonPressEnd functions to wait to start the game.
The results screen is rendered pretty much the same way though has the interesting problem of having to display the score. Thankfully the score is a single digit number. This means that to display it, we only need to add 48 to the number to get the proper ASCII value for the number. For numbers greater than 9 we would need multiple digits which adds the problem of no BCD or division functions for the NES. We will be covering software multiplication and division shortly, but it is a complex topic so it is nice that we didn't need to get into it before creating this game. Here is the code for displaying the score.
LDA SCORE
CLC
ADC #48
; the cursor is already at the appropriate position in the PPU so
; simply need to send the character index to the PPU
STA $2007
And that is all there is to trivia. Of course, having randomly selected questions and mixing up the answers so they were not always in the same order would be nice. This requires quite a bit of work as we need to delve into the topics of entropy, pseudo-random numbers, and software multiplication. Software division will be covered as well as we will need it for displaying multi-digit numbers which is something the target RPG will need for sure. There is a lot to cover before we can do the full version of trivia, though I may have a couple of other simple games before we get to trivia 2. But…that will not be done on this blog as the Blazing Games Development blog is being shut down. More on that, and where future home-brew articles will appear will be covered next.
Friday, August 15, 2014
NES Trivia Gameplay
As covered in the NES Trivia Screen article, the code for this game is at http://blazinggames.com/books/NES/NESTrivia/ . We are only covering the most relevant snippets of code. If you wish to look at the main game loop in its entirety search the code for the MainGameLoop label.
With the Questions displayed we now need to monitor the user input. To allow for the player to hold the up or down buttons down there is a delay between reads of the joystick that is initiated when the player performs an action. This works well for holding down the directions but rapidly clicking on a button doesn't work as well as it should as some of the clicks can happen between the delay. This will be fixed in the second version of trivia.
DEC INPUT_DELAY
BNE MainGameLoop_adjustScroll
INC INPUT_DELAY ; Make sure if no input we update next frame
JSR ReadController1
TAY
Moving up or down is simply a matter of adjusting the CURRENT_ANSWER variable. Because there are only 4 possible answers (0..3) we can simplify the range checking logic by simply using the AND operation to force the value of the adjusted CURRENT_ANSWER to within the acceptable range. This technique saves us from having to have a conditional branch which, at least in my opinion, makes for more readable code. While people who are not familiar with boolean operations may disagree with this, if you are programming in assembly language a lot you will quickly get use to working with boolean operations.
MainLoop_checkButtonUp:
TYA
AND #BUTTON_UP
BEQ MainLoop_checkButtonA
LDX CURRENT_ANSWER
DEX
TXA
AND #3
STA CURRENT_ANSWER
LDA #DELAY_TIME
STA INPUT_DELAY
JMP MainGameLoop_adjustScroll
The heart of the trivia game logic comes when the A button is pressed. The handling code waits for the button to be released and then calls DisplayQuestionResults. This function potentially prints a lot to the screen so we temporarily turn off the display so we can write to the PPU without any issues. It then sets up the print location before checking to see if the answer the player selected is the correct answer. The appropriate result string is printed, and if the answer is correct the score is increased. Finally, this function prints the explanation before returning to the main game loop.
DisplayQuestionResults:
LDA #$00
STA $2001 ; disable rendering
; set up print coordinates
TAX ; accumulator already 0
LDY ANSWER_ROWS+4
JSR SetScreenXY
; See if selected answer is correct
LDY #14 ; Offset to correct answer
LDA [QUESTION_INFO_PTR],Y
CMP CURRENT_ANSWER
BEQ DisplayQuestionResults_correct
CallPrintString incorrectText
JMP DisplayQuestionResults_explain
DisplayQuestionResults_correct:
INC SCORE
CallPrintString correctText
DisplayQuestionResults_explain:
; set up coordinates for explanation text
LDY ANSWER_ROWS+4
INY
INY
LDA #0
TAX
JSR SetScreenXY
; print explanation
LDY #12
JSR PrintQuestionInfoString
LDA #011110 ; enable background + sprites
STA $2001
RTS
When we return to the main loop we wait for the press and then the release of a button so that the player has time to acknowledge the explanation. After this, we need to know if the question is the last question or not. If it is the last question, we jump to the summary screen loop. If it is not the last question, the pointer to the current question info structure is incremented by 16 (the length of the structure) and we call DisplayQuestion to get the next question displayed.
LDX CURRENT_QUESTION
INX
STX CURRENT_QUESTION
CPX #9
BEQ SummaryScreen
LDA QUESTION_INFO_PTR
CLC
ADC #16
BCC MainLoop_showNextQuestion
INC QUESTION_INFO_PTR+1
MainLoop_showNextQuestion:
STA QUESTION_INFO_PTR
JSR DisplayQuestion
We are now finished with the game's core logic. Essentially we have a game. The only thing missing from having a complete game at this point is the title and summary screens. Normally, these are not things that I would bother to cover as they are very straightforward, but as this is our first NES game, it is probably a good idea to cover them. This is what we will be doing next.
With the Questions displayed we now need to monitor the user input. To allow for the player to hold the up or down buttons down there is a delay between reads of the joystick that is initiated when the player performs an action. This works well for holding down the directions but rapidly clicking on a button doesn't work as well as it should as some of the clicks can happen between the delay. This will be fixed in the second version of trivia.
DEC INPUT_DELAY
BNE MainGameLoop_adjustScroll
INC INPUT_DELAY ; Make sure if no input we update next frame
JSR ReadController1
TAY
Moving up or down is simply a matter of adjusting the CURRENT_ANSWER variable. Because there are only 4 possible answers (0..3) we can simplify the range checking logic by simply using the AND operation to force the value of the adjusted CURRENT_ANSWER to within the acceptable range. This technique saves us from having to have a conditional branch which, at least in my opinion, makes for more readable code. While people who are not familiar with boolean operations may disagree with this, if you are programming in assembly language a lot you will quickly get use to working with boolean operations.
MainLoop_checkButtonUp:
TYA
AND #BUTTON_UP
BEQ MainLoop_checkButtonA
LDX CURRENT_ANSWER
DEX
TXA
AND #3
STA CURRENT_ANSWER
LDA #DELAY_TIME
STA INPUT_DELAY
JMP MainGameLoop_adjustScroll
The heart of the trivia game logic comes when the A button is pressed. The handling code waits for the button to be released and then calls DisplayQuestionResults. This function potentially prints a lot to the screen so we temporarily turn off the display so we can write to the PPU without any issues. It then sets up the print location before checking to see if the answer the player selected is the correct answer. The appropriate result string is printed, and if the answer is correct the score is increased. Finally, this function prints the explanation before returning to the main game loop.
DisplayQuestionResults:
LDA #$00
STA $2001 ; disable rendering
; set up print coordinates
TAX ; accumulator already 0
LDY ANSWER_ROWS+4
JSR SetScreenXY
; See if selected answer is correct
LDY #14 ; Offset to correct answer
LDA [QUESTION_INFO_PTR],Y
CMP CURRENT_ANSWER
BEQ DisplayQuestionResults_correct
CallPrintString incorrectText
JMP DisplayQuestionResults_explain
DisplayQuestionResults_correct:
INC SCORE
CallPrintString correctText
DisplayQuestionResults_explain:
; set up coordinates for explanation text
LDY ANSWER_ROWS+4
INY
INY
LDA #0
TAX
JSR SetScreenXY
; print explanation
LDY #12
JSR PrintQuestionInfoString
LDA #011110 ; enable background + sprites
STA $2001
RTS
When we return to the main loop we wait for the press and then the release of a button so that the player has time to acknowledge the explanation. After this, we need to know if the question is the last question or not. If it is the last question, we jump to the summary screen loop. If it is not the last question, the pointer to the current question info structure is incremented by 16 (the length of the structure) and we call DisplayQuestion to get the next question displayed.
LDX CURRENT_QUESTION
INX
STX CURRENT_QUESTION
CPX #9
BEQ SummaryScreen
LDA QUESTION_INFO_PTR
CLC
ADC #16
BCC MainLoop_showNextQuestion
INC QUESTION_INFO_PTR+1
MainLoop_showNextQuestion:
STA QUESTION_INFO_PTR
JSR DisplayQuestion
We are now finished with the game's core logic. Essentially we have a game. The only thing missing from having a complete game at this point is the title and summary screens. Normally, these are not things that I would bother to cover as they are very straightforward, but as this is our first NES game, it is probably a good idea to cover them. This is what we will be doing next.
Friday, August 8, 2014
NES Trivia Screen
As usual I am only going to cover the snippets of code I consider most relevant for the discussion. For those of you who want to see all the code, it is located at @link to source code here@.
The core of the game is fairly simple. We start by clearing the screen and displaying the label for the current question. As the label always takes the form of “Question ???” we save a bit of memory by having the label string only create the ??? part of the string generating the full string on the fly. The label is underlined. This is done by taking advantage of the fact that the PrintString function returns the length of the printed string in the Y register. Notice that the use of macros makes the code quite a bit more human-readable.
CallClearScreen ' ',0,0
CallStrNCpy baseLabel, SCRATCH_PAGE, 0
LDY #0
LDA [QUESTION_INFO_PTR],Y
STA SOURCE_PTR
INY
LDA [QUESTION_INFO_PTR],Y
STA SOURCE_PTR+1
JSR AppendString
; once created we print it
CallSetScreenXY 2,1,0
CallPrintString SCRATCH_PAGE
; underline Title
TYA
PHA ; save length of string to underline
CallSetScreenXY 2,2,0
PLA ; retrieve length of label string
TAX ; transfer to appropriate parameter for call
LDA #'='
JSR PrintRepeatedChar
Printing the question, answers, and later the explanation is all pretty much the same code but with different pointers being used, this is ideal code for a function. The desired string to be printed is part of the question info structure. We set Y to the offset within this structure to the pointer for the string we want printed. In case you are wondering, the term for a pointer to a pointer is called a handle. We copy this pointer to the zero-page SOURCE_PTR variable then call the PrintString function.
PrintQuestionInfoString:
LDA [QUESTION_INFO_PTR],Y
STA SOURCE_PTR
INY
LDA [QUESTION_INFO_PTR],Y
STA SOURCE_PTR+1
JSR PrintString
Now, as we did for underlining, we take advantage of the returned length value to determine how many rows were used for printing the string. I should point out that this is not always correct as the answers are indented by a couple of characters. This generally is not a problem but is something that has to be kept in mind when creating the data for the game. Divide the length printed by 32 to determine how many lines were printed. It is important to remember that the remainder from the divide is dropped. This means we need to add 1 to the result. As we are adding a blank line between rows this means we need to add 2 to get the appropriate next row.
TYA ; divide printed length by 32
LSR A
LSR A
LSR A
LSR A
LSR A
CLC ; add it to current printed row so we know what line we are on
ADC CURRENT_ROW
CLC ; add 2 so we know appropriate row for next print
ADC #2
STA CURRENT_ROW
RTS
While tracking the row for printing is important, we also need this information for handling the player choice. After calling the above function to print the question, we store the returned row number which will be the location of the first answer. We then call the function again for each of the answers storing the rows in subsequent memory locations. This is the equivalent of creating an array of rows. You may have noticed that there is an extra row stored. This will be used to display the results and explanation.
The players choice is represented by a right arrow sprite. The column the sprite appears on is set to 4 when the sprite is set up and never changes. The vertical placement of this sprite is based on the current choice that is selected which is stored in the CURRENT_ANSWER variable. The value in this variable is used to index the rows table we stored the row in above to determine the Y coordinate of the sprite.
LDY CURRENT_ANSWER
LDA ANSWER_ROWS,Y
ASL A
ASL A
ASL A
STA SPRITE_PAGE
At this point we have the question displayed with an arrow to the currently selected answer. Getting player input and determining if the selected question is our next task.
The core of the game is fairly simple. We start by clearing the screen and displaying the label for the current question. As the label always takes the form of “Question ???” we save a bit of memory by having the label string only create the ??? part of the string generating the full string on the fly. The label is underlined. This is done by taking advantage of the fact that the PrintString function returns the length of the printed string in the Y register. Notice that the use of macros makes the code quite a bit more human-readable.
CallClearScreen ' ',0,0
CallStrNCpy baseLabel, SCRATCH_PAGE, 0
LDY #0
LDA [QUESTION_INFO_PTR],Y
STA SOURCE_PTR
INY
LDA [QUESTION_INFO_PTR],Y
STA SOURCE_PTR+1
JSR AppendString
; once created we print it
CallSetScreenXY 2,1,0
CallPrintString SCRATCH_PAGE
; underline Title
TYA
PHA ; save length of string to underline
CallSetScreenXY 2,2,0
PLA ; retrieve length of label string
TAX ; transfer to appropriate parameter for call
LDA #'='
JSR PrintRepeatedChar
Printing the question, answers, and later the explanation is all pretty much the same code but with different pointers being used, this is ideal code for a function. The desired string to be printed is part of the question info structure. We set Y to the offset within this structure to the pointer for the string we want printed. In case you are wondering, the term for a pointer to a pointer is called a handle. We copy this pointer to the zero-page SOURCE_PTR variable then call the PrintString function.
PrintQuestionInfoString:
LDA [QUESTION_INFO_PTR],Y
STA SOURCE_PTR
INY
LDA [QUESTION_INFO_PTR],Y
STA SOURCE_PTR+1
JSR PrintString
Now, as we did for underlining, we take advantage of the returned length value to determine how many rows were used for printing the string. I should point out that this is not always correct as the answers are indented by a couple of characters. This generally is not a problem but is something that has to be kept in mind when creating the data for the game. Divide the length printed by 32 to determine how many lines were printed. It is important to remember that the remainder from the divide is dropped. This means we need to add 1 to the result. As we are adding a blank line between rows this means we need to add 2 to get the appropriate next row.
TYA ; divide printed length by 32
LSR A
LSR A
LSR A
LSR A
LSR A
CLC ; add it to current printed row so we know what line we are on
ADC CURRENT_ROW
CLC ; add 2 so we know appropriate row for next print
ADC #2
STA CURRENT_ROW
RTS
While tracking the row for printing is important, we also need this information for handling the player choice. After calling the above function to print the question, we store the returned row number which will be the location of the first answer. We then call the function again for each of the answers storing the rows in subsequent memory locations. This is the equivalent of creating an array of rows. You may have noticed that there is an extra row stored. This will be used to display the results and explanation.
The players choice is represented by a right arrow sprite. The column the sprite appears on is set to 4 when the sprite is set up and never changes. The vertical placement of this sprite is based on the current choice that is selected which is stored in the CURRENT_ANSWER variable. The value in this variable is used to index the rows table we stored the row in above to determine the Y coordinate of the sprite.
LDY CURRENT_ANSWER
LDA ANSWER_ROWS,Y
ASL A
ASL A
ASL A
STA SPRITE_PAGE
At this point we have the question displayed with an arrow to the currently selected answer. Getting player input and determining if the selected question is our next task.
Friday, August 1, 2014
Drone Defence Postmortem
It is a new month so time for my postmortem of my Blazing Games release for this month. The game is my first game created with OpenFl which is the flash-like library for Haxe. I am not sure why I decided to try doing a similar game to what I did as my Game Maker test game, but I did. The game needs a lot of polish yet, but for the limited time I put into it worked out great.
What Went Right
OpenFL is a flash-like library for Haxe. While Haxe already supports the Flash API for projects exporting to Flash, OpenFL expands this to all the other platforms that programs can be exported to. At least in theory. As I have done a lot of work using the Flash API, this is a great feature for me as it makes getting up to speed with Haxe much easier. If you are not familiar with Flash, this is probably not that big of a deal but it is still a decent library. I have tried a number of different Flash-like libraries for a variety of languages to various results. This library, from what I did with it, worked exactly like I expected (at least until I exported for HTML5) which was nice considering the learning curve that Haxe gave me.
Mixed Blessings
Haxe is a rather interesting language as instead of compiling to machine-language (or a virtual machine-language) it compiles to a number of different programming languages for a variety of different platforms. The idea here is that different platforms have different key languages for development. Windows is C++, IOS/OSX was Objective-C, Android is Java, the internet is HTML5 or Flash. The idea here is that you code in Haxe then fine-tune for each platform in it’s preferred language. It is, however, it’s own language with it’s own way of doing things. While similar to ActionScript, it is different enough to occasionally throw a wrench in the works. One of the nice things it does, which I wish C and all its decedents did, is automatically break switch statements unless you explicitly tell it not to. One thing I didn’t like is the requirement of iterators in for loops.
What Went Wrong
Unfortunately, as is often the case with projects still in development, there are issues with OpenFL. In my case, the HitTestObject method did not work in the HTML5 export. As this is essentially just a bounding box test, I replaced my hit test code with calls to check for rectangle intersections between the bounding boxes for the objects. The problem here then became there always being a collision. After checking the results of the getBounds function, I discovered to my dismay that the width and height of the object were the canvas size and not the size of the sprites. Worse, requesting the width and height of the sprite also returned the canvas width and height. These bugs don’t exist in the other export formats I tried so I ended up releasing the Flash build of the game instead of a HTML5 build like I was originally planning to. I will have to look into this issue a bit more as I really liked OpenFL and think if issues like this can be fixed this would be a great platform to develop for.
What Went Right
OpenFL is a flash-like library for Haxe. While Haxe already supports the Flash API for projects exporting to Flash, OpenFL expands this to all the other platforms that programs can be exported to. At least in theory. As I have done a lot of work using the Flash API, this is a great feature for me as it makes getting up to speed with Haxe much easier. If you are not familiar with Flash, this is probably not that big of a deal but it is still a decent library. I have tried a number of different Flash-like libraries for a variety of languages to various results. This library, from what I did with it, worked exactly like I expected (at least until I exported for HTML5) which was nice considering the learning curve that Haxe gave me.
Mixed Blessings
Haxe is a rather interesting language as instead of compiling to machine-language (or a virtual machine-language) it compiles to a number of different programming languages for a variety of different platforms. The idea here is that different platforms have different key languages for development. Windows is C++, IOS/OSX was Objective-C, Android is Java, the internet is HTML5 or Flash. The idea here is that you code in Haxe then fine-tune for each platform in it’s preferred language. It is, however, it’s own language with it’s own way of doing things. While similar to ActionScript, it is different enough to occasionally throw a wrench in the works. One of the nice things it does, which I wish C and all its decedents did, is automatically break switch statements unless you explicitly tell it not to. One thing I didn’t like is the requirement of iterators in for loops.
What Went Wrong
Unfortunately, as is often the case with projects still in development, there are issues with OpenFL. In my case, the HitTestObject method did not work in the HTML5 export. As this is essentially just a bounding box test, I replaced my hit test code with calls to check for rectangle intersections between the bounding boxes for the objects. The problem here then became there always being a collision. After checking the results of the getBounds function, I discovered to my dismay that the width and height of the object were the canvas size and not the size of the sprites. Worse, requesting the width and height of the sprite also returned the canvas width and height. These bugs don’t exist in the other export formats I tried so I ended up releasing the Flash build of the game instead of a HTML5 build like I was originally planning to. I will have to look into this issue a bit more as I really liked OpenFL and think if issues like this can be fixed this would be a great platform to develop for.
Friday, July 25, 2014
Designing NES Trivia
As I have said before, and have heard other people say as well, trivia is a trivial game to create. It consists of a set number of rounds. Each round has a question presented to the player with the player choosing the answer from one of a set number of answers. Once the player selects his or her choice, they are told if they are correct and an explanation of the correct answer is given.
This can be represented by a fairly simple data structure:
0..1 Pointer to label for the question string
2..3 Pointer to question string
4..5 Pointer to first (0) answer
6..7 Pointer to second (1) answer
8..9 Pointer to third (2) answer
10..11 Pointer to fourth (3) answer
12..13 Pointer to explanation
14..15 Correct answer number
The correct answer number only needs a single byte but uses a pair of bytes for the simple reason that this makes the structure 16 bytes. Powers of 2 are always nice to have as that allows you to take advantage of the bit-shifting operations instead of using more costly multiplication. When you consider that the 6502 does not have multiplication instructions, meaning that software multiplication needs to be done, this is a very important consideration. The actual implementation of a question looks like this:
questionInfo:
.dw q1_label, q1_question
.dw q1_answer0, q1_answer1, q1_answer2, q1_answer3
.dw q1_explanation, 2
; additional question info structures follow this...
; then we have the actual string data
q1_label: .db "One",0
q1_question: .db "The original Japanese version "
.db "of the NES was called?",0
q1_answer0: .db "Nintendo Entertainment System",0
q1_answer1: .db "Adam",0
q1_answer2: .db "Nintendo Family Computer",0
q1_answer3: .db "Nintendo Advanced Video System",0
q1_explanation: .db "The Nintendo Family Computer "
.db "became better known by the short"
.db "name: Famicom.",0
You will notice that strings are specially formatted to take advantage of the fact that the lines are 32 characters long. Extra space characters are added to fill out lines when necessary. While it would certainly be possible to write code to do the formatting for us, for this first version it is not necessary. The decision to write formatting code will depend on how much storage space is wasted by extra characters for formatting. When we get to the point where code to format text will take significantly less memory than will be saved by embedding formatting into the strings then it will be worth writing the code.
The game itself consists of three separate screens. The title screen and results screen are simple text displays with nothing special about them. The main game screen is fairly simple as well but has three separate phases of operation. The first phase displays the question and answers. The second phase has the user moving a pointer between the four different answers and determining which answer the user has selected. The final phase is determining the results of the user selection and displaying them as well as the explanation. Development starts with getting the game screen to work. Once it is working the game can be completed by adding the title and results screens. That is what we will be focusing on after next month's postmortem.
This can be represented by a fairly simple data structure:
0..1 Pointer to label for the question string
2..3 Pointer to question string
4..5 Pointer to first (0) answer
6..7 Pointer to second (1) answer
8..9 Pointer to third (2) answer
10..11 Pointer to fourth (3) answer
12..13 Pointer to explanation
14..15 Correct answer number
questionInfo:
.dw q1_label, q1_question
.dw q1_answer0, q1_answer1, q1_answer2, q1_answer3
.dw q1_explanation, 2
; additional question info structures follow this...
; then we have the actual string data
q1_label: .db "One",0
q1_question: .db "The original Japanese version "
.db "of the NES was called?",0
q1_answer0: .db "Nintendo Entertainment System",0
q1_answer1: .db "Adam",0
q1_answer2: .db "Nintendo Family Computer",0
q1_answer3: .db "Nintendo Advanced Video System",0
q1_explanation: .db "The Nintendo Family Computer "
.db "became better known by the short"
.db "name: Famicom.",0
The game itself consists of three separate screens. The title screen and results screen are simple text displays with nothing special about them. The main game screen is fairly simple as well but has three separate phases of operation. The first phase displays the question and answers. The second phase has the user moving a pointer between the four different answers and determining which answer the user has selected. The final phase is determining the results of the user selection and displaying them as well as the explanation. Development starts with getting the game screen to work. Once it is working the game can be completed by adding the title and results screens. That is what we will be focusing on after next month's postmortem.
Friday, July 18, 2014
RPG Maker VX Ace Review
Sorry for not posting last week. Here is my review of RPG Maker VX Ace. It is a fairly long review which is broken into good, bad and ugly sections.
The Good
I actually consider this to be a really good program that I would gladly use to develop games in if it were not for the items in the ugly section. Before I get to the ugly points, lets first look at where the program excels.
Map Editor
When you consider that RPGs consist of multiple maps it is important that you have a decent map editor. Thankfully the map editor is very nice. It is tile based with each map having a tile-set that the map is made of. Tile-sets are made up of one or more image files. It is possible to share images between tile-sets which can reduce the number of necessary image files.
My favorite feature of the map editor is smart tiles. These tiles work by looking at the surrounding tiles and choosing the appropriate tile. For example, let's say you were adding a 4x4 tile rug to a room. The corners and edges would become the appropriate border pattern while the centre four tiles are the mid-carpet image.
The map supports multiple layers. Essentially you have your floor/wall layer which various decoration tiles can be placed over top of. This allows you to have things such as walls that have pictures on them or tables and chairs in the middle of the room. Tiles have three states of enterability. They can be solid, appear over the player or appear under the player. Each tile can also have an event placed on it. Events can have their own sprite and have scripts attached to them. I will cover events in more detail in the scripting section.
Database
The database holds all the actors, classes, skills, weapons, armours, enemies, troops, states, tile sets, common events, system, and terms that the game uses. Editing these is what makes your game unique. There is a default starting database that is set up for your typical fantasy game. If you are not developing a fantasy game or want to create an original game then you will pretty much want to get rid of most of the stuff in the database and start from scratch.
Database pages generally give you a list of all the items in that category. The number of items in a category is set to a certain number of entries, but those can be changed to however many items you need. Each item then has a simple to fill out form making creating and editing items very simple.
Scripting
The power of any game engine is largely dependent on how good the scripting system is. There are two parts to this factor. The actual language(s) the engine supports and how much the API for the game lets the player control the engine.
Language-wise RPG Maker VX Ace uses the Ruby language. This is a very flexible and powerful language but not something easy for a first-time programmer to grasp. To allow non-programmers the ability to create scripts, the program also offers a menu-based scripting language. This is a fairly easy to use language where you assemble commands based on typical RPG actions and fill out dialog boxes with the details of what you want to do. There is enough actions that you can accomplish most game tasks.
For those going with Ruby, which I never did for First, you have access to an API that gives you access to pretty much everything you would want to do with the engine and even gives you access to the windows API giving you a lot of power if you absolutely need it.
The Bad
While this is a great tool, there are some rough edges.
Database dependencies
While the database is nice to use, there is one really annoying thing about it. Many categories of items depend on items in other categories. If you are creating an encounter in the troops tab, you need to make sure the monsters have already been created. The monsters need to have skills and items set, and so on. What I would have liked to have seen is the option to create a new required skill or item on the fly so that when creating something you are not jumping back and forth between tabs.
Packaging
I covered the packaging issue in my postmortem of my first RPG Maker game. The tool for creating a distributable package does not analyze your game for the assets that are actually used but instead includes all the files in the resource manager. This means you need to manually remove any items your game does not need otherwise it will be included in the distribution. If you are doing a total conversion, this may not be that bad as you can start by removing everything and only adding back what items you need but this is still a lot of work that could have easily been automated.
Documentation
The documentation that comes with the package is kind of sparse. It covers the basics of the tool and has an API reference for Ruby programmers. It has no tutorials on how to use the game nor any explanation of how the stats in the default database work. To find answers to these questions requires searching forums or delving into the ruby code and spending hours looking through the database to piece how things work. There are some really good RPG Maker VX Ace tutorials on the internet, which you really should go through before using the tool for the first time, but nothing with the package.
The Ugly
None of the bad items above are enough to deter most people from using the tool. I would too, but there are three issues that prevent me from doing so.
Resolution
The game resolution is really ancient. Anybody who has played a RPG Maker game probably has noticed the small window that the game is played in. While it is possible to get past this limitation by liberal use of Ruby scripting and Windows API calls, this would be a huge amount of work. I am hoping that if there is another version of RPG Maker released that it will at a minimum address this issue. Possibly by supporting different resolutions of tile-images though even the simple solution of scaling tiles would be sufficient for many people. If RPG Maker VX Ace had proper support for HD resolutions then I would probably be developing a commercial game in it right now despite the other two ugly items.
Windows only
Having used cross-platform languages for over a decade, I really don’t understand why developers still release tools that only create stuff that will run on Windows. Windows is such a large base that this is not an outright killer, but when combined with the resolution limitations makes it so for me. Minimally I would like to have the ability to export games to OSX and Linux. Ideally support for tables as well. Even if you had to pay extra for the ability to port to different platforms, this would be a great feature to have.
DLC Licensing
One thought that I had was to simply use RPG Maker as a prototyping tool and then find a way of exporting everything to another engine that overcame the resolution and platform limitations of the tool. Making this much more complicated is the fact that all the built-in graphics as well as most of the DLC theme packs are licensed only for use if the game is published as an RPG Maker game. As most of the DLC packs that have this limitation don’t explicitly mention this until after you have bought/downloaded them, this is exceedingly annoying. While this deters people from jumping ship to a different tool, it also prevents people from using the tool. This is unfortunate as it would be a great prototyping tool even without proper export commands.
Conclusion
While I would not rule out using RPG Maker VX Pro as a prototyping tool, I would make sure I did so by making sure all the music and artwork used was my own (or licensed for use outside of RPG Maker). It is a really good tool but the resolution and lack of cross-platform capabilities makes it unsuitable for my needs. I am really hoping that a new version that addresses at least one of the above issues is released soon as I would quickly grab that tool.
The Good
I actually consider this to be a really good program that I would gladly use to develop games in if it were not for the items in the ugly section. Before I get to the ugly points, lets first look at where the program excels.
Map Editor
When you consider that RPGs consist of multiple maps it is important that you have a decent map editor. Thankfully the map editor is very nice. It is tile based with each map having a tile-set that the map is made of. Tile-sets are made up of one or more image files. It is possible to share images between tile-sets which can reduce the number of necessary image files.
My favorite feature of the map editor is smart tiles. These tiles work by looking at the surrounding tiles and choosing the appropriate tile. For example, let's say you were adding a 4x4 tile rug to a room. The corners and edges would become the appropriate border pattern while the centre four tiles are the mid-carpet image.
The map supports multiple layers. Essentially you have your floor/wall layer which various decoration tiles can be placed over top of. This allows you to have things such as walls that have pictures on them or tables and chairs in the middle of the room. Tiles have three states of enterability. They can be solid, appear over the player or appear under the player. Each tile can also have an event placed on it. Events can have their own sprite and have scripts attached to them. I will cover events in more detail in the scripting section.
Database
The database holds all the actors, classes, skills, weapons, armours, enemies, troops, states, tile sets, common events, system, and terms that the game uses. Editing these is what makes your game unique. There is a default starting database that is set up for your typical fantasy game. If you are not developing a fantasy game or want to create an original game then you will pretty much want to get rid of most of the stuff in the database and start from scratch.
Database pages generally give you a list of all the items in that category. The number of items in a category is set to a certain number of entries, but those can be changed to however many items you need. Each item then has a simple to fill out form making creating and editing items very simple.
Scripting
The power of any game engine is largely dependent on how good the scripting system is. There are two parts to this factor. The actual language(s) the engine supports and how much the API for the game lets the player control the engine.
Language-wise RPG Maker VX Ace uses the Ruby language. This is a very flexible and powerful language but not something easy for a first-time programmer to grasp. To allow non-programmers the ability to create scripts, the program also offers a menu-based scripting language. This is a fairly easy to use language where you assemble commands based on typical RPG actions and fill out dialog boxes with the details of what you want to do. There is enough actions that you can accomplish most game tasks.
For those going with Ruby, which I never did for First, you have access to an API that gives you access to pretty much everything you would want to do with the engine and even gives you access to the windows API giving you a lot of power if you absolutely need it.
The Bad
While this is a great tool, there are some rough edges.
Database dependencies
While the database is nice to use, there is one really annoying thing about it. Many categories of items depend on items in other categories. If you are creating an encounter in the troops tab, you need to make sure the monsters have already been created. The monsters need to have skills and items set, and so on. What I would have liked to have seen is the option to create a new required skill or item on the fly so that when creating something you are not jumping back and forth between tabs.
Packaging
I covered the packaging issue in my postmortem of my first RPG Maker game. The tool for creating a distributable package does not analyze your game for the assets that are actually used but instead includes all the files in the resource manager. This means you need to manually remove any items your game does not need otherwise it will be included in the distribution. If you are doing a total conversion, this may not be that bad as you can start by removing everything and only adding back what items you need but this is still a lot of work that could have easily been automated.
Documentation
The documentation that comes with the package is kind of sparse. It covers the basics of the tool and has an API reference for Ruby programmers. It has no tutorials on how to use the game nor any explanation of how the stats in the default database work. To find answers to these questions requires searching forums or delving into the ruby code and spending hours looking through the database to piece how things work. There are some really good RPG Maker VX Ace tutorials on the internet, which you really should go through before using the tool for the first time, but nothing with the package.
The Ugly
None of the bad items above are enough to deter most people from using the tool. I would too, but there are three issues that prevent me from doing so.
Resolution
The game resolution is really ancient. Anybody who has played a RPG Maker game probably has noticed the small window that the game is played in. While it is possible to get past this limitation by liberal use of Ruby scripting and Windows API calls, this would be a huge amount of work. I am hoping that if there is another version of RPG Maker released that it will at a minimum address this issue. Possibly by supporting different resolutions of tile-images though even the simple solution of scaling tiles would be sufficient for many people. If RPG Maker VX Ace had proper support for HD resolutions then I would probably be developing a commercial game in it right now despite the other two ugly items.
Windows only
Having used cross-platform languages for over a decade, I really don’t understand why developers still release tools that only create stuff that will run on Windows. Windows is such a large base that this is not an outright killer, but when combined with the resolution limitations makes it so for me. Minimally I would like to have the ability to export games to OSX and Linux. Ideally support for tables as well. Even if you had to pay extra for the ability to port to different platforms, this would be a great feature to have.
DLC Licensing
One thought that I had was to simply use RPG Maker as a prototyping tool and then find a way of exporting everything to another engine that overcame the resolution and platform limitations of the tool. Making this much more complicated is the fact that all the built-in graphics as well as most of the DLC theme packs are licensed only for use if the game is published as an RPG Maker game. As most of the DLC packs that have this limitation don’t explicitly mention this until after you have bought/downloaded them, this is exceedingly annoying. While this deters people from jumping ship to a different tool, it also prevents people from using the tool. This is unfortunate as it would be a great prototyping tool even without proper export commands.
Conclusion
While I would not rule out using RPG Maker VX Pro as a prototyping tool, I would make sure I did so by making sure all the music and artwork used was my own (or licensed for use outside of RPG Maker). It is a really good tool but the resolution and lack of cross-platform capabilities makes it unsuitable for my needs. I am really hoping that a new version that addresses at least one of the above issues is released soon as I would quickly grab that tool.
Friday, July 4, 2014
"First" postmortem
It is time for my Postmortem of the game that was recently released on Blazing Games. This game is called First as it is my first attempt at creating a game using RPG Maker VX Ace.
What Went Right
It is usually, if not always, wise to have a plan B. When the RPG Maker game competition was announced I knew I was going to attempt to create a game for it. A game that had a chance of winning would require a large time commitment so my plan if I was unable to finish was to forgo the contest and release my first RPG Maker game for July’s game. My first RPG Maker game was created months ago so it was ineligible for the contest. As the Blazing Games release for this month is my first RPG Maker project it is clear I never had enough time to finish the planned game. This was not a result of the game being over-ambitious but was a result of not having anywhere near the amount of spare time as expected. One thing you should always remember when scheduling projects is that unforeseen events (and for that matter, problems) will happen. In this case, the real game was roughed out but needed a lot of polishing before it could be considered a contender. With only a week before the competition deadline a decision on whether to reduce the amount of polish or go with my first RPG Maker project was in order. Had I known my Canada Day plans were going to be rained out, the choice would have been different.
The First game consisted of the player's home, the island map, and the Kobold cave. I quickly came up with a story, added the town and the related buildings, and modified the cave to fit the story. It is still a very simple game but still an entertaining fifteen minutes.
Mixed Blessings
RPG Maker VX Ace is actually a fairly nice tool. There is too much to discuss here so will discuss the tool next week. Using an existing engine saves you a lot of work at the cost of flexibility. While the scripting engine is very flexible and powerful, it is still a huge amount of work to create a game that is vastly different from the base game that the engine was designed for. This has the unfortunate result that many RPG Maker games feel the same. This problem is true of other game engines, such as Unity and Unreal, as well. If you want your game to stand out, a lot of effort is required even if you are using an existing engine.
What Went Wrong
The biggest issue with the game is the size of the zip file. The reason for this huge file is simply that RPG Maker includes all the files in the resource manager even if they are not being used. This means that in order to get a smaller distribution file you need to manually remove the files that aren't needed. As I had expected RPG Maker to do this for me, no time was allocated for this task. Making this task trickier is the fact that I have very little idea as to which files are needed. Once you have worked with RPG Maker for a while this will probably be less of an issue. Of course, it is also possible that there is a way to get RPG Maker to do this work for you but I simply didn’t figure out how to.
Next week I will go over my thoughts on the RPG Maker VX Ace tool.
What Went Right
It is usually, if not always, wise to have a plan B. When the RPG Maker game competition was announced I knew I was going to attempt to create a game for it. A game that had a chance of winning would require a large time commitment so my plan if I was unable to finish was to forgo the contest and release my first RPG Maker game for July’s game. My first RPG Maker game was created months ago so it was ineligible for the contest. As the Blazing Games release for this month is my first RPG Maker project it is clear I never had enough time to finish the planned game. This was not a result of the game being over-ambitious but was a result of not having anywhere near the amount of spare time as expected. One thing you should always remember when scheduling projects is that unforeseen events (and for that matter, problems) will happen. In this case, the real game was roughed out but needed a lot of polishing before it could be considered a contender. With only a week before the competition deadline a decision on whether to reduce the amount of polish or go with my first RPG Maker project was in order. Had I known my Canada Day plans were going to be rained out, the choice would have been different.
The First game consisted of the player's home, the island map, and the Kobold cave. I quickly came up with a story, added the town and the related buildings, and modified the cave to fit the story. It is still a very simple game but still an entertaining fifteen minutes.
Mixed Blessings
RPG Maker VX Ace is actually a fairly nice tool. There is too much to discuss here so will discuss the tool next week. Using an existing engine saves you a lot of work at the cost of flexibility. While the scripting engine is very flexible and powerful, it is still a huge amount of work to create a game that is vastly different from the base game that the engine was designed for. This has the unfortunate result that many RPG Maker games feel the same. This problem is true of other game engines, such as Unity and Unreal, as well. If you want your game to stand out, a lot of effort is required even if you are using an existing engine.
What Went Wrong
The biggest issue with the game is the size of the zip file. The reason for this huge file is simply that RPG Maker includes all the files in the resource manager even if they are not being used. This means that in order to get a smaller distribution file you need to manually remove the files that aren't needed. As I had expected RPG Maker to do this for me, no time was allocated for this task. Making this task trickier is the fact that I have very little idea as to which files are needed. Once you have worked with RPG Maker for a while this will probably be less of an issue. Of course, it is also possible that there is a way to get RPG Maker to do this work for you but I simply didn’t figure out how to.
Next week I will go over my thoughts on the RPG Maker VX Ace tool.
Friday, June 27, 2014
NES Controllers
The NES has serial ports for the controllers. The advantage of this is that it is possible to have different controllers and other peripherals. The downside is that you need to read the input one bit at a time. The serial ports are located at memory addresses $4016 and $4017. The order that the bits are read is dependent on the controller that is plugged in, but as most games use the normal NES controller, the bit order is A, B, Select, Start, Up, Down, Left, Right.
The controllers need to be told to send their state to the serial port. This is done by a method known as strobing a port. Essentially this is simply writing a 1 to the port you wish to read followed by a 0 to the port you want to read. You then read the port 8 times for a standard controller, possibly more for other controllers. The low order bit (1) is used to tell you the state of the button being read while the next bit (2) indicates if a controller is attached. Other bits may also have significance, but I have not been able to find any information on this.
It is possible to have controller reading routines that incorporate the logic as the bits are tested, but I prefer having the bits combined into a single byte that can then be tested using boolean operations. This is the code for the first controller, the second controller works the same except you use $4017 instead of $4016.
ReadController1:
; strobe the controllers so will send button bits
LDA #$01
STA $4016
LDA #$00
STA $4016
; now loop through buttons to build joystick value
; a,b,select,start,up,down,left,right
LDY #$00
LDX #$08
ReadController1_pollJoy1:
LDA $4016 ; read bit
AND #$01 ; check if set (button down)
BEQ ReadController1_adjustJoyBits
INY ; as bit 0 is 0 will set bit!
ReadController1_adjustJoyBits:
TYA
DEX ; loop through button bits
; done here so won't over-shift flagset
BEQ ReadController1_done
ASL A ; shift button flag bits over
TAY
JMP ReadController1_pollJoy1
ReadController1_done:
RTS
One potential problem with the controller is that it is possible for the sound chip to cause interference with the serial bits resulting in the wrong value. This is a fairly easy to solve problem. Simply read the controller until the value returned is the same as the previous read.
A couple of convenience functions that I like to have, which are handy to have for things such as title screens and other times where you need to wait for button presses, are WaitForButtonPress and WaitForButtonPressEnd. These simply wait for a button press or the end of a button press.
WaitForButtonPress:
JSR ReadController1
AND #$F0
BEQ WaitForButtonPress
RTS
WaitForButtonPressEnd:
JSR ReadController1
AND #$F0
BNE WaitForButtonPressEnd
RTS
I also wrote a function that displays what controller buttons are pressed but as this is fairly simple code, I am not including it here. If you are interested in the code, it is still part of the Trivia source code (NES Trivia included in the game zip file.) even though it is not actually used.
The next couple of weeks will take a look at my first RPG Maker VXAce game. First a postmortem of the game and then a look at my thoughts on RPG Maker and what I am hoping the next version of this tool would have to make it perfect for my needs (not that my wishes are likely to happen but you never know).
The controllers need to be told to send their state to the serial port. This is done by a method known as strobing a port. Essentially this is simply writing a 1 to the port you wish to read followed by a 0 to the port you want to read. You then read the port 8 times for a standard controller, possibly more for other controllers. The low order bit (1) is used to tell you the state of the button being read while the next bit (2) indicates if a controller is attached. Other bits may also have significance, but I have not been able to find any information on this.
It is possible to have controller reading routines that incorporate the logic as the bits are tested, but I prefer having the bits combined into a single byte that can then be tested using boolean operations. This is the code for the first controller, the second controller works the same except you use $4017 instead of $4016.
ReadController1:
; strobe the controllers so will send button bits
LDA #$01
STA $4016
LDA #$00
STA $4016
; now loop through buttons to build joystick value
; a,b,select,start,up,down,left,right
LDY #$00
LDX #$08
ReadController1_pollJoy1:
LDA $4016 ; read bit
AND #$01 ; check if set (button down)
BEQ ReadController1_adjustJoyBits
INY ; as bit 0 is 0 will set bit!
ReadController1_adjustJoyBits:
TYA
DEX ; loop through button bits
; done here so won't over-shift flagset
BEQ ReadController1_done
ASL A ; shift button flag bits over
TAY
JMP ReadController1_pollJoy1
ReadController1_done:
RTS
One potential problem with the controller is that it is possible for the sound chip to cause interference with the serial bits resulting in the wrong value. This is a fairly easy to solve problem. Simply read the controller until the value returned is the same as the previous read.
A couple of convenience functions that I like to have, which are handy to have for things such as title screens and other times where you need to wait for button presses, are WaitForButtonPress and WaitForButtonPressEnd. These simply wait for a button press or the end of a button press.
WaitForButtonPress:
JSR ReadController1
AND #$F0
BEQ WaitForButtonPress
RTS
WaitForButtonPressEnd:
JSR ReadController1
AND #$F0
BNE WaitForButtonPressEnd
RTS
I also wrote a function that displays what controller buttons are pressed but as this is fairly simple code, I am not including it here. If you are interested in the code, it is still part of the Trivia source code (NES Trivia included in the game zip file.) even though it is not actually used.
The next couple of weeks will take a look at my first RPG Maker VXAce game. First a postmortem of the game and then a look at my thoughts on RPG Maker and what I am hoping the next version of this tool would have to make it perfect for my needs (not that my wishes are likely to happen but you never know).
Saturday, June 21, 2014
NES String Utilities
There are a number of additional functions that may not be necessary but are nice to have if you are creating a text heavy game. One print-related function that I love to have, even if it is a very simple function, is a way of repeatedly printing an indicated character an indicated number of times. On the NES it is simply a matter of a loop sending the desired character to the PPU. Still, having it as a separate function will save a few bytes per use so it doesn't hurt to have as its own function.
PrintRepeatedChar:
STA $2007
DEX
BNE PrintRepeatedChar
RTS
If you are manipulating strings on the fly, something that will be used in the RPG that is my ultimate goal, appending characters and strings is handy. Appending a character simply requires that the terminating zero be replaced with the character to be appended and the byte after that character be replaced with a terminating zero. As this code is fairly similar to the AppendString function I will not bother showing the code here but feel free to look it up in the source file.
The AppendString function adds string pointed to by SOURCE_PTR to the end of the string pointed to by DEST_PTR. Note that DEST_PTR is modified in the process to set up a call to StrNCpy. Our first goal is to find end index of DEST_PTR which points to the string being appended.
AppendString:
LDY #0
AppendString_loop:
LDA [DEST_PTR],Y
BEQ AppendString_doAppend
INY
CPY #$FF
BEQ AppendString_done
JMP AppendString_loop
Once we know the length of the string we are appending we adjust the DEST_PTR to point to the end of the string. We can then simply call the StrNCpy function to finish. It is possible to save a few cycles by jumping to StrNCpy and taking advantage of its RTS but this is considered a bad practice that should only be used for optimizing.
AppendString_doAppend:
; index in TEMP so it can be used with math instructions
STY TEMP
; Subtract index from 0 so we know maximum number of characters that
; can be copied
LDA #0
SEC SBC TEMP
; This is placed in X for subsequent StrNCpy call
TAX
; Add index to DEST_PTR
LDA DEST_PTR
CLC
ADC TEMP
BCC AppendString_StrNCpy
INC DEST_PTR+1
AppendString_StrNCpy:
STA DEST_PTR ; now do the append via StrNCpy
JSR StrNCpy
AppendString_done:
RTS
SubStr copies the middle portion of an existing string into a new string. Creating a new string from the middle portion of an existing string is another handy function but is really just a call to StrNCpy with an adjusted SOURCE_PTR. This is fairly straightforward code so will not be included here but is in the source file.
Finally the library includes a StrLength function. As we have done something like this in the Append String function we really don't need to show the code here. The big difference is we use SOURCE_PTR instead of DEST_PTR.
Now we have an adequate string library for our upcoming projects. Before we can get to creating the trivia game we still have one NES topic to cover. Controller input.
PrintRepeatedChar:
STA $2007
DEX
BNE PrintRepeatedChar
RTS
If you are manipulating strings on the fly, something that will be used in the RPG that is my ultimate goal, appending characters and strings is handy. Appending a character simply requires that the terminating zero be replaced with the character to be appended and the byte after that character be replaced with a terminating zero. As this code is fairly similar to the AppendString function I will not bother showing the code here but feel free to look it up in the source file.
The AppendString function adds string pointed to by SOURCE_PTR to the end of the string pointed to by DEST_PTR. Note that DEST_PTR is modified in the process to set up a call to StrNCpy. Our first goal is to find end index of DEST_PTR which points to the string being appended.
AppendString:
LDY #0
AppendString_loop:
LDA [DEST_PTR],Y
BEQ AppendString_doAppend
INY
CPY #$FF
BEQ AppendString_done
JMP AppendString_loop
Once we know the length of the string we are appending we adjust the DEST_PTR to point to the end of the string. We can then simply call the StrNCpy function to finish. It is possible to save a few cycles by jumping to StrNCpy and taking advantage of its RTS but this is considered a bad practice that should only be used for optimizing.
AppendString_doAppend:
; index in TEMP so it can be used with math instructions
STY TEMP
; Subtract index from 0 so we know maximum number of characters that
; can be copied
LDA #0
SEC SBC TEMP
; This is placed in X for subsequent StrNCpy call
TAX
; Add index to DEST_PTR
LDA DEST_PTR
CLC
ADC TEMP
BCC AppendString_StrNCpy
INC DEST_PTR+1
AppendString_StrNCpy:
STA DEST_PTR ; now do the append via StrNCpy
JSR StrNCpy
AppendString_done:
RTS
SubStr copies the middle portion of an existing string into a new string. Creating a new string from the middle portion of an existing string is another handy function but is really just a call to StrNCpy with an adjusted SOURCE_PTR. This is fairly straightforward code so will not be included here but is in the source file.
Finally the library includes a StrLength function. As we have done something like this in the Append String function we really don't need to show the code here. The big difference is we use SOURCE_PTR instead of DEST_PTR.
Now we have an adequate string library for our upcoming projects. Before we can get to creating the trivia game we still have one NES topic to cover. Controller input.
Friday, June 13, 2014
StrNCpy and StrNCmp
Copying strings is pretty much just your regular memory copy operation with a couple of twists. First, we have no idea how many bytes need to be copied. Second, we need to make sure to write a zero at the end of the string so that the copied string will always be a valid string.
This function requires two pointers be set up. The SOURCE_PTR points to string to be copied while the DEST_PTR pointer where string is copied to. We also use the X Register to hold the maximum length of the string (including null terminator) to be copied, with a length of 0 being an entire page.
First we set the character to copy to zero. We then use zero page indirect addressing to load a character from the source string. If this character is a zero then the copying is done. Because our last action is always to write an ending zero, we can branch right to our ending code. If not a zero then we write the character to the destination location.
StrNCpy:
LDY #0
StrNCpy_loop:
LDA [SOURCE_PTR],Y
BEQ StrNCpy_done
STA [DEST_PTR],Y
The X Register is deducted to make sure the maximum copy length had not been reached. If it has been then we force an overwrite of the last character with a zero.
DEX
BEQ StrNCpy_lengthReached
INY
JMP StrNCpy_loop
StrNCpy_lengthReached:
LDA #0 ; Make sure last character a zero
StrNCpy_done:
STA [DEST_PTR],Y
RTS
String comparison is fairly similar which makes it a fairly costly operation. The longer the strings being compared the longer the operation will take. This is why it irks me when I see programmers use strings when integer constants could be used. This is thankfully not as bad a situation as it could be. Many string class libraries use hash values when comparing strings. This technique has the cost of computing a hash value, but if strings are immutable as they are in many modern languages then the hash value will only be computed once. While hash values result in a simple and fast integer comparison for non-matching strings, hashes are not unique so if a match is found then you still need to check each character to make sure the strings match.
We are not computing or checking hash values, but are checking if the source and destination pointers are the same. This takes a few cycles but can save a lot of work. This also lets us cheat by using string pointers as our integer constants for prompts and other text-based menus.
StrNCmp:
LDY #0
LDA SOURCE_PTR
CMP DEST_PTR
BNE StrNCmp_compareLoop
LDA SOURCE_PTR+1
CMP DEST_PTR+1
BNE StrNCmp_compareLoop
; If we reach here, same pointer so must match
LDA #0
RTS
The second phase is a byte by byte comparison of the strings. The logic here is pretty similar to the string copy except we are comparing instead of copying.
StrNCmp_compareLoop:
LDA [SOURCE_PTR],Y
BEQ StrNCmp_done
CMP [DEST_PTR],Y
BNE StrNCmp_done
DEX ; Make sure not comparing beyond limit
BEQ StrNCmp_done
INY ; Now set next byte and continue
JMP StrNCmp_compareLoop
Finally we determine the comparison result. We do this the same way the CMP instruction does by simply subtracting the compared byte from the source byte.
StrNCmp_done:
SEC
SBC [DEST_PTR],Y
RTS
That covers the most important parts of our string library but there are still a few functions that I want to write which will be covered next.
This function requires two pointers be set up. The SOURCE_PTR points to string to be copied while the DEST_PTR pointer where string is copied to. We also use the X Register to hold the maximum length of the string (including null terminator) to be copied, with a length of 0 being an entire page.
First we set the character to copy to zero. We then use zero page indirect addressing to load a character from the source string. If this character is a zero then the copying is done. Because our last action is always to write an ending zero, we can branch right to our ending code. If not a zero then we write the character to the destination location.
StrNCpy:
LDY #0
StrNCpy_loop:
LDA [SOURCE_PTR],Y
BEQ StrNCpy_done
STA [DEST_PTR],Y
The X Register is deducted to make sure the maximum copy length had not been reached. If it has been then we force an overwrite of the last character with a zero.
DEX
BEQ StrNCpy_lengthReached
INY
JMP StrNCpy_loop
StrNCpy_lengthReached:
LDA #0 ; Make sure last character a zero
StrNCpy_done:
STA [DEST_PTR],Y
RTS
String comparison is fairly similar which makes it a fairly costly operation. The longer the strings being compared the longer the operation will take. This is why it irks me when I see programmers use strings when integer constants could be used. This is thankfully not as bad a situation as it could be. Many string class libraries use hash values when comparing strings. This technique has the cost of computing a hash value, but if strings are immutable as they are in many modern languages then the hash value will only be computed once. While hash values result in a simple and fast integer comparison for non-matching strings, hashes are not unique so if a match is found then you still need to check each character to make sure the strings match.
We are not computing or checking hash values, but are checking if the source and destination pointers are the same. This takes a few cycles but can save a lot of work. This also lets us cheat by using string pointers as our integer constants for prompts and other text-based menus.
StrNCmp:
LDY #0
LDA SOURCE_PTR
CMP DEST_PTR
BNE StrNCmp_compareLoop
LDA SOURCE_PTR+1
CMP DEST_PTR+1
BNE StrNCmp_compareLoop
; If we reach here, same pointer so must match
LDA #0
RTS
The second phase is a byte by byte comparison of the strings. The logic here is pretty similar to the string copy except we are comparing instead of copying.
StrNCmp_compareLoop:
LDA [SOURCE_PTR],Y
BEQ StrNCmp_done
CMP [DEST_PTR],Y
BNE StrNCmp_done
DEX ; Make sure not comparing beyond limit
BEQ StrNCmp_done
INY ; Now set next byte and continue
JMP StrNCmp_compareLoop
Finally we determine the comparison result. We do this the same way the CMP instruction does by simply subtracting the compared byte from the source byte.
StrNCmp_done:
SEC
SBC [DEST_PTR],Y
RTS
That covers the most important parts of our string library but there are still a few functions that I want to write which will be covered next.
Friday, June 6, 2014
NES Printing Strings
The whole purpose of having strings is to be able to display them. The print string function should support multiple screens and allow the location of the text to be specified. Because setting the PPU address to a screen location is handy to have even if we aren't writing a string, the SetScreenXY function will be created first. It will be called using the x / y registers to hold the x / y coordinates and the accumulator holding the quadrant of the screen to draw the text to.
The first thing the function does is multiplies the quadrant by 4 then adding the high byte of quadrant 0 to this. This is the equivalent of base_address = 1024 + quadrant_base. Next we want to multiply Y by 32 and add it to this address. I take advantage of the fact that the result of this multiplication would result in the upper 5 bits of Y being added to the high order byte so a tiny bit of bit manipulation saves a lot of looping logic. Finally, as we know the lower 5 bits of the low-order byte are clear, we can simply OR the X value with the PPU address. This may seem complicated, but looking at the code should help.
SetScreenXY:
; Calculate PPU Address for screen quadrant
ASL A
ASL A
CLC
ADC #$20
STA PPU_HIGH
; Add high portion of 32*y to high PPU address
TYA
LSR A
LSR A
LSR A
CLC
ADC PPU_HIGH
STA PPU_HIGH
; Calculate low byte of y * 32
TYA
; AND #$07 not necessary as 0 is always shifted in
ASL A
ASL A
ASL A
ASL A
ASL A
; add X to it
STA PPU_LOW
TXA
ORA PPU_LOW
STA PPU_LOW
LDA $2002 ; read PPU status to reset the high/low latch
LDA PPU_HIGH
STA $2006 ; write the high byte of screen address
LDA PPU_LOW
STA $2006 ; write the low byte of screen address
RTS
The PrintString function uses the SOURCE_PTR to hold the string to print, which it prints at the current PPU address. This means that SetScreenXY should be called before printing. Concurrent calls to PrintString will continue printing where the last call left off. The cursor position is not tracked, though if you needed this functionality it would be fairly easy to add. This is not something I will need so the printing functions are being kept to their simplest form. This function is a loop that prints characters until either 256 characters are printed or a zero character is reached. The length-checking code is free as a JMP would be needed if the BNE wasn't used.
PrintString:
LDY #0
PrintString_loop:
LDA [SOURCE_PTR],Y
BEQ PrintString_done
STA $2007
INY
BEQ PrintString_done
JMP PrintString_loop
PrintString_done:
RTS
The problem with these functions is that there a bunch of code required to set up the parameters. Wouldn't it be great if we could call a function like this: "CallPrintStringAt labelOfString, x,y,screenQuardrant"? This is what macros are for. Different assemblers will have different ways of setting up macros. This is the way it is done in NESAsm:
CallPrintStringAt .macro
LDA #LOW(\1)
STA SOURCE_PTR
LDA #HIGH(\1)
STA SOURCE_PTR+1
LDX #\2
LDY #\3
LDA #\4
JSR SetScreenXY
JSR PrintString
.endm
The \# sections are the parameters. The code is inserted as shown with the parameters being pasted as they are into the macro. For complicated functions that require setting up multiple registers and variables, macros can save a lot of time. They can also make code easier to read. It is important to remember that the code for the macro is inserted into the program every time the macro is used so it is not a substitute for functions. But they certainly make calling functions easier. The downside to macros is that the code is just pasted as is so some optimizations that could be done (such as if you know a register or memory address is already correct) are not.
Printing works great except for one problem. Color. As was explained in earlier posts, setting attributes is kind of complicated and colors are set for 2x2 blocks. The ClearScreen function sets the attributes. We will not cover the ClearScreen function as we have written similar code for HelloNES and HelloSprites already. Next we will be looking at string copying and comparisons which will include a bit of a rant.
The first thing the function does is multiplies the quadrant by 4 then adding the high byte of quadrant 0 to this. This is the equivalent of base_address = 1024 + quadrant_base. Next we want to multiply Y by 32 and add it to this address. I take advantage of the fact that the result of this multiplication would result in the upper 5 bits of Y being added to the high order byte so a tiny bit of bit manipulation saves a lot of looping logic. Finally, as we know the lower 5 bits of the low-order byte are clear, we can simply OR the X value with the PPU address. This may seem complicated, but looking at the code should help.
SetScreenXY:
; Calculate PPU Address for screen quadrant
ASL A
ASL A
CLC
ADC #$20
STA PPU_HIGH
; Add high portion of 32*y to high PPU address
TYA
LSR A
LSR A
LSR A
CLC
ADC PPU_HIGH
STA PPU_HIGH
; Calculate low byte of y * 32
TYA
; AND #$07 not necessary as 0 is always shifted in
ASL A
ASL A
ASL A
ASL A
ASL A
; add X to it
STA PPU_LOW
TXA
ORA PPU_LOW
STA PPU_LOW
LDA $2002 ; read PPU status to reset the high/low latch
LDA PPU_HIGH
STA $2006 ; write the high byte of screen address
LDA PPU_LOW
STA $2006 ; write the low byte of screen address
RTS
The PrintString function uses the SOURCE_PTR to hold the string to print, which it prints at the current PPU address. This means that SetScreenXY should be called before printing. Concurrent calls to PrintString will continue printing where the last call left off. The cursor position is not tracked, though if you needed this functionality it would be fairly easy to add. This is not something I will need so the printing functions are being kept to their simplest form. This function is a loop that prints characters until either 256 characters are printed or a zero character is reached. The length-checking code is free as a JMP would be needed if the BNE wasn't used.
PrintString:
LDY #0
PrintString_loop:
LDA [SOURCE_PTR],Y
BEQ PrintString_done
STA $2007
INY
BEQ PrintString_done
JMP PrintString_loop
PrintString_done:
RTS
The problem with these functions is that there a bunch of code required to set up the parameters. Wouldn't it be great if we could call a function like this: "CallPrintStringAt labelOfString, x,y,screenQuardrant"? This is what macros are for. Different assemblers will have different ways of setting up macros. This is the way it is done in NESAsm:
CallPrintStringAt .macro
LDA #LOW(\1)
STA SOURCE_PTR
LDA #HIGH(\1)
STA SOURCE_PTR+1
LDX #\2
LDY #\3
LDA #\4
JSR SetScreenXY
JSR PrintString
.endm
The \# sections are the parameters. The code is inserted as shown with the parameters being pasted as they are into the macro. For complicated functions that require setting up multiple registers and variables, macros can save a lot of time. They can also make code easier to read. It is important to remember that the code for the macro is inserted into the program every time the macro is used so it is not a substitute for functions. But they certainly make calling functions easier. The downside to macros is that the code is just pasted as is so some optimizations that could be done (such as if you know a register or memory address is already correct) are not.
Printing works great except for one problem. Color. As was explained in earlier posts, setting attributes is kind of complicated and colors are set for 2x2 blocks. The ClearScreen function sets the attributes. We will not cover the ClearScreen function as we have written similar code for HelloNES and HelloSprites already. Next we will be looking at string copying and comparisons which will include a bit of a rant.
Saturday, May 31, 2014
NES Trivia Postmortem
For my Blazing Games June game I am releasing my NES Trivia game even though I have not yet quite got to it in the blog. See the what went wrong section for the reason for this. Needless to say, here is the postmortem.
What Went Right
The string library that was developed for general purpose use worked really well. Especially when the macros were used. Lots of the display-related code is very easy to understand thanks to the use of the PrintStringAt macro. While the StrNCmp function was never used in the game, it will be used in the sequel so the code was not wasted, just slightly premature.
Mixed Blessings
The whole reason for this game was to actually create a simple game fairly early in the series. As it turned out, there was a lot more foundation work that I had to write about before I could get to the meat and have a real game. Even at this point there are things that could be improved. The biggest being randomness. Right after that (before that for many people) is sound. Filling up the extra ROM space with questions and touching up the display finish off my list.
What Went Wrong
This was not the game I was planning on releasing for June. I was going to hold off releasing the game until we actually started creating the game in this blog. Unfortunately, the game I was hoping to release for June simply was too large for the amount of time I had available (and my Dad going into the hospital for a hernia operation didn't help). Using this game as filler material was my only option. Sadly the game I was developing is going to be delayed by at least a month as there is a big RPG Maker contest in June. While I suspect there are people who are far more knowledgable about RPG Maker that will probably win, there are real prizes for this challenge and I did want to try out the tool so this will be my June project. If the resulting game got enough interest, and especially if it won money, I would probably shift my focus to developing a full version of that game.
What Went Right
The string library that was developed for general purpose use worked really well. Especially when the macros were used. Lots of the display-related code is very easy to understand thanks to the use of the PrintStringAt macro. While the StrNCmp function was never used in the game, it will be used in the sequel so the code was not wasted, just slightly premature.
Mixed Blessings
The whole reason for this game was to actually create a simple game fairly early in the series. As it turned out, there was a lot more foundation work that I had to write about before I could get to the meat and have a real game. Even at this point there are things that could be improved. The biggest being randomness. Right after that (before that for many people) is sound. Filling up the extra ROM space with questions and touching up the display finish off my list.
What Went Wrong
This was not the game I was planning on releasing for June. I was going to hold off releasing the game until we actually started creating the game in this blog. Unfortunately, the game I was hoping to release for June simply was too large for the amount of time I had available (and my Dad going into the hospital for a hernia operation didn't help). Using this game as filler material was my only option. Sadly the game I was developing is going to be delayed by at least a month as there is a big RPG Maker contest in June. While I suspect there are people who are far more knowledgable about RPG Maker that will probably win, there are real prizes for this challenge and I did want to try out the tool so this will be my June project. If the resulting game got enough interest, and especially if it won money, I would probably shift my focus to developing a full version of that game.
Friday, May 23, 2014
String Theory
While I do have an interest in theoretical physics, this column is not about that. When it comes to programming, strings are taken for granted. Pretty much every language comes with a comprehensive string library. In modern-day programming, it really is not necessary to write a string library. After all, most string libraries are really well written so there is nothing to be gained from writing your own.
When it comes to early game consoles, however, writing your own library may make sense. Early consoles don't have that much memory so you only want functionality that is actually required. It is certainly possible to find general purpose 6502 string libraries, but basic strings are simple enough that it is fairly easy to write a few routines for dealing with them.
Ultimately strings are simply arrays of characters. The type of characters is based on the platform. For the NES, we use bytes that indicate which pattern table character to display. This does not have to correspond to ASCII, but my pattern tables tend to at least partially incorporate the ASCII character set. For modern string libraries unicode may be used,quite possibly using UTF-8 formatting. There are numerous ways of implementing strings. The three most common methods are fixed length, Pascal-style and C-style strings.
Fixed length strings have a set length with any unused characters being spaces or null characters. This technique is often used with databases to help ensure that every row of the database table is the same length as that makes manipulating the database much more efficient. As the length of the string is known, no additional information about the string is needed, though if you are going to be frequently comparing strings you may want to keep a hash-value. The downside to this method of representing strings is that every string must be at least the length of the longest allowed string so this method is not memory efficient.
Many dialects of the Pascal language represent strings by having the first byte be the length of the string followed by the array of characters. This length variable didn't need to be a byte so later versions of this method would use 16 or 32-bit integers for the length. Variable-length strings were more efficient, and dealing with the length is simple enough but as nice as Pascal was as a programming language, the C language and it's numerous variants would dominate programming and C had a different method of handling strings.
C-style strings, also known as null-terminating strings, simply continue until a 0 is reached. The lack of an explicit length has resulted in buffer-overflow bugs that still haunt us today. The idea here is that if a string is larger than the size allocated for the string, copying the string will result in data beyond the allocated size of the string being overwritten. This can result in data corruption or worse. If you are writing in C, strncpy should always be used in place of strcpy.
As memory is at a premium, the choice of string format for my home-brew projects really comes down to a choice between C strings and Pascal strings. As C strings are more common, that is the format that will be used. String copy, compare, concatenation and some printing functions should be sufficient for our needs.
When it comes to early game consoles, however, writing your own library may make sense. Early consoles don't have that much memory so you only want functionality that is actually required. It is certainly possible to find general purpose 6502 string libraries, but basic strings are simple enough that it is fairly easy to write a few routines for dealing with them.
Ultimately strings are simply arrays of characters. The type of characters is based on the platform. For the NES, we use bytes that indicate which pattern table character to display. This does not have to correspond to ASCII, but my pattern tables tend to at least partially incorporate the ASCII character set. For modern string libraries unicode may be used,quite possibly using UTF-8 formatting. There are numerous ways of implementing strings. The three most common methods are fixed length, Pascal-style and C-style strings.
Fixed length strings have a set length with any unused characters being spaces or null characters. This technique is often used with databases to help ensure that every row of the database table is the same length as that makes manipulating the database much more efficient. As the length of the string is known, no additional information about the string is needed, though if you are going to be frequently comparing strings you may want to keep a hash-value. The downside to this method of representing strings is that every string must be at least the length of the longest allowed string so this method is not memory efficient.
Many dialects of the Pascal language represent strings by having the first byte be the length of the string followed by the array of characters. This length variable didn't need to be a byte so later versions of this method would use 16 or 32-bit integers for the length. Variable-length strings were more efficient, and dealing with the length is simple enough but as nice as Pascal was as a programming language, the C language and it's numerous variants would dominate programming and C had a different method of handling strings.
C-style strings, also known as null-terminating strings, simply continue until a 0 is reached. The lack of an explicit length has resulted in buffer-overflow bugs that still haunt us today. The idea here is that if a string is larger than the size allocated for the string, copying the string will result in data beyond the allocated size of the string being overwritten. This can result in data corruption or worse. If you are writing in C, strncpy should always be used in place of strcpy.
As memory is at a premium, the choice of string format for my home-brew projects really comes down to a choice between C strings and Pascal strings. As C strings are more common, that is the format that will be used. String copy, compare, concatenation and some printing functions should be sufficient for our needs.
Friday, May 16, 2014
6502 Pointers
Pointers are one of those programming subjects that tend to confuse people yet once understood is really fairly simple. If you have been following my NES series of articles, the following code is probably easy to understand:
LDY #0
CopySpriteData:
LDA SpriteData,Y
STA $200,Y
INY
BEQ CopySpriteData
RTS
SpriteData:
; 256 bytes of sprite data go here
This code simply copies 256 bytes of data from SpriteData to the second page of 6502 memory. The fact that when a byte overflows it wraps around and becomes 0 again is used to terminate the loop. This code seems easy enough. The LDA instruction is using the address SpriteData is at, then adding the Y register to that value to come up with the memory address to grab the byte being copied from. Likewise, the STA is using the memory address $200 and adding the Y register to it to find the address to store the byte.
Pointers work pretty much the same way but instead of directly using an address, the address is stored in a pair of zero page addresses. Why would you want to do this? By having pointers to addresses instead of hard-coding the address you can create general-purpose functions. The caller would simply fill in the pointer with the address the function is suppose to use then call the function. The 6502 expects addresses to be written in a low to high format meaning the low-order byte is followed by the high-order byte. This is known as little-endian format. For NES developers this can be confusing as the PPU uses high/low (big-endian) for specifying addresses. To demonstrate pointers, here is a simple MemCpy function.
MemCpy:
LDY #0
MemCpy_loop:
LDA [SOURCE_PTR],Y
STA [DEST_PTR],Y
INY
CPY COPY_LENGTH
BNE MemCpy_loop
RTS
The Y register is zeroed out before the loop. The byte at the address pointed to in SOURCE_PTR offset by Y is loaded into the accumulator. This value is then stored at the address pointed to by DEST_PTR offset by Y. The Y offset is increased and the loop continues until Y is equal to the value in COPY_LENGTH.
This works, but the amount of effort required to set up the zero-page pointer variables requires more instructions than the actual function. A more complex function, such as a MemCpy function that supported 16-bit copy-lengths would be worth doing. Likewise, when you are dealing with addresses that you may not know beforehand, such as will be the case with the general-purpose prompt routines we will be developing, using pointers to data is incredibly handy.
The use of pointers is something that will be used quite a bit as we progress. Our Trivia game will be needing strings and some type of way of selecting a choice so that is what we will be focusing on next.
LDY #0
CopySpriteData:
LDA SpriteData,Y
STA $200,Y
INY
BEQ CopySpriteData
RTS
SpriteData:
; 256 bytes of sprite data go here
This code simply copies 256 bytes of data from SpriteData to the second page of 6502 memory. The fact that when a byte overflows it wraps around and becomes 0 again is used to terminate the loop. This code seems easy enough. The LDA instruction is using the address SpriteData is at, then adding the Y register to that value to come up with the memory address to grab the byte being copied from. Likewise, the STA is using the memory address $200 and adding the Y register to it to find the address to store the byte.
Pointers work pretty much the same way but instead of directly using an address, the address is stored in a pair of zero page addresses. Why would you want to do this? By having pointers to addresses instead of hard-coding the address you can create general-purpose functions. The caller would simply fill in the pointer with the address the function is suppose to use then call the function. The 6502 expects addresses to be written in a low to high format meaning the low-order byte is followed by the high-order byte. This is known as little-endian format. For NES developers this can be confusing as the PPU uses high/low (big-endian) for specifying addresses. To demonstrate pointers, here is a simple MemCpy function.
MemCpy:
LDY #0
MemCpy_loop:
LDA [SOURCE_PTR],Y
STA [DEST_PTR],Y
INY
CPY COPY_LENGTH
BNE MemCpy_loop
RTS
The Y register is zeroed out before the loop. The byte at the address pointed to in SOURCE_PTR offset by Y is loaded into the accumulator. This value is then stored at the address pointed to by DEST_PTR offset by Y. The Y offset is increased and the loop continues until Y is equal to the value in COPY_LENGTH.
This works, but the amount of effort required to set up the zero-page pointer variables requires more instructions than the actual function. A more complex function, such as a MemCpy function that supported 16-bit copy-lengths would be worth doing. Likewise, when you are dealing with addresses that you may not know beforehand, such as will be the case with the general-purpose prompt routines we will be developing, using pointers to data is incredibly handy.
The use of pointers is something that will be used quite a bit as we progress. Our Trivia game will be needing strings and some type of way of selecting a choice so that is what we will be focusing on next.
Saturday, May 10, 2014
NES Hello Sprites 2
NES programs will often clone sprite memory in RAM to allow for DMA transfers. DMA, which stands for Direct Memory Access, is a rapid way of transferring blocks of memory to hardware. When a DMA transfer happens, the processor is temporarily halted while the memory is rapidly copied into PPU memory. While this still takes time, it is much faster than manually copying sprites. If you have a large number of sprites, it is far better to use DMA than to manually copy sprites.
Another convenience that the NES provides programmers is a VBlank Non-Maskable Interrupt (NMI). Interrupts cause the processor to stop what it is doing and immediately start running the subroutine pointed to by the interrupt vector. There are two types of interrupts. Your regular interrupts, or IRQs, can be disabled by the SEI instruction and enabled by the CLI instruction. NMIs are not affected by those instructions so will always occur. The PPU control register, however, does allow the VBlank to be disabled.
The advantage of using interrupts is that you do not have to worry about polling for the VBlank so you can process other game logic while the PPU is drawing the screen without having to worry about missing this important period. In this second sprite demo, all of our logic will be done in the interrupt handler, though this certainly does not have to be the case and in later projects we will be developing a state machine to handle complex processing.
The code for the second version of our sprite demo is very similar to the original version with only a few changes needed to support interrupts and DMA. Instead of copying the sprite data directly to the PPUs sprite memory, it is copied to a page of RAM. VBlank interrupts are enabled just before the radically changed main loop as follows:
LDA #%10000000 ; enable NMI
STA $2000
MainGameLoop:
NOP ; Right now we do nothing in the main loop.
JMP MainGameLoop
NMI:
LDA #2
STA $4014
JSR MoveSprites
RTI
Another convenience that the NES provides programmers is a VBlank Non-Maskable Interrupt (NMI). Interrupts cause the processor to stop what it is doing and immediately start running the subroutine pointed to by the interrupt vector. There are two types of interrupts. Your regular interrupts, or IRQs, can be disabled by the SEI instruction and enabled by the CLI instruction. NMIs are not affected by those instructions so will always occur. The PPU control register, however, does allow the VBlank to be disabled.
The advantage of using interrupts is that you do not have to worry about polling for the VBlank so you can process other game logic while the PPU is drawing the screen without having to worry about missing this important period. In this second sprite demo, all of our logic will be done in the interrupt handler, though this certainly does not have to be the case and in later projects we will be developing a state machine to handle complex processing.
The code for the second version of our sprite demo is very similar to the original version with only a few changes needed to support interrupts and DMA. Instead of copying the sprite data directly to the PPUs sprite memory, it is copied to a page of RAM. VBlank interrupts are enabled just before the radically changed main loop as follows:
LDA #%10000000 ; enable NMI
STA $2000
MainGameLoop:
NOP ; Right now we do nothing in the main loop.
JMP MainGameLoop
Yes, absolutely nothing is done in the main loop. Instead all work is done in the Interrupt. While the NOP instruction is not necessary, I have heard urban legends about loops causing hardware to catch fire. I find this highly suspect but spreading the loop over an extra instruction does give me an excuse to use my favorite 6502 instruction. The real logic happens in the Non-maskable interrupt routine. Though thanks to DMA hardware this is much simpler than the manual method of transferring sprite information.
LDA #2
STA $4014
JSR MoveSprites
RTI
As you can see, DMA is very simple to use. You just store the page of memory you want to transfer to the PPU into $4014. The move sprites function is almost identical except it stores sprite positions to RAM instead of writing directly to the PPUs sprite memory which has the added benefit of being more compatible with emulators (always a benefit for home-brew games).
Subscribe to:
Posts (Atom)
