It might also help to list things in the game loop that need to come before or after drawscreen.
Has anyone already created a list like this?
Thanks.
Edited by Random Terrain, Mon Mar 17, 2008 1:16 PM.
1
Has anyone made a list of commands that must go in the game loop?
Started by Random Terrain, Mar 17 2008 12:03 PM
8 replies to this topic
#1 OFFLINE
Random Terrain
-
-
- 20,910 posts
Visual batari Basic User
-
Controlled Randomness
Replay Value
Nonlinear - Location:North Carolina (USA)
Posted Mon Mar 17, 2008 12:03 PM
Seems like a good thing to add to the bB page would be a list of commands and related things that must be in the game loop. The multisprite kernel might have a different list, so two lists might be needed.
It might also help to list things in the game loop that need to come before or after drawscreen.
Has anyone already created a list like this?
Thanks.
It might also help to list things in the game loop that need to come before or after drawscreen.
Has anyone already created a list like this?
Thanks.
#2 OFFLINE
MausGames
-
-
- 851 posts
Dragonstomper
- Location:MO, USA
Posted Mon Mar 17, 2008 7:29 PM
I second that, there are far too many to expect everyone to learn through trial and error. I've never taken the time to compile that list, but hopefully someone has.
As far as before/after drawnscreen, that is irrelevant. Any code can go before or after drawscreen, depending on the programmers preference. All variables but the "temp"s hold their value through drawscreen, so your main drawscreen loop really is a "loop". So technically, virtually all of your code executes before drawscreen comes back around.
Can't wait until you start posting some code/bins RT.
As far as before/after drawnscreen, that is irrelevant. Any code can go before or after drawscreen, depending on the programmers preference. All variables but the "temp"s hold their value through drawscreen, so your main drawscreen loop really is a "loop". So technically, virtually all of your code executes before drawscreen comes back around.
Can't wait until you start posting some code/bins RT.
#3 OFFLINE
Random Terrain
-
-
- 20,910 posts
Visual batari Basic User
-
Controlled Randomness
Replay Value
Nonlinear - Location:North Carolina (USA)
Posted Mon Mar 17, 2008 8:47 PM
MausGames, on Mon Mar 17, 2008 9:29 PM, said:
I second that, there are far too many to expect everyone to learn through trial and error. I've never taken the time to compile that list, but hopefully someone has.
MausGames, on Mon Mar 17, 2008 9:29 PM, said:
As far as before/after drawnscreen, that is irrelevant. Any code can go before or after drawscreen, depending on the programmers preference. All variables but the "temp"s hold their value through drawscreen, so your main drawscreen loop really is a "loop". So technically, virtually all of your code executes before drawscreen comes back around.
MausGames, on Mon Mar 17, 2008 9:29 PM, said:
Can't wait until you start posting some code/bins RT.
#4 OFFLINE
batari
-
-
- 6,236 posts
)66]U('=I;B$*
- begin 644 contest
Posted Mon Mar 17, 2008 9:38 PM
There is a short list of TIA regs that may or may not need to be written every frame in the "ephemeral registers" section. Not all of them need to be changed if their values are the same as shown in the table.
#5 OFFLINE
SeaGtGruff
-
-
- 4,543 posts
River Patroller
- Location:Georgia, USA
Posted Mon Mar 17, 2008 10:11 PM
Your question is a little tricky to answer, because it depends on what you mean by "in the game loop." For example, if you check the joystick each time you go through the game loop, and if pressing the button on the joystick makes the program jump to a subroutine that does something-- like fire a missile-- then, technically, the subroutine to fire the missile is in the game loop, because it's being called from within the game loop.
In fact, you could argue that the only things that *aren't* in the game loop are any statements that are performed at the very beginning of the game, before the program ever falls into the game loop, or any statements that are performed when the game is over, after the program exits the game loop-- except that, in reality, you can't "exit to the operating system" when the game is over (since there *is* no operating system), and most games let you restart the program without having to power off and then power back on. Thus, the entire program is actually "in the game loop," except for any statements that get executed on power-up and then are never executed again, even when the game is restarted with a "warm reset." In other words, just about the entire program is one big loop, although it's usually divided up into several smaller loops.
However, I think what you're asking about are statements that need to be performed each time you go through a display loop, because if you don't perform them every time, they will "lose their settings" after the screen has been displayed. In batari Basic, there are very few statements that fall into that category. Basically, you're looking at any memory locations-- TIA registers, RIOT registers, or RAM variables-- whose values get wiped out by the kernel, and which can't be restored automatically by batari Basic. And these memory locations aren't "statements"; they're just locations that get set using an assignment or "let" statement.
Just about every piece of data that batari Basic needs to draw the screen is stored in RAM or ROM, therefore it can be restored automatically by batari Basic each time a display loop is performed. For example, when you define the playfield's shape-- which playfield pixels are on, and which are off-- either the shape data is stored in a table at a predetermined area in RAM, or else a pair of lo/hi pointers in RAM are set to the address where the playfield shape data resides in ROM. This means that once the RAM table or RAM pointers have been set, batari Basic can keep redrawing the playfield each time it goes through the display loop, without you needing to keep redefining the playfield inside the display loop. In other words, you don't need to do this:
On the other hand, batari Basic doesn't have RAM variables for the four color registers (the background, playfield, player0, and player1 colors), although it does have a RAM variable for the score color, and sometimes for other colors-- depending on the kernel and kernel options selected (standard vs. multisprite, and the options for multicolored players or playfield, or other special color options). So as long as the kernel doesn't change one of the color registers, you can set it outside the display loop, and it will keep its setting.
In the standard kernel, if you aren't using any of the multicolor options, or any other special color options, the background and playfield colors will keep their values once you set them, so you can set them outside the display kernel. But since the score is drawn with the two players, and the score color can be set, the kernel will wipe out any values you write to the two player color registers, hence you must set the two player colors inside the display loop or they'll get changed to the score's color as soon as the kernel draws the score.
On the other hand, the multisprite kernel uses player1 to draw player2 through player5, and it needs to know which colors to draw them in, so it has RAM variables for the colors of player1 through player5. That means you don't need to set those colors inside the display kernel-- although you *do* still need to set player0's color inside the display loop.
Other player-related registers that get wiped out by the score display include NUSIZ0, NUSIZ1, REFP0, and REFP1, so if you want to set them to specific values, then you'll need to do so inside the display kernel.
The online help manual does contain a discussion and an incomplete listing of these variables-- see the link to "Ephemeral Variables & Registers" in the list of topics in the upper right section of the online manual.
Michael
In fact, you could argue that the only things that *aren't* in the game loop are any statements that are performed at the very beginning of the game, before the program ever falls into the game loop, or any statements that are performed when the game is over, after the program exits the game loop-- except that, in reality, you can't "exit to the operating system" when the game is over (since there *is* no operating system), and most games let you restart the program without having to power off and then power back on. Thus, the entire program is actually "in the game loop," except for any statements that get executed on power-up and then are never executed again, even when the game is restarted with a "warm reset." In other words, just about the entire program is one big loop, although it's usually divided up into several smaller loops.
However, I think what you're asking about are statements that need to be performed each time you go through a display loop, because if you don't perform them every time, they will "lose their settings" after the screen has been displayed. In batari Basic, there are very few statements that fall into that category. Basically, you're looking at any memory locations-- TIA registers, RIOT registers, or RAM variables-- whose values get wiped out by the kernel, and which can't be restored automatically by batari Basic. And these memory locations aren't "statements"; they're just locations that get set using an assignment or "let" statement.
Just about every piece of data that batari Basic needs to draw the screen is stored in RAM or ROM, therefore it can be restored automatically by batari Basic each time a display loop is performed. For example, when you define the playfield's shape-- which playfield pixels are on, and which are off-- either the shape data is stored in a table at a predetermined area in RAM, or else a pair of lo/hi pointers in RAM are set to the address where the playfield shape data resides in ROM. This means that once the RAM table or RAM pointers have been set, batari Basic can keep redrawing the playfield each time it goes through the display loop, without you needing to keep redefining the playfield inside the display loop. In other words, you don't need to do this:
loop playfield: X....................X.......... ..X................X............ ....X............X.............. ......X........X................ ........X....X.................. ..........XX.................... ..........XX.................... ........X....X.................. ......X........X................ ....X............X.............. ..X................X............ X....................X.......... end drawscreen goto loopbecause you can do this instead:
playfield: X....................X.......... ..X................X............ ....X............X.............. ......X........X................ ........X....X.................. ..........XX.................... ..........XX.................... ........X....X.................. ......X........X................ ....X............X.............. ..X................X............ X....................X.......... end loop drawscreen goto loopLikewise, you can define the shapes of player0 and player1 outside the display loop, because batari Basic has RAM pointers to tell it where the player shapes are in ROM. You can also set the (x,y) coordinates of the sprites outside the display loop, because they're stored in RAM variables and don't get wiped out by the kernel.
On the other hand, batari Basic doesn't have RAM variables for the four color registers (the background, playfield, player0, and player1 colors), although it does have a RAM variable for the score color, and sometimes for other colors-- depending on the kernel and kernel options selected (standard vs. multisprite, and the options for multicolored players or playfield, or other special color options). So as long as the kernel doesn't change one of the color registers, you can set it outside the display loop, and it will keep its setting.
In the standard kernel, if you aren't using any of the multicolor options, or any other special color options, the background and playfield colors will keep their values once you set them, so you can set them outside the display kernel. But since the score is drawn with the two players, and the score color can be set, the kernel will wipe out any values you write to the two player color registers, hence you must set the two player colors inside the display loop or they'll get changed to the score's color as soon as the kernel draws the score.
On the other hand, the multisprite kernel uses player1 to draw player2 through player5, and it needs to know which colors to draw them in, so it has RAM variables for the colors of player1 through player5. That means you don't need to set those colors inside the display kernel-- although you *do* still need to set player0's color inside the display loop.
Other player-related registers that get wiped out by the score display include NUSIZ0, NUSIZ1, REFP0, and REFP1, so if you want to set them to specific values, then you'll need to do so inside the display kernel.
The online help manual does contain a discussion and an incomplete listing of these variables-- see the link to "Ephemeral Variables & Registers" in the list of topics in the upper right section of the online manual.
Michael
#6 OFFLINE
Random Terrain
-
-
- 20,910 posts
Visual batari Basic User
-
Controlled Randomness
Replay Value
Nonlinear - Location:North Carolina (USA)
Posted Tue Mar 18, 2008 1:30 AM
batari, on Mon Mar 17, 2008 11:38 PM, said:
There is a short list of TIA regs that may or may not need to be written every frame in the "ephemeral registers" section. Not all of them need to be changed if their values are the same as shown in the table.
SeaGtGruff, on Tue Mar 18, 2008 12:11 AM, said:
Your question is a little tricky to answer, because it depends on what you mean by "in the game loop." For example, if you check the joystick each time you go through the game loop, and if pressing the button on the joystick makes the program jump to a subroutine that does something-- like fire a missile-- then, technically, the subroutine to fire the missile is in the game loop, because it's being called from within the game loop.
In fact, you could argue that the only things that *aren't* in the game loop are any statements that are performed at the very beginning of the game, before the program ever falls into the game loop, or any statements that are performed when the game is over, after the program exits the game loop-- except that, in reality, you can't "exit to the operating system" when the game is over (since there *is* no operating system), and most games let you restart the program without having to power off and then power back on. Thus, the entire program is actually "in the game loop," except for any statements that get executed on power-up and then are never executed again, even when the game is restarted with a "warm reset." In other words, just about the entire program is one big loop, although it's usually divided up into several smaller loops.
However, I think what you're asking about are statements that need to be performed each time you go through a display loop, because if you don't perform them every time, they will "lose their settings" after the screen has been displayed. In batari Basic, there are very few statements that fall into that category. Basically, you're looking at any memory locations-- TIA registers, RIOT registers, or RAM variables-- whose values get wiped out by the kernel, and which can't be restored automatically by batari Basic. And these memory locations aren't "statements"; they're just locations that get set using an assignment or "let" statement.
In fact, you could argue that the only things that *aren't* in the game loop are any statements that are performed at the very beginning of the game, before the program ever falls into the game loop, or any statements that are performed when the game is over, after the program exits the game loop-- except that, in reality, you can't "exit to the operating system" when the game is over (since there *is* no operating system), and most games let you restart the program without having to power off and then power back on. Thus, the entire program is actually "in the game loop," except for any statements that get executed on power-up and then are never executed again, even when the game is restarted with a "warm reset." In other words, just about the entire program is one big loop, although it's usually divided up into several smaller loops.
However, I think what you're asking about are statements that need to be performed each time you go through a display loop, because if you don't perform them every time, they will "lose their settings" after the screen has been displayed. In batari Basic, there are very few statements that fall into that category. Basically, you're looking at any memory locations-- TIA registers, RIOT registers, or RAM variables-- whose values get wiped out by the kernel, and which can't be restored automatically by batari Basic. And these memory locations aren't "statements"; they're just locations that get set using an assignment or "let" statement.
SeaGtGruff, on Tue Mar 18, 2008 12:11 AM, said:
Likewise, you can define the shapes of player0 and player1 outside the display loop, because batari Basic has RAM pointers to tell it where the player shapes are in ROM. You can also set the (x,y) coordinates of the sprites outside the display loop, because they're stored in RAM variables and don't get wiped out by the kernel.
On the other hand, batari Basic doesn't have RAM variables for the four color registers (the background, playfield, player0, and player1 colors), although it does have a RAM variable for the score color, and sometimes for other colors-- depending on the kernel and kernel options selected (standard vs. multisprite, and the options for multicolored players or playfield, or other special color options). So as long as the kernel doesn't change one of the color registers, you can set it outside the display loop, and it will keep its setting.
In the standard kernel, if you aren't using any of the multicolor options, or any other special color options, the background and playfield colors will keep their values once you set them, so you can set them outside the display kernel. But since the score is drawn with the two players, and the score color can be set, the kernel will wipe out any values you write to the two player color registers, hence you must set the two player colors inside the display loop or they'll get changed to the score's color as soon as the kernel draws the score.
On the other hand, the multisprite kernel uses player1 to draw player2 through player5, and it needs to know which colors to draw them in, so it has RAM variables for the colors of player1 through player5. That means you don't need to set those colors inside the display kernel-- although you *do* still need to set player0's color inside the display loop.
Other player-related registers that get wiped out by the score display include NUSIZ0, NUSIZ1, REFP0, and REFP1, so if you want to set them to specific values, then you'll need to do so inside the display kernel.
The online help manual does contain a discussion and an incomplete listing of these variables-- see the link to "Ephemeral Variables & Registers" in the list of topics in the upper right section of the online manual.
On the other hand, batari Basic doesn't have RAM variables for the four color registers (the background, playfield, player0, and player1 colors), although it does have a RAM variable for the score color, and sometimes for other colors-- depending on the kernel and kernel options selected (standard vs. multisprite, and the options for multicolored players or playfield, or other special color options). So as long as the kernel doesn't change one of the color registers, you can set it outside the display loop, and it will keep its setting.
In the standard kernel, if you aren't using any of the multicolor options, or any other special color options, the background and playfield colors will keep their values once you set them, so you can set them outside the display kernel. But since the score is drawn with the two players, and the score color can be set, the kernel will wipe out any values you write to the two player color registers, hence you must set the two player colors inside the display loop or they'll get changed to the score's color as soon as the kernel draws the score.
On the other hand, the multisprite kernel uses player1 to draw player2 through player5, and it needs to know which colors to draw them in, so it has RAM variables for the colors of player1 through player5. That means you don't need to set those colors inside the display kernel-- although you *do* still need to set player0's color inside the display loop.
Other player-related registers that get wiped out by the score display include NUSIZ0, NUSIZ1, REFP0, and REFP1, so if you want to set them to specific values, then you'll need to do so inside the display kernel.
The online help manual does contain a discussion and an incomplete listing of these variables-- see the link to "Ephemeral Variables & Registers" in the list of topics in the upper right section of the online manual.
http://www.randomter....html#ephvarreg
Although I remember fixing up that Ephemeral Variables and Registers section, it didn't sink in that the list I was looking for was right there. I thought there were other things that were forgotten and had to be reset each time in the game loop.
You said that it was an incomplete listing. What should be added to make it complete?
Thanks.
#7 OFFLINE
batari
-
-
- 6,236 posts
)66]U('=I;B$*
- begin 644 contest
Posted Tue Mar 18, 2008 4:19 AM
It's basically a list of TIA registers you are likely to use. I could list all TIA regs used by the kernel, but I don't think anyone's going to use anything I've not already listed (and using them wouldn't make a lot of sense anyway.)
I called it an incomplete list because I wanted to also list variables that are overwritten by the kernel and some bB commands (such as the temp1-temp6 variables) and list exactly where they are used. I've noticed that programmers generally use regular variables for temporary storage because they simply don't know when it's OK to use temp1-temp6.
I'd like programmers to move away from that and use temp1-temp6 wherever practical so they can free up those regular variables, but I don't expect anyone to do that until I actually sit down and update the list.
I called it an incomplete list because I wanted to also list variables that are overwritten by the kernel and some bB commands (such as the temp1-temp6 variables) and list exactly where they are used. I've noticed that programmers generally use regular variables for temporary storage because they simply don't know when it's OK to use temp1-temp6.
I'd like programmers to move away from that and use temp1-temp6 wherever practical so they can free up those regular variables, but I don't expect anyone to do that until I actually sit down and update the list.
#8 OFFLINE
Random Terrain
-
-
- 20,910 posts
Visual batari Basic User
-
Controlled Randomness
Replay Value
Nonlinear - Location:North Carolina (USA)
Posted Tue Mar 18, 2008 4:56 AM
batari, on Tue Mar 18, 2008 6:19 AM, said:
It's basically a list of TIA registers you are likely to use. I could list all TIA regs used by the kernel, but I don't think anyone's going to use anything I've not already listed (and using them wouldn't make a lot of sense anyway.)
I called it an incomplete list because I wanted to also list variables that are overwritten by the kernel and some bB commands (such as the temp1-temp6 variables) and list exactly where they are used. I've noticed that programmers generally use regular variables for temporary storage because they simply don't know when it's OK to use temp1-temp6.
I'd like programmers to move away from that and use temp1-temp6 wherever practical so they can free up those regular variables, but I don't expect anyone to do that until I actually sit down and update the list.
I called it an incomplete list because I wanted to also list variables that are overwritten by the kernel and some bB commands (such as the temp1-temp6 variables) and list exactly where they are used. I've noticed that programmers generally use regular variables for temporary storage because they simply don't know when it's OK to use temp1-temp6.
I'd like programmers to move away from that and use temp1-temp6 wherever practical so they can free up those regular variables, but I don't expect anyone to do that until I actually sit down and update the list.
#9 OFFLINE
Fort Apocalypse
-
-
- 1,593 posts
Stargunner
Posted Tue Mar 18, 2008 5:40 PM
batari, on Tue Mar 18, 2008 6:19 AM, said:
I've noticed that programmers generally use regular variables for temporary storage because they simply don't know when it's OK to use temp1-temp6.
I'd like programmers to move away from that and use temp1-temp6 wherever practical so they can free up those regular variables, but I don't expect anyone to do that until I actually sit down and update the list.
I'd like programmers to move away from that and use temp1-temp6 wherever practical so they can free up those regular variables, but I don't expect anyone to do that until I actually sit down and update the list.
We had a discussion in the forum some months back and most of us decided that temp4-6 were almost always safe. temp3 is borderline and using temp1 and temp2 can be dicey since function calls involve those two more often (calls to pfread, etc.) I'm probably oversimplifying it and would really look forward to the full scoop on that (like these commands will use temp1/2 so you can't expect they'll be the same value that they were before the command after the command is called, etc. somewhere on http://www.randomter...c-commands.html ).
1 user(s) are reading this topic
0 members, 1 guests, 0 anonymous users
