Sokoban

[alex_79]

I like the improvements in the animation, and I see you also changed the levels' colors. They look better now, in the previous version the boxes and the walls were in the same color in level 7.

A couple of bug reports:

 

1- There are quite a lot of screen jumps (too many scanlines) in PAL mode (right diff to B). This doesn't happen in NTSC.

 

2- It is sometimes possible to move a box diagonally! You can easily try this in level 3, where you can move the right box diagonally on top of the left one. I went through the older versions and this bug is present since the first binary you posted on July 23.

 

  

Edited August 29, 2019 by alex_79

[+Andrew Davie]

3 hours ago, alex_79 said:

I like the improvements in the animation, and I see you also changed the levels' colors. They look better now, in the previous version the boxes and the walls were in the same color in level 7.

A couple of bug reports:

 

1- There are quite a lot of screen jumps (too many scanlines) in PAL mode (right diff to B). This doesn't happen in NTSC.

 

2- It is sometimes possible to move a box diagonally! You can easily try this in level 3, where you can move the right box diagonally on top of the left one. I went through the older versions and this bug is present since the first binary you posted on July 23.

 

  

 

How funny!  Many thanks for the report!  Will fix these ASAP.

The screen jump is because of very tight cycle counting in the hunt for ultimate speed. I'll rework my calculations.

The diagonals; it never occurred to me to try diagonals.

 

 

 

[+Andrew Davie]

Here is an update that's a bit of a bugfix and bit of improvements.

 

Firstly, I have backed-off the timing tolerances and hopefully we won't see PAL flicker. What I have to do is count to the exact cycle how long each various subsection of the code takes. This is sometimes a matter of figuring out ALL of the various pathways code can take through conditional branching, etc., and then finding the slowest path. To the exact cycle. And then I tell the system that's how long it takes to do that code. The system will then pre-check to see if there's enough CPU time to execute at least that amount of code, before executing it. If I get those cycle times wrong, or I add some code without re-counting... then the screen draw effectively goes overtime and we get glitches. So it's a bit of a pain.  What I've done here is instead of re-counting hundreds and hundreds of lines of code, I've just added a fudge factor to ALL of the counts, so they are saying "hey I take so long to execute". They lie to the scheduling system, basically. They ask for X units of time when they really only need X-2 units of time, for example.  The upshot of this is that the scheduler runs a little slower because it sometimes waits for a "long enough" timeslot when it really could have thrown the bit of code up for execution in a slighlty smaller time gap that happened earlier. It's not a biggie.

Now, the pushing diagonals was a bit tricky. What I think was happening was that between when the system started pushing a box and when it actually decided to get the push done, the joystick had changed direction. So you would have it thinking ... "what's the new square for the box... is it empty?"  And when you started out, the new square was to the side, not empty so no push, but the next time around, the new square was determined (from the now UP joystick) to be empty and thus pushable. And the box went (effectively) diagonal.  So, if that's not fixed this time, at least I know exactly what's happening. Just a bit tricky to fix, with the buffered joystick stuff.

 

Finally, even more fixups of the animations. I like, in particular, the turning around - if you're in a corner facing the wrong way, for example, then you will turn around first (one move) before actually moving in the direction you want (another move).  We shall see if this becomes the most hated feature of the game or not. I hope not, as I said... I like it.

I've included the source code this time - consider this a snapshot in time - but remember that the full and current source is always available on github at GitHub Sokoboo
 

Sokoboo_SOURCE_2019030b.zip sokoboo_2019030b.bin

[spspspsp]

12 hours ago, Andrew Davie said:

Having said that, I did get a few pointers on things to fix.  The first was joystick responsiveness. It's a fine line between being responsive (not missing any moves), and running too fast and doing moves you didn't intend. It's compounded by the game not running at 60Hz internally - it's an asynchronous engine and sometimes things take a little longer, so you don't always get to the player move at the same regularity.

I know this is tricky because of the asynchronous engine, but I struggle with this too. My playing style is to release the stick at the time I expect the box to move, but because the timing varies sometimes I release before the box moves and I have to push again. A sound effect like in the Game Gear version of Sokoban might help players like me.

 

And I see that the diagonal pushing issue has recently been reported. I noticed that today for the first time too.

 

Another thing I noticed is that this: when you are pushing a box (against a wall or another box, for example), it is possible to move away from the box while maintaining your box pushing stance as long as you don't recenter the joystick. Other versions I've played lock you in place unless you put the controller in its neutral position. I was able to mess up some of the maps quite a bit when I combined this with diagonal pushing.

[+Andrew Davie]

1 minute ago, spspspsp said:

Another thing I noticed is that this: when you are pushing a box (against a wall or another box, for example), it is possible to move away from the box while maintaining your box pushing stance as long as you don't recenter the joystick. Other versions I've played lock you in place unless you put the controller in its neutral position. I was able to mess up some of the maps quite a bit when I combined this with diagonal pushing.

Thanks for reporting this; I was aware of it. It's really just the animation that's wrong. To "smooth out" the transitions between animations, I prevented the idle and walk from immediately changing to a new animation. In this particular case, the new animation is never triggering. Just a minor bug - it won't affect pushing boxes in any way.

[+Andrew Davie]

3 minutes ago, spspspsp said:

I know this is tricky because of the asynchronous engine, but I struggle with this too. My playing style is to release the stick at the time I expect the box to move, but because the timing varies sometimes I release before the box moves and I have to push again. A sound effect like in the Game Gear version of Sokoban might help players like me.

 

 

There will definitely be a sound effect. Maybe after this weekend. I can also change the delay before a box is pushed (make it longer), which might help. But that might be frustrating, we shall see.  In any case, there should be sufficient time after the box actually moves to let go before it gets triggered again. It's a fine line... responsiveness.

[spspspsp]

6 minutes ago, Andrew Davie said:

Thanks for reporting this; I was aware of it. It's really just the animation that's wrong. To "smooth out" the transitions between animations, I prevented the idle and walk from immediately changing to a new animation. In this particular case, the new animation is never triggering. Just a minor bug - it won't affect pushing boxes in any way.

In the most recent binary I can't seem to do this any more. So, I guess it's no longer an issue.

 

The new animations are nice, by the way.

Edited August 30, 2019 by spspspsp

[+Andrew Davie]

I've started work on a new "better" level display/selection screen. I'm dog tired so I thought I'd put up at least what I have so far. The idea is, you have a picture of "the guy" pushing a box, with the side of the box having the level number on it.  I am going to extend the height of the box a bit, and put a lid of some sort on it. Also a bottom, and then the ground.  Finally, I'm going to add 48-pixel sprite routine top and/or bottom where I can put a bit of text, something like "SELECT//LEVEL"... or... something.

So... dog tired... work in progress... don't nit pick over pixels here and there

 

I like it, but as is normal with these things, you're often blind to the ugliness of your own creations.
 

[+Karl G]

I like it - it definitely adds flavor to the game.

[+Andrew Davie]

A mockup... give me a few days....

[Albert]

That's pretty cool.  The guy's legs should be moving, though, showing he's pushing the block!  But only as you are actually pushing the joystick to change the level.

 

 ..Al

[NostAlgae37]

19 hours ago, Andrew Davie said:

 

So... dog tired... work in progress... don't nit pick over pixels here and there

 

 

The color lines are off at the hands, neck and waist areas...    (Ducks to avoid flying objects.)    In all seriousness, I like the idea but agree with Al that the pushing animation should be included, if possible.

[+Andrew Davie]

Progress.... bugs and all... not sure if I like it any more

 

 

Edited August 31, 2019 by Andrew Davie

[+Andrew Davie]

Well, the NTSC version is mostly done. Here I show the two variants - arms up in the air in celebration - that's the normal "next level" screen. And when the guy is pushing against the box, that's the "select level" screen. I'll put some text up on those screens soon. And then I'll get it working in PAL. It's really ugly code.... just saying.... hackity hack hack....
 

[+Andrew Davie]

Here's a binary of the prototype selection/level screen. Should work for NTSC and PAL.

Right-difficulty to A for NTSC, and B for PAL. Stella defaults to B, so you might want to switch that, as the NTSC colours and screen ratio are nicer IMHO. I've also been working a bit on the sensitivity and responsiveness of the joystick. It's a tricky thing.

 

 

sokoboo_20190901.bin

[+Andrew Davie]

Been a journey the past few days, and I've not made much visible progress. But a lot has happened behind the curtains, and I've fixed/caught a few issues. I took a huge side-branch trying to get more happening on the screen - multiple background colour changes, etc... but in the end I just didn't have enough cycles available and reverted to earlier code. Still struggling with a stable screen on NTSC. I think the visuals (of the level screen) shown in the video is about as good as it's going to get. I'll release a binary in a day or two, once things are stable...

 

 

Edited September 3, 2019 by Andrew Davie

[Albert]

That's a very cool level display!

[+Andrew Davie]

Well, it turns out the screen instability I was hunting turns out to be a difference in Stella (release/beta) and how it interprets if the screen should roll or not. The beta thinks the screen should roll. The release has a different opinion. For now, I'm happy to release this binary, as most other things seem to be working OK. This has the selection screen pretty much done. Until I decide to change it. Again.

I'm not sure what to tackle next. The joystick responsiveness is still a hassle. I really need to get SaveKey function in. Also, perhaps some sort of "low score" table. To that end >> does anyone have some good high score table code that I can "borrow"? << . I'd prefer not to re-invent the wheel. Also, some 'venetian-blind' 12-character wide text routines would save me a lot of effort.

 

sokoboo_20190904.bin

[+Andrew Davie]

Clearly I don't feel like thinking much, so I've played with the colours instead. Here's a selection of colour combinations as used in the first 8 levels. It's quite hard to find combinations of 3 colours that look good, and in particular which (appear to) combine together into various combinations which ALSO look good, giving 8 "chronocolours". Anyway, this set is reasonably nice.

 

 

 

 

 

 

 

 

 

Edited September 6, 2019 by Andrew Davie
Because I hate this forum's editor.

[+FujiSkunk]

Remember, this is the Atari 2600.  You don't need realistic colors, just garish, super-saturated, highly-contrasting colors.

 

Either way, I think these look good, especially the fifth set, perfect for brick walls.

[+Andrew Davie]

I was hunting for nice screen colours (again), and decided just for the fun of it to choose three random colours at runtime. For those who don't know, the screen is composed only of single-colour scanlines, but the colour is varied on each scanline so that successive scanlines display A, B, C, A, B, C... where A and B and C are different colours. This "Interleaved Chronocolour (TM)" blends the colours and pixels on consecutive scanlines to give the impression of way more than the single colour that is actually on each scanline. 8, actually. Well anyway, A, B and C have to be very carefully chosen. Or... do they? I was extremely surprised after this experiment to see how many decent-looking screens actually came out of the random colour selection. And some quite suprising ones, too! For example, see 3:26. I'm going to have to figure out if I can get some of this randomness in the game. I might release the next binary with the randomness in, even though some of the levels may look poor. You can always hit reset to restart the level with new colours, i suppose

 

 

[RamrodHare]

I'm really thrilled about this game. I've been following along for a while now with the progress and it's amazing how you keep thinking of new things. This is going to be an excellent game and one I'm looking forward to playing.  

[NostAlgae37]

6 hours ago, Andrew Davie said:

Well anyway, A, B and C have to be very carefully chosen. Or... do they? I was extremely surprised after this experiment to see how many decent-looking screens actually came out of the random colour selection. And some quite suprising ones, too! For example, see 3:26.
 

Most of these look pretty interesting, but 3:26 is the worst by far because the walls are in almost total darkness and are nearly invisible!   

[+Andrew Davie]

One final bit of colour fun and I'll move on - I tried changing two of the three colours on every character line. Leaving the background 'ground' stripes unchanged. Here's a few screen grabs of some of the results. Interesting....

 

 

 

 

 

 

[NostAlgae37]

I like this a lot, it's actually kind of beautiful and gives that artificial "Atari-world" type of feel to the game.  But I'm not sure how others will feel about it, because it jumps the shark in terms of realism and they might prefer colors a bit more grounded in the natural world.

Edited September 8, 2019 by NostAlgae37
left out a word