Jump to content
IGNORED

Sokoban 2600


Cybergoth

Recommended Posts

Adding the sprite is no problem at all. It'll most likely need a Sara chip for non-static display though.

Really? How big are biggest levels? That level (19x11) would need ...88 bytes? 20x14 would fit in 112 bytes, which would be difficult but probably not impossible.

Link to comment
Share on other sites

Really? How big are biggest levels? That level (19x11) would need ...88 bytes? 20x14 would fit in 112 bytes, which would be difficult but probably not impossible.

 

The screen layout is 19*16. Covering all 6 PF registers would require 6*16=96 bytes, maybe 80 if you combine the two PF0 columns. You'd require that RAM twice though, one set for each even and odd lines.

 

And there's another problem: This technique will provide 4 tiles, but unfortunately the game normally requires 5:

 

Void, Wall, Box, Target - AND - Box-on-Target

 

Well, in theory you can replace Box-onTarget with just Box with some effort: If the Box gets moved away, instead of just leaving void, just restore the inital ROM state.

 

There's still a problem remaining with ~ 5 out of the 50 levels that already start with a Box-on-Target, which is a bit harder to solve, since when in ROM I only know it's a Box, I actually don't know that if it gets moved away it must turn into Target then. Unless I keep extra tables and do some extra overhead for these exceptions.

Link to comment
Share on other sites

Cool! Sokoban would be a great addition to the Atari game library.

 

Didn't Andrew make a one level demo of Sokoban a while back?

 

Personally, I'd like to see a version of Kwirk. It is similar to Sokoban in some ways, but has bigger blocks, turnstiles, and gaps where you have to push a block to make a bridge to reach your destination.

Edited by mojofltr
Link to comment
Share on other sites

Really? How big are biggest levels? That level (19x11) would need ...88 bytes? 20x14 would fit in 112 bytes, which would be difficult but probably not impossible.

 

The screen layout is 19*16. Covering all 6 PF registers

:dunce:

 

Of course!

 

Well. Combine PF0 columns gives 10 bytes or RAM per row, so probably your maximum would be what you've got already, an 11-row board.

 

Probably the best idea would be to narrow the board to 16 tiles wide so then you can get a 16x14 board.

 

Or. :!: The green lines are static! So store them in ROM, store blue in RAM, and bingo, you can get a 19x16 board in 80 or 96 bytes of RAM. :)

 

I missing something?

 

EDIT: Just realized, that brings another box-on-target problem: the box-on-target looks like a wall. Of course, it solves your other problem of how to handle an initial box-on-target, and makes moving a box off target easy. You win some, you lose some. :D

 

EDIT II: Maybe make box-on-targets blink slowly to distinguish them?

Edited by vdub_bobby
Link to comment
Share on other sites

I missing something?

 

EDIT: Just realized, that brings another box-on-target problem: the box-on-target looks like a wall.

 

Yes and yes :lol:

 

EDIT II: Maybe make box-on-targets blink slowly to distinguish them?

 

And the walls would blink in sync ;)

 

I thought I could possibly kill some RAM usage with lookup tables, since the actual data per line are only 20 bits. I'm thinking of something like (pseudo code):

 

LDA PF1LeftPF1RightTable,X  ; => 01011100
TAY
LDA LookupPF1Left, Y		; => 00110011
STA PF1
...
LDA LookupPF1Right, Y		; => 11110000
STA PF1

 

So for 6 extra cycles I can get rid of one PF column, two for 12 cycles and maybe I can merge both PF0 also, unpack this live AND display the player AND get all the timings done, then it might be doable without a Sara board ;)

Link to comment
Share on other sites

EDIT II: Maybe make box-on-targets blink slowly to distinguish them?

 

And the walls would blink in sync ;)

No no no! Make just the lines in RAM, the blue lines (just the 'box') blink. ;) So a box that is on target would blink, but the target would stay static. If I could make an animated GIF I'd illustrate but, well, I can't. :D

 

But this is probably better, it's similar to how I stored the girder patterns in Squish 'Em:

I thought I could possibly kill some RAM usage with lookup tables, since the actual data per line are only 20 bits. I'm thinking of something like (pseudo code):

 

LDA PF1LeftPF1RightTable,X ; => 01011100
TAY
LDA LookupPF1Left, Y	; => 00110011
STA PF1
...
LDA LookupPF1Right, Y	; => 11110000
STA PF1

 

So for 6 extra cycles I can get rid of one PF column, two for 12 cycles and maybe I can merge both PF0 also, unpack this live AND display the player AND get all the timings done, then it might be doable without a Sara board ;)

Link to comment
Share on other sites

EDIT II: Maybe make box-on-targets blink slowly to distinguish them?

 

And the walls would blink in sync ;)

No no no! Make just the lines in RAM, the blue lines (just the 'box') blink. ;) So a box that is on target would blink, but the target would stay static. If I could make an animated GIF I'd illustrate but, well, I can't. :D

 

Well yes, but the wall is on on both lines. Either that or it's looking the same as the target.

 

I have 4 different tiles: 00, 11, 10 & 01 so no matter what I assign them, there's always two of them blinking.

 

Or am I missing something now? :twisted:

Link to comment
Share on other sites

Here's how I see it:

Blank: 00

Box: 01

Target: 10

Wall: 11

 

Box-on-target: 11 for ten frames, 10 for ten frames, etc.

 

So it would look like a wall half the time, but in theory :lol: the player could tell because it would be blinking.

 

EDIT: Or hmmm. I think I'm misunderstanding your confusion. All blue lines are stored in RAM, all green lines are stored in ROM. Locations of boxes are stored separately from the array grid. (Is that not possible? What's the maximum # of boxes on a level?) So it would be no problem to remove boxes from the display RAM while still tracking them.

Edited by vdub_bobby
Link to comment
Share on other sites

:dunce:

 

Ok, I got you now. All the time I was assuming with "blinking" you were suggesting a color change for one of the lines :lol:

 

Well, if it would switch even more rapdily between two tiles, with some luck one combination might possibly transmogrify into a really plausibly 5th tile :)

 

EDIT: Or hmmm. I think I'm misunderstanding your confusion. All blue lines are stored in RAM, all green lines are stored in ROM. Locations of boxes are stored separately from the array grid. (Is that not possible? What's the maximum # of boxes on a level?) So it would be no problem to remove boxes from the display RAM while still tracking them.

 

I didn't even get so far, with my confusion already kicking in before it. But yes, you'd need to store the boxes separately for this then. (I haven't checked yet what the maximum # of boxes is. Some 20-30 I'd assume)

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...