Jump to content
IGNORED

Has anyone made a list of commands that must go in the game loop?


Random Terrain

Recommended Posts

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.

Edited by Random Terrain
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Yeah, I bet somebody has made a list by now since bB has been around for 3 or 4 years.

 

 

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.

Thanks for the info about drawscreen. I thought I read in this forum a year or two ago about something needing to come before or after drawscreen, but I'm probably just remembering something else that had to go before or after a different command.

 

 

Can't wait until you start posting some code/bins RT.

Thanks. After I finish the new version of Tone Toy, I'll start working on some games. I can't wait to play around with multicolored sprites and playfields.

Link to comment
Share on other sites

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:

 

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 loop

because 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 loop

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.

 

Michael

Link to comment
Share on other sites

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.

Thanks. See the bottom of this post for more on this.

 

 

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.

Yeah, I'm talking about the things you can set up outside of the game loop, at the beginning before the game loop begins. I understand that anything you need for the game loop that you jump to using goto or gosub is also part of the game loop.

 

 

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.

Thanks. So it looks like there aren't that many things that are forgotten and need to be reset each time during the game loop:

 

http://www.randomterrain.com/atari-2600-me....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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Thanks.

Link to comment
Share on other sites

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.

 

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.randomterrain.com/atari-2600-me...c-commands.html ).

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...