Shades (Atari 2600)

[+playsoft]

A few years ago I started a port of the iOS game Shades by UOVO which is a Tetris type game where you have to try and drop a block on another of the same shade so they merge to a darker shade:

 

 

That it used luminance made it well suited to the 2600 but it was frustratingly hard to tell them apart and I abandoned it. However recently @Thomas Jentzsch hacked it to use different (but similar) hues to give more variance.

 

Attached is the current WIP.

 

@Karl G I've added 3 additional colour palettes and for testing you can step through them by pressing the trigger during the game. The colours are just placeholders for now, if you fancy playing around with these you will find them in build\colours.s. Each palette comprises 6 colours values, the 5 block colours (ordered bright to dark) plus the background colour. I use the ca65 assembler which is included so you should be able to rebuild by running build.bat in the build directory from the command prompt. Perhaps the colours could switch each time the speed increases?

 

Currently there are 4 speeds; NOVICE starts at speed 1, NORMAL at speed 3 and EXPERT at speed 4. I thought the fastest speed was difficult enough but I'm getting better at playing it now and it needs to go faster and present more of a challenge once you get to around 3,000 points.

 

shades_wip_1_5_2020.zip

[+Philsan]

Awesome Paul! That's a good use of one of VCS strenghts, 128 colors.

 

Considered the fact A8 has 128 colors too and 16 shades of color in one graphic mode, I would love an A8 conversion.

[+playsoft]

Thanks Phil, this was originally going to be an A8 game and my contribution to the 2017 New Year Disk. But when I started coding it seemed it could be done just as well on the VCS. Perhaps an A8 version for the 2021 NYD!

[bluswimmer]

Glad to see that this is getting more development! Would like to see a color palette with greyscale blocks.

[+Karl G]

I love the ability to switch the color scheme in real time.

[+Karl G]

On 5/1/2020 at 6:29 AM, playsoft said:

I use the ca65 assembler which is included so you should be able to rebuild by running build.bat in the build directory from the command prompt.

Has anyone else had luck assembling this?  I was able to, but the 60Hz versions have unstable screens. I'm on a mac though, so I built my own version of cc65 instead of using the included version.

[+playsoft]

1 hour ago, Karl G said:

Has anyone else had luck assembling this?  I was able to, but the 60Hz versions have unstable screens. I'm on a mac though, so I built my own version of cc65 instead of using the included version.

Were the .bin files in the .zip stable? Assembling should have generated identical files, so would be interesting to see if they match.

[+Karl G]

7 minutes ago, playsoft said:

Were the .bin files in the .zip stable? Assembling should have generated identical files, so would be interesting to see if they match.

Yeah; the included ROMs played fine, and I did a "cmp" on the unstable ones to determine something was indeed different.  One could blame my version of cc65, I suppose, but it seems strange that it's just the 60Hz versions that had issues.

[+Karl G]

Okay - I tried it on a Windows VM with the version of the assembler you included in the download, and everything worked okay, so it must be something specific to my Mac version of the assembler.

[+playsoft]

About the only thing I can think of which is open to some interpretation by the assembler is when it decides to do zp or absolute addressing. My guess would be the Mac code takes a little longer and there was enough leeway in the 50Hz builds for it to have no effect, but not the 60Hz ones. I wouldn't mind seeing a Mac build, not to do a full analysis but just to see what the first difference is.

[+Karl G]

44 minutes ago, playsoft said:

About the only thing I can think of which is open to some interpretation by the assembler is when it decides to do zp or absolute addressing. My guess would be the Mac code takes a little longer and there was enough leeway in the 50Hz builds for it to have no effect, but not the 60Hz ones. I wouldn't mind seeing a Mac build, not to do a full analysis but just to see what the first difference is.

Sure thing!  I'm curious as well.  ? Here's the version I built on my MacBook.

 

shades-ntsc-borked.bin

[+playsoft]

That is identical to the PAL version, so it is not seeing the HZ_60 or NTSC flags.

 

I define them on the command line (the -Wa means pass to the assembler, -DHZ_60=1 means define label HZ_60 with value 1):

 

bin\cl65 -t atari -C bin\memory.cfg -Wa-DHZ_60=1 -Wa-DNTSC=1 main.s -o SHADES_NTSC.BIN

 

In the code it uses these labels to select timer values and colours:

 

.ifdef HZ_60
VBLANK_TIME       = 50
OVERSCAN_TIME     = 26
.else
VBLANK_TIME       = 83
OVERSCAN_TIME     = 52
.endif

.ifdef NTSC
YELLOW            = $10
BLUE              = $90
GREEN             = $C0
.else
YELLOW            = $30
BLUE              = $B0
GREEN             = $50
.endif

block_colours:
.ifdef NTSC
  .byte $AE,$BA,$C6,$C2,$D0,$90
  .byte $3E,$3A,$36,$32,$30,$F0
  .byte $5E,$5A,$56,$52,$50,$B0
  .byte $9E,$9A,$96,$92,$90,$40
  .byte $AE,$BA,$C6,$C2,$D0,$90 ; repeat of first
.else
  .byte $5E,$58,$54,$52,$50,$B0
  .byte $4E,$48,$44,$42,$40,$80
  .byte $AE,$A8,$A4,$A2,$A0,$60
  .byte $DE,$D8,$D4,$D2,$D0,$50
  .byte $5E,$58,$54,$52,$50,$B0 ; repeat of first
.endif

.ifdef HZ_60
  ldx #$03
.else
  ldx #$19
.endif
:

So for whatever reason it seems they are not getting passed down.

 

[+Karl G]

Huh - I had to strip off the -Wa portion and just use -D directly to get it to work.  Here's my simple UNIX/MacOS build script that's working now (build.sh):

 

#!/bin/bash
cl65 -t atari -C bin/memory.cfg -DHZ_60=1 -DNTSC=1 main.s -o SHADES_NTSC.BIN
cl65 -t atari -C bin/memory.cfg -DNTSC=1 main.s -o SHADES_NTSC_50.BIN
cl65 -t atari -C bin/memory.cfg main.s -o SHADES_PAL.BIN
cl65 -t atari -C bin/memory.cfg -DHZ_60=1 main.s -o SHADES_PAL_60.BIN

build.sh