Hello 2600 Homebrewers

[The Brew that is True]

2 hours ago, Andrew Davie said:

Sinking is always an option.

 

you could implement "distance buffers" around each boat, and simply not allow a boat to move if the buffer would cause a collision. That's of course if you're using software collision code - which I would be doing.  So, calculate object position - check collision - if no collision, move object to that position. With a (circular) distance buffer around the boat, you'll always be able to turn around and steer out - admittedly sometimes difficult against prevailing winds. 

 

The concept, anyway, is that there are never collisions, but just collisions that are avoided by disallowing movement before the collision happens.

Thanks for your insights Andrew, much appreciated.

 

Simply sinking upon collision is definitely a possibility, perhaps as a variant option.

 

I'm currently using a similar approach to your "there are never collisions" concept for the "edges of the world". But I planned to leverage the builtin hardware detection for boat/playfield and boat/boat collisions. Mainly for two reasons, first as an opportunity to learn that aspect of the 2600, and second to take advantage of the presumed savings in code, space, time, bugs, etc... and understanding the tradeoffs involved.

 

In what situations do you use hardware collision detection, or have you forsworn it entirely as a non-starter?

 

Cheers

[+Andrew Davie]

3 minutes ago, The Brew that is True said:

In what situations do you use hardware collision detection, or have you forsworn it entirely as a non-starter?

 

In my case... never ever.  It precludes, for example, you having a sort of isometric view on stuff.  The top of your mast will collide with the keel/hull of a boat above it, when in fact it might look that the hulls are widely separated. I don't think hardware collision is the greatest, as it's "pixel perfect" and that's often IMHO the very last thing you want. Great for pong and ball hitting paddle, sure. But I would never ever consider using it. Software for me!

[The Brew that is True]

2 hours ago, Andrew Davie said:

In my case... never ever.  It precludes, for example, you having a sort of isometric view on stuff.  The top of your mast will collide with the keel/hull of a boat above it, when in fact it might look that the hulls are widely separated. I don't think hardware collision is the greatest, as it's "pixel perfect" and that's often IMHO the very last thing you want. Great for pong and ball hitting paddle, sure. But I would never ever consider using it. Software for me!

Never ever... Wow, fascinating. I'll need to ruminate on that a while. ?

 

[The Brew that is True]

I've given up, at least for now, on coming up with anything sophisticated for collision recovery. I tried a few different ideas, but none worked cleanly in the context of a wind-relative movement system. So I will punt for the time being: In the attached baby step a boat that collides with the playfield (or the other boat) goes back to restart the race.

 

I added four playfield blocks (the smallest ones) to serve as race course marker buoys. I need to add logic for tracking that each boat rounds all buoys in the proper order to complete the race. Once I've added buoy tracking, I might change the collision recovery to return a boat back to the last buoy it rounded, instead of all the way back to the race start.

 

Feedback is of course appreciated.

 

PS: When I launch this ROM file on Stella the display area comes down like a curtain being lowered. Does it also behave this way on a physical 2600?

Match_Race_2600_baby_step_8.bin

[+Andrew Davie]

Would be nice to have visible wind direction speed/markers.  A flag/number top corner perhaps, or flags on the buoys?

I think the pivot point on the bow is a mistake; it would be more intuitive to me, at least, to have it at the boat midpoint.

Keep up the good work!

 

[+Andrew Davie]

If you could make the 45° angles actually 45° in the graphics, rather than what looks about 30°, I think the visuals of the direction change (along with the midpoint as suggested above) would be much improved.

[+Andrew Davie]

Add inertia to the movement, so when you turn, you slowly lose the motion you had, and gain the motion you will have.

This would make a big difference to the feeling of "sailing". No more instant stops when heading into the wind, and acceleration.

These will make big improvements, IMHO.

 

[+Andrew Davie]

Perhaps include some randomness in the wind speed (i.e., +/-  25% or so, around the original speed).  That is, simulating gusts and inconsistency.  In other words, windspeed may be 10 knots, but on any particular frame you may see 8... or 11... or 12...   could vary slowly, and over the course of a game, could even totally change direction. Would be a good one for difficulty options, too.

 

Now I look more closely, I think you do change the wind speed. But it's abrupt.  Ramp up/down to new speeds and directions so it's more natural. This combined with ship inertia should be pretty cool-looking.

 

Edited July 19, 2022 by Andrew Davie

[The Brew that is True]

29 minutes ago, Andrew Davie said:

Would be nice to have visible wind direction speed/markers.  A flag/number top corner perhaps, or flags on the buoys?

I think the pivot point on the bow is a mistake; it would be more intuitive to me, at least, to have it at the boat midpoint.

Keep up the good work!

 

Thanks for the feedback Andrew!

 

There's a wind vane built into the center island showing the direction from which the wind is currently blowing.

There's no wind speed indicator since wind speed is constant during a race. Although I was thinking of possibly having wind speed vary from race to race, i.e. a calm weather race, a normal weather race, a stormy weather race.

 

The buoys could use some differentiating markings.

 

 

[The Brew that is True]

45 minutes ago, Andrew Davie said:

I think the pivot point on the bow is a mistake; it would be more intuitive to me, at least, to have it at the boat midpoint.

Keep up the good work!

 

The only reason I'm using the bow as pivot point is that the naval board wargames I own are designed that way. I'm just parroting them, I have no idea what the actual design rationale was behind their choice. At some point I should make a center pivot prototype for comparison.

[The Brew that is True]

47 minutes ago, Andrew Davie said:

If you could make the 45° angles actually 45° in the graphics, rather than what looks about 30°, I think the visuals of the direction change (along with the midpoint as suggested above) would be much improved.

I'll look into this, they seemed roughly 45° to me, but I only eyeballed, I never bothered to actually check.

[The Brew that is True]

1 hour ago, Andrew Davie said:

Add inertia to the movement, so when you turn, you slowly lose the motion you had, and gain the motion you will have.

This would make a big difference to the feeling of "sailing". No more instant stops when heading into the wind, and acceleration.

These will make big improvements, IMHO.

 

That is already in place, but it needs recalibration, the effect is currently much too subtle to be noticed.

 

                Point of Sail
    New Speed   This Frame
    This Frame
              \  0 1 2 3 4
               \ - - - - -
             0|  0 1 1 1 1  |0
             1|  0 2 2 2 2  |1
    Previous 2|  1 2 2 3 3  |2
    Speed    3|  1 2 3 4 4  |3
             4|  2 2 3 5 4  |4
             5|  2 3 3 5 4  |5
                 - - - - -
                 0 1 2 3 4

Here are the Points of Sail referred to above:

  # Point of Sail
  - -----------------------------
  0 In Irons (i.e. into the wind)
  1 Close Hauled
  2 Beam Reach
  3 Broad Reach
  4 Running Downwind
  - -----------------------------
            \
             \          Wind Direction
              \     -----------------------
               \    W NW  N NE  E SE  S SW
                \   0  1  2  3  4  5  6  7
                 \ -- -- -- -- -- -- -- --
           |  W 0|  0  1  2  3  4  3  2  1 
           | NW 1|  1  0  1  2  3  4  3  2 
           |  N 2|  2  1  0  1  2  3  4  3 
      Boat | NE 3|  3  2  1  0  1  2  3  4 
   Heading |  E 4|  4  3  2  1  0  1  2  3 
           | SE 5|  3  4  3  2  1  0  1  2 
           |  S 6|  2  3  4  3  2  1  0  1 
           | SW 7|  1  2  3  4  3  2  1  0 
                   -- -- -- -- -- -- -- --
                    0  1  2  3  4  5  6  7
                    W NW  N NE  E SE  S SW

N.B.

When reading the Point of Sail Table note that wind direction is generally reported by the direction from which it originates. For example, a north or northerly wind blows from the north to the south.

Edited July 19, 2022 by The Brew that is True

[The Brew that is True]

1 hour ago, Andrew Davie said:

Keep up the good work!

 

I really appreciate the feedback and encouragement, you've given me much to mull over. 

[The Brew that is True]

I haven't worked on this for over a week.

 

I've been spending my morning coffees reading through the treasure trove that is Stella mailing list archive.

It seems the 2600 coding + emulation + disassembly + discussion scene was very vibrant 20+ years ago. 

 

Revisiting the Stella archive is producing many more aha moments of insight compared to my first skim-through.

 

I think I'll focus next on how to add a lap/score display without compromising the current 192x160 playing surface. Plenty of head scratching and hand wringing awaits me I'm sure. 

 

Edited July 28, 2022 by The Brew that is True

[The Brew that is True]

My latest experiments have all resulted in flicker fests. 

 

I'm fine with flicker when used for in-game effects (e.g. zapping things, explosions, lightning, tractor beams), but otherwise it is a bane.

 

Oh well, back to the drawing board. 

[The Brew that is True]

No More Secrets v0.96 (NMOS 6510 Unintended Opcodes)

Heady stuff. Hopefully my display kernel can benefit.

 

[The Brew that is True]

I've been putting it off for a while now, but I've reached the point where I need to go back to my initial attempt at a display kernel to restructure and optimize it. I'll need to squeeze in at least a race/lap progress bar per player (presumably using the Mx).

 

I've been working on these experiments a little too much in a vacuum, learning from the Stella mailing list and AA archives, but most  discussion is centered around styles of games other than racing. I'll be on the lookout for commented disassemblies of any 2600 racing games to gain insights on how they handled various aspects.

 

I'm not sure if I'm using the terminology correctly, I guess you'd call my current display kernel a Four-Line Kernel (4LK) that's been intertwined with a Single-Line Kernel (1LK). Right now the 4LK handles the refresh of the playfield and the wind vane, while the 1LK handles the boats.

Here for example is the first of four scanlines worth of display kernel code:

 

---------------------------------------------------------------
 DK WORK 1/18 - 1LK TIA Updates for 1st scanline of 4.

 Color Clocks: 27 x192/4 = 27 x48 = 1,296
 ROM Bytes: 6
 ---------------------------------------------------------------

 N.B. Assumes preloaded A register.

851c    sta GRP1_ff     (3)x3   @ dk.000*.000-008 ***
a5d2    lda ORAM_GRP0   (3)x3   @ dk.000*.009-017
851b    sta GRP0_ff     (3)x3   @ dk.000*.018-026 ***

 ---------------------------------------------------------------
 DK WORK 2/18 - 4LK TIA Updates.

 Color Clocks: 72 x192/4 = 72 x48 = 3,456
 ROM Bytes: 16
 ---------------------------------------------------------------

a5d7    lda ORAM_ENABL  (3)x3   @ dk.000*.027-035
851f    sta ENABL_02    (3)x3   @ dk.000*.036-044 ***

a5d3    lda ORAM_PF0    (3)x3   @ dk.000*.045-053
850d    sta PF0_f0      (3)x3   @ dk.000*.054-062 ***
a5d4    lda ORAM_PF1    (3)x3   @ dk.000*.063-071
850e    sta PF1_ff      (3)x3   @ dk.000*.072-080 ***
a5d5    lda ORAM_PF2    (3)x3   @ dk.000*.081-089
850f    sta PF2_ff      (3)x3   @ dk.000*.090-098 ***

 ---------------------------------------------------------------
 DK WORK 3/18 - 1LK Preloads for 2nd scanline of 4.

 Color Clocks: 129 x192/4 = 129 x48 = 6,192
 ROM Bytes: 28
 ---------------------------------------------------------------

98      tya                     (2)x3   @ dk.000*.099-104
 N.B. clc rather than sec.
18      clc                     (2)x3   @ dk.000*.105-110
e587    sbc SRAM_P0_Y           (3)x3   @ dk.000*.111-119
c5a7    cmp CRAM_P0_HEIGHT      (3)x3   @ dk.000*.120-128
aa      tax                     (2)x3   @ dk.000*.129-134
a900    lda #$00                (2)x3   @ dk.000*.135-140
e900    sbc #$00                (2)x3   @ dk.000*.141-146
35a9    and CRAM_GRP0_ROWS,X    (4)x3   @ dk.000*.147-158
85d2    sta ORAM_GRP0           (3)x3   @ dk.000*.159-167

98      tya                     (2)x3   @ dk.000*.168-173
 N.B. clc rather than sec.
18      clc                     (2)x3   @ dk.000*.174-179
e589    sbc SRAM_P1_Y           (3)x3   @ dk.000*.180-188
c5b3    cmp CRAM_P1_HEIGHT      (3)x3   @ dk.000*.189-197
aa      tax                     (2)x3   @ dk.000*.198-203
a900    lda #$00                (2)x3   @ dk.000*.204-209
e900    sbc #$00                (2)x3   @ dk.000*.210-215
35b5    and CRAM_GRP1_ROWS,X    (4)x3   @ dk.000*.216-227

[The Brew that is True]

Since I probably won't get a chance to work on baby step #9 for at least another week, maybe two weeks. I thought I'd at least post the source as it stands at the moment (in a complete state of flux) for your entertainment and amusement. 

Match_Race_2600_baby_step_9.txt

[The Brew that is True]

Are "spurious" writes to the TIA write addresses in the range $2d..3f safe on a physical 2600?

 

I'm thinking of using c63f dec $3f as my default 2-byte 3mc/15cc delay macro.