In search of...

[wimoos]

There is a minor bug in the Sokoban game at line 46. The PEEK(P+D+D) might peek beyond screen limits and find an inconsistent value there.
The fix is to do the PEEK only after a box is found at P+D.

I came across this when converting the game to WimBasic where I use CEEK. CEEK checks parameter boundaries and stumbled across this,

Regards,

Wim.

[Mike]

There is a minor bug in the Sokoban game at line 46. The PEEK(P+D+D) might peek beyond screen limits and find an inconsistent value there.
The fix is to do the PEEK only after a box is found at P+D.

This fix is not necessary and only complicates the code.

The IF statement in line 47 already handles this case by itself: (BAND3)=2 checks for a box at P+D and when there is no box, the value of C as used in (CAND3)=0 is irrelevant as the Boolean expression is already false. When there is a box at P+D, the level designs enforce that P+D+D is within defined screen memory and thus (CAND3)=0 can correctly check whether the place behind the box is empty.

[wimoos]

PEEK-ing "out of bounds" is not really proper programming.

Replacing line 46 as follows already fixes it. Can't say it complicates code.

Code: Select all

46 A=PEEK(P):B=PEEK(P+D):ONBAND1GOTO44:C=PEEK(P+D+D):IF(BAND3)=0THENPOKEV+12,240:GOSUB52

Regards,

Wim.

[Mike]

PEEK-ing "out of bounds" is not really proper programming.

As I wrote, the condition is already being taken care of. No need to change the code.

Can't say it complicates code.

Your fix just adds unnecessary code in an attempt to 'protect' the integrity of a system that doesn't have to be concerned about it.

[wimoos]

Yes. Well.

The setup of the Sokoban game, with its bitmasks to signify the contents of a location is a great find.

But, in the algorithm:

What is the use of trying to get information on a second-adjacent location if you're not even sure you're going to impact it ? Because, maybe the first-adjacent location is a wall (in which case you're not going to move at all, and the second-adjacent is non-existent) or it is an empty space (in which case you'll just move there with no side-effect).

Only if the first-adjacent location holds a box, then there must be a valid second-adjacent location and it is interesting to know what it holds. Only when it holds a space then you can move. So, also, as a side-effect, what is the use of getting information on your current location if you're not sure you will even move.

My suggestion for an algorithm is as follows. There is no unnecessary code and it successfully protects the integrity of the system.

Code: Select all

...
46 B=PEEK(P+D):ONBAND1GOTO44:IF(BAND2)=0THENPOKEV+12,240:GOTO49
47 C=PEEK(P+D+D):ONSGN(CAND3)GOTO44:POKEV+13,240
48 N=N+((CAND4)-(BAND4))/4:POKEP+D+D,CAND4OR34
49 POKEP+D,BAND4OR33:POKEP,PEEK(P)AND4OR32:P=P+D
50 FORT=1TO70:NEXT:POKEV+12,0:POKEV+13,0
51 FORT=1TO30:NEXT:IFN<MTHEN44
...

By the way, in WimBasic this takes only three lines:

Code: Select all

...
21 B=CEEK(P+D,S):ONBAND1GOTO20:IFBAND2:C=CEEK(P+D+D,S)ELSEPLAY3,240:GOTO23
22 IFCAND3THEN20ELSESOUND240:N=N+((CAND4)-(BAND4))/4:COKEP+D+D,CAND4OR34
23 COKEP+D,BAND4OR33:COKEP,CEEK(P,S)AND4OR32:P=P+D:PLAY3,0:SOUND0,1:WEND
...

Regards,

Wim.

[Mike]

So, also, as a side-effect, what is the use of getting information on your current location if you're not sure you will even move.

Again, I am doing it this way, because it keeps the program logic simple. Any extra conditional statement only increases the probability of introducing real bugs into the code:

For example, when a box is moved, there are 3 tiles affected, each of them could be a target or not. With the given encoding, I really don't need to think about all 8 combinations while the program redraws these 3 tiles. Also the count N of all boxes on targets can simply be updated with one Boolean expression: [...]

See here.

[wimoos]

I can follow the "state-analyze-move" approach and honor it, next to my pragmatic approach.

Still a PEEK is done that is possibly "out-of-bounds". And because the screen memory, conveniently, doesn't start at 0, this doesn't lead to an ILLQUANT error. During the analysis it is discovered that the bogus value is not needed.

I see two possible solutions for the original approach:

Apply IF P+D+D>7679 THEN C=PEEK(P+D+D) (because later it is found that whatever value C has, it is not needed (enforced by the screen definitions)). In WimBasic I would do: C=CEEK(MAX(0,P+D+D),S)

or

Change line 34 to M=0:N=0:FORAD=7700TO8020STEP20:X=0 , thus positioning everything one row lower on the screen and defining the first row as part of "the world outside the building".

Regards,

Wim.

[Mike]

Change line 34 to M=0:N=0:FORAD=7700TO8020STEP20:X=0 , thus positioning everything one row lower on the screen and defining the first row as part of "the world outside the building".

I applied this change. The *.zip file has been updated, please reload: (download)

It was necessary to also change lines 31 and 32 which re-size and re-position the screen. The window content now appears at the same position on screen as before (the display window was shifted up one text line, and extended by *two* text lines, compared to the original).

The "written by" year in line 22 was changed to follow suit.

While I was at it, I also added a boot loader which unexpands the VIC-20 on load, so it's not necessary anymore to remove RAM expansions.

Greetings,

Michael

[wimoos]

This is the WimBasic version of the Sokoban game that Mike developed. I have added a rudimentary timer and counters for moves and pushes.
Run BOOT to load and run WimBasic, that subsequently reconfigures the VIC and starts the game.

The following WimBasic features were used:

HIMEM
INPUTLINE# (the screen files were reformatted to support this)
INPUTFORM
INSTR
WHILE / WEND and QUIT
IF THEN ELSE
COKE / CEEK
DOKE / DEEK
PLAY / SOUND / VOLUME
COLOR
PRINT@ / USING
SEC
Mike's joystick routine that I embedded in WimBasic.

Regards,

Wim.

skb-wb.zip

(17.54 KiB) Downloaded 50 times