Shamelessly Trying Again...Golf Hack Anyone

[StephenJ]

Forgive me for bringing this up again.
It's in the hopes that one of our gifted programmers found some time on their hands for a quick project.
(I say "quick", but I have no idea how difficult it would be)

 

As I mentioned in my previous appeal, I like the 2600 Golf game...but there's room for just-a-bit of improvement.

 

Here are the hacks I'd really like to see:

1. Increase the hole count to [18], with the option to play the front or back [9], or the entire course.

2. Have multiple players alternate on each hole, rather than having one player complete the entire hole before the next player is up.
    - Since there would be more than one ball on the playing field at one time, each would have to be a different color that corresponds with the golfer's color.

3. Increase the maximum number of players to [4]. The most fun I ever had, playing retro golf games, was when myself and three of my friends would play Intellivision Golf...lots of cheering, whining and trash talk during those sessions.

 

Please give it some thought.

 

All the best,

StephenJ

[CapitanClassic]

I remember your thread from about 6 months ago. I decided that as a first project it might be fun to attempt this. I am not a gifted programmer, but about 2 months ago (and about 10-20hours of work), I have partially disassembled the game (attached, newfile.a), with the help of Stella. A full disassembly is the first step needed before expanding the game.

 

my findings so far:

 

i have identified about 1/3rd of the variables that are used in the game. HoleNumber, curPlayer numbed, parValue. I have identified where some of the data regarding what objects to display on a hole, and where to place them (somewhat, I don’t completely understand the placement algorithm). I have identified some of the subroutines, and what they are used for.

 

Regarding your proposed changes:

It should be easy to fit 9 more holes within a 4K game since each hole is only a handful of bytes (20-50 or so, I think). I did run into an issue when changing the size of the rom from 2K to 4K (last couple of lines in the file, commented out ). The initialization code sets the pointers to the hole objects to $FF, and somewhere I believe that the difference from the indirecting addressing to the object graphics from the location in the ROM from a 2K to 4K game differs and causes the pointers to point to junk data. All those subroutines will have to be rewritten to point to the correct location.

 

The check for the end of game is just checking if the holenumber is 9 or less. It is simple to change this to 18, but the issue becomes displaying the holeNumber which now requires a new digit at the top. The scores have a similar issue where they are stored as Binary Coded Decimal BCD, and are only a single byte. This only allows scores of 99 or less. Scores over 100 will need an extra digit to display. It would probably be best to rewrite the whole display at the top so more information can be displayed. The 6Digit score technique could be used to display 6 column digits across 3 rows (not sure if there is enough screen real estate, but this could be broken up to a top header and bottom footer.) The Playfield was originally used for this purpose, but this could be changed to using the P0,P1 sprites as long as the player sprite isn’t allowed the move above/below the same level as the score display. I also don’t know if there is enough time to update the player graphics (change from double wide, change from the golfer/club to digits and visa versa while drawing the hole)

 

HoleNumber, Par header

P1 Score, P2Score

 

P3 Score, P4Score footer

 

Having players alternate increases the number of variables needed by at least 6 bytes (store x,y position of ball) and possibly quite a few more (do we need to store the golfers position, or just snap it to the balls position when it is the players turn). I think there is enough ram available, but we are eating up bytes quickly (P3-P4 score) pointers to each of those players current score graphics digits, player color, etc. Additionally, a new subroutine to calculate distance to pin needs to be created to determine who the next golfer should be.

 

Golf2600.zip

Edited August 23, 2019 by CapitanClassic

[CapitanClassic]

If you want 9 more holes, you will have to design them. The originals below.

 

The course must be symmetric (unless the  course data is changed and the display kernel is rewritten).

the course must only have 4 objects on it. One must be the green.

no object can be on the same vertical position as another.

[StephenJ]

Wahoo!!

 

CaptainClassic (great name BTW),

I’m so glad that you chose Golf as your first 2600 Hack project, and I appreciate you sharing the progress you have already made.

 

I have next-to-no knowledge about programming, so I can’t even comment (much less help) on several of the things you mention. But, I have no doubt that your fellow AA programmers will be offering helpful suggestions soon enough.

 

At the laymans' level, let me throw out the following:

• The need for an extra digit for the score
  • When the score tops 99, maybe have the numbers reset to zero, and change their color to red…indicating that the red numbers are +100
• do we need to store the golfers' position, or just snap it to the balls position when it is the players turn.
  • I think having the golfers’ position snap to the balls’ position would be just fine…even preferable to having to move the golfer manually.
• A new subroutine to calculate distance to pin needs to be created to determine who the next golfer should be.
  • I really don’t think you should concern yourself with this aspect of mimicking real golf. I’m sure that alternating turns, regardless of distance to the hole, would be just fine. You’ve got too many other more important things to worry about!

 

Once again, thanks so much for taking on this project. I look forward to following your progress every step of the way.

Stephen

 

-> I was just posting the above reply when I saw your post regarding the additional holes.

Since I'm not a programmer, would it help if I made some hole-suggestions using PowerPoint?

Edited August 23, 2019 by StephenJ

[CapitanClassic]

Use whatever design tool you like for the new holes.

[StephenJ]

The symmetric requirement certainly puts significant limits on the variety of the course. Maybe that's why the original game only had nine holes.  

 

"...unless the course data is changed and the display kernel is rewritten..."

Sounds like that would be a big deal...right?

 

[CapitanClassic]

It isn’t so much that it is a big deal, but rather Theseus’s Ship. At what point after replacing the scoring graphics, creating non-reflected courses, adding more than 4 obstacles, etc. do you have a new homebrew game rather than the original Golf. If you change too much, it will no longer be Golf, but a homebrew game that happens to have 9 holes that are from the original game and 9 holes that look completely different from the original.

 

 

The original courses were pretty limited. I believe that there are only 8x20 bits or so that define the fairway (I don’t think I identified the exact location of this data yet). The Playfield is reflected, and the Playfield bits P0, P1, P2 (only the lower 4 bits) determine the shape of the course, and they are only updated every 8 Scanlines. This is why the course is so blocky.

 

i would suggest designing 4 obstacles in different locations using the 9 fairways that already exist, or opening the course images above in MSpaint /gimp / graphics editor of your choice, and determine exactly where the transitions points in the fairway exist from the top to the bottom over all 9 holes . My guess is that there are 8 points where the course becomes wider/narrower. Then you can create new fairways that have the same number of transitions. There are several that haven’t been created yet, a “U”, an “X” an “O”, ...

 

Limitations force you to be more creative. There are still plenty of variations that are possible with 4 obstacles of your choice (water, sand trap, tree) and either the original 9 fairways or several new fairways with 8 vertical transitions.

Edited August 24, 2019 by CapitanClassic

[Nukey Shay]

The simplest solution for a greater variety of greens is to add CTRLPF to the PF data ($F616 to $F63B are LSB pointers to the bitmaps in page F7).  Currently, all greens use reflected PF.  Just add a new table for CTRLPF values instead of trying to incorporate them into LF616 data.

 

Subroutine $F5B4 is a BRK interrupt.  It should be tagged and the address referenced at $F7FE/F before you change the romsize or move stuff around.

[StephenJ]

I stand by what I said "...The reason I started this thread was to hopefully get the AA programmers to improve the Atari 2600 Golf game...".

In other words, don't change the game; perspective (i.e. top-down, see the entire hole, etc.) or interface...and the like.
I admit, I wasn't concerned with how the improvements were achieved...or if the changes approached the point of making it a new homebrew game vs an updated version of the original.

 

This is your project. Please continue with whatever you think is best.

 

Stephen

 

 

[CapitanClassic]

19 minutes ago, StephenJ said:

I stand by what I said "...The reason I started this thread was to hopefully get the AA programmers to improve the Atari 2600 Golf game...".

In other words, don't change the game; perspective (i.e. top-down, see the entire hole, etc.) or interface...and the like.
I admit, I wasn't concerned with how the improvements were achieved...or if the changes approached the point of making it a new homebrew game vs an updated version of the original.

 

This is your project. Please continue with whatever you think is best.

 

Stephen

 

 

Will you be designing 9 new holes?

[StephenJ]

With the limitations for each hole, even with variations of the obstacles, I don't see there being much to gain by adding 9 more.
I think it's just not enough variety for an entire 18 hole course.

Maybe others here on AA would like to chime in?

 

 

[+Karl G]

In case anyone didn't follow what Nukey was suggesting, currently the shape of the existing holes are mirrored on the left and right sides. As mentioned before, making these completely distinct on each side would be a major rewrite of the game's display kernel. However, a much smaller change would be to allow the option of the hole to be repeated instead of mirrored.  You would be able to design these yourself on a 8x20 grid, and it should be possible to come up with 9 more designs with repeated playfields instead of mirrored. Whoever is doing the hack could take your hole designs, and add them to the game.

 

[CapitanClassic]

2 hours ago, Karl G said:

In case anyone didn't follow what Nukey was suggesting, currently the shape of the existing holes are mirrored on the left and right sides. As mentioned before, making these completely distinct on each side would be a major rewrite of the game's display kernel. However, a much smaller change would be to allow the option of the hole to be repeated instead of mirrored.  You would be able to design these yourself on a 8x20 grid, and it should be possible to come up with 9 more designs with repeated playfields instead of mirrored. Whoever is doing the hack could take your hole designs, and add them to the game.

 

It still isn't clear to me Nukey said the greens are all mirrored (I think he means fairways are all mirrored. There is only one green, it is shared by all the holes). I understand that I can create a new table of PF values for holes 10-18, (and/or) relocate the the original 9 holes to those tables. And if hole >9 then set  PF non-reflected . Even if I dont rewrite the display kernel to update the PF (as in the diagram below), I can create 9 new holes just using the original PF table data. Some will need a little tweaking because they cont have any solid fairway connecting left to right side of screen

 

[Nukey Shay]

Actually, there is a lot of data-sharing going on to build the existing screens in Ram memory (loop LF4E9).  Expanding the Rom to 4k, this could be done with separate data (and allow you to set CTRLPF on every band).  You could mix and match mirrored and reflected bands however you wanted.

[Nukey Shay]

BTW the kernel routine would need to be hacked a bit...as the normally-blank PF0 would be running down the center of the screen for non-reflected playfield bands.

[CapitanClassic]

5 hours ago, StephenJ said:

With the limitations for each hole, even with variations of the obstacles, I don't see there being much to gain by adding 9 more.
I think it's just not enough variety for an entire 18 hole course.

Maybe others here on AA would like to chime in?

 

 

It looks like you have quite a bit of leyway in how you want to construct your fairways. You can either reflect or duplicate, and can change every line of you wish.

 

go ahead and create 9 holes using 20 on/off vale’s that are either duplicated on the right, or mirrored on the right, and I will place them in a new table for holes 10-18. Each hole is 64 pixels high I think

Edited August 25, 2019 by CapitanClassic

[StephenJ]

Is something like this OK?...duplicated on the right side.

[CapitanClassic]

18 minutes ago, StephenJ said:

Is something like this OK?...duplicated on the right side.

That is correct. Although, you actually have twice the resolution horizontally. You have 20 (4x1) pixels on the left that are either duplicated or mirrored in the right. Whether the line is mirrored or duplicated can be controlled individually for each line.

 

Not only that, burn as Nukey pointed out, you don’t have to only have 8 blocky pixels vertically either. The playfield graphics could actually be changed each each scanline instead of every 8 lines.

Edited August 25, 2019 by CapitanClassic

[Mallard Games]

On 8/24/2019 at 4:36 PM, StephenJ said:

With the limitations for each hole, even with variations of the obstacles, I don't see there being much to gain by adding 9 more.
I think it's just not enough variety for an entire 18 hole course.

Maybe others here on AA would like to chime in?

 

 

You could have the back 9 holes be mirrors of the front 9 holes with a darker green color.

[Nukey Shay]

Still need to alter the kernel to do that.  Mirrored playfield is displayed as PF0|PF1|PF2|PF0|PF1|PF2.

The existing kernel is reversed only PF0|PF1|PF2|PF2|PF1|PF0.

[StephenJ]

 

"...you actually have twice the resolution horizontally. You have 20 (4x1) pixels on the left that are either duplicated or mirrored in the right..."

"...Whether the line is mirrored or duplicated can be controlled individually for each line..."

Understood.

 

"...you don’t have to only have 8 blocky pixels vertically..." "...The playfield graphics could actually be changed each each scanline instead of every 8 lines..."

Not following on this one.

 

To simplify for me, and speaking left-side only: I can have up to 20 (4x1) blocks horizontally...how many (4x1) blocks vertically?

Please keep it mind...I am not familiar with the lingo used by Programmers or Graphics artists. 

 

 

 

[CapitanClassic]

7 hours ago, StephenJ said:

 

"...you actually have twice the resolution horizontally. You have 20 (4x1) pixels on the left that are either duplicated or mirrored in the right..."

"...Whether the line is mirrored or duplicated can be controlled individually for each line..."

Understood.

 

"...you don’t have to only have 8 blocky pixels vertically..." "...The playfield graphics could actually be changed each each scanline instead of every 8 lines..."

Not following on this one.

 

To simplify for me, and speaking left-side only: I can have up to 20 (4x1) blocks horizontally...how many (4x1) blocks vertically?

Please keep it mind...I am not familiar with the lingo used by Programmers or Graphics artists. 

 

 

 

I had some of the numbers from my previous post incorrect. It has been a while since i looked at the disassembly.

The resolution of the Atari 2600 is complicated, and there aren’t really such things as pixels.

 

Effectively, the resolution of most games is 160 pixels wide by 192 pixels tall. The Atari 2600 doesn’t have any traditional display ram, instead it has 2 8-bit sprite, 2 missiles (can be 1 pixel, 2-pixels, 4-pixels, or 8-pixels Wide), one ball (1x, 2x, 4x, or 8x) and a 20 pixel (4x pixels/color clocks wide) Playfield that is either reflected/duplicated in the right side of the screen. When you turn on any of the sprites/missiles/ball/Playfield, those pixels are replicated from the top of the visible screen all the way to the bottom of the screen (would appear as vertical bands) 

 

The Playfield pixels are 4 color clocks wide, and if you multiply 4 x 40 pixels (reflected/duplicate), you get 160 pixels wide. Which perfectly fits the horizontal resolution of the Atari.

 

Reexamining the code and watching the debug output in Stella, I can see some of the errors I made. The original 9 holes are always within a 40x9 grid. The Playfield is always set to off for P0 (losing 4 effective grid squares on both the left and right) which controls the left hand side of the screen (and right hand side when reflected). On a duplicated Playfield, this would lead to a blue impassible band down the middle of the fairway, 4 Playfield pixels wide (16 regular pixels). The display kernel never alters the P0 Playfield register, so it will have to be altered. (This isn’t a big deal, but will require modifying the original kernel to update this register when loading fairway data for the hole.

Additionally, all the top and bottom rows of the grid are all blue. So, the original kernel really only has 32x7 grid, with each grid that is fairway displaying on the screen as a large 4 pixels wide x 16 pixels tall.

 

P0  P1.     P2.     P2(r)

0000        1111000000001111        0000

    11111111                11111111

P0.  P1.         P2.          P0(d)P1(d).   P2(d)

0000                0000

    11111111            11111111

            11110000            11110000       

 

 

Since i I am going to have to alter the display kernel anyway to handle the duplicated P0 blue band, I might as well also modify the display kernel that controls how often the P2,P1 fairway registers are updated. They are currently only updated every 16 scanlines. They could possibly be updated as often as every scanline, but I don’t think that level of resolution is necessary. How about updating the Playfield every 4 scanlines. I would still leave a blue boundary around the grid, but your grid is much higher resolution.

 

Original Fairway Grid

40x9 (with blue outer boundary, effectively 32x7)

 

New improved Fairway grid

40x36 (with blue outer boundary, effectively 38x34)

[CapitanClassic]

Additionally, the obstacles are 16x16 pixels big. (Double wide, and a 2-line kernel so twice as tall). In the new 40x36 pixel grid, they would take up a 4x4 grid of pixels.

 

 

[StephenJ]

CaptainClassic,
Looks like I'm not going to be able to contribute to your project, at least not for a while...recent home-life developments.
I'll be putting several other things on hold as well.

As I said before, I'm glad you chose Golf as your first 2600 Hack project and I wish you all the best.
 

Here's hoping it makes it to the AA Store!

StephenJ

 

 

[Nukey Shay]

Golf already has a tidy sum of Ram memory unused, which could be utilized for multiple players or whatever you want...if you are not concerned with displaying multiple players simultaneously.  Just have a player make his shot, then swap to the other player, and so on.  The alternate players need not be visible when the active player is taking his turn.