Jump to content
Sign in to follow this  
Cybergoth

Sokoban 2600

Recommended Posts

Hi there!

 

I wonder for what kind of game such a display could possibly be good for? :?

 

Greetings,

Manuel

hm.zip

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Hi there!

 

I wonder for what kind of game such a display could possibly be good for? :?

 

Greetings,

Manuel

Well, for starters, how about for posting screenshots?

Share this post


Link to post
Share on other sites
Well, for starters, how about for posting screenshots?

 

Kinda ruins the gag then :ponder: :lol:

 

I was bored last night, so I wrote a tool that can read the level data from the C64 version. Even from the custom levels done with the built-in editor.

Share this post


Link to post
Share on other sites
OOPS! Sorry!!

 

Hey, bring it back, it's ok! Not that funny anyway ;)

Ok!

Would be nice if you make this game one day (maybe after jumpman?). :)

Share this post


Link to post
Share on other sites
Would be nice if you make this game one day (maybe after jumpman?). :)

 

Well, I'm ready to go. Just bring on Sara replacement boards ;)

Share this post


Link to post
Share on other sites
Kinda ruins the gag then :ponder: :lol:

 

Not for those of us who frequent a certain other forum. :ponder: :P

 

Garak

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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

Share this post


Link to post
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 ;)

Share this post


Link to post
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 ;)

Share this post


Link to post
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:

Share this post


Link to post
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

Share this post


Link to post
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)

Share this post


Link to post
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.

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...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...