Sokoban

[+FujiSkunk]

4 hours ago, Andrew Davie said:

You can see "me" frantically "running around" and touching files here and there.

 

You should make a game out of that...

[+sramirez2008]

6 hours ago, Andrew Davie said:

I'm finally back to "sexy". I spent some time working on the colour intensities and now have it pretty good. There are balancing constraints; you want things to be bright enough but not too bright, you want contrasts to be good but also colours have to mix properly. And it all has to work with randomly selected colours, and those colours need to mix right. And the mixes need to produce appreciably different colours that also look good. Anyway, fortunately most of the mixes look OK - even though random. I've upped the brightness on the background, and to my eye everything now looks hunky dory.  I've also tweaked the fades - slightly faster - and of course the extra brightness in the background gives it more steps which looks good too. So, I might leave this version here for a day or so and stop doing so many updates

Fingers crossed the video will look brighter, less clunky, and give a better impression of what it looks like on Stella.
 

sokoboo_20190911.bin 32 kB · 6 downloads

Gave this a quick whirl and found it to be a bit too bright. Interested in what others think.  Really like the fades.

 

BTW, playing via UnoCart and a good old CRT.

[+Karl G]

It looks great on Stella. I'll need a NTSC version before I can try it on my UnoCart to see how the latest version looks on real hardware to my eyes.

[+sramirez2008]

Forgot to mention that I'm experiencing screen roll (latest ROM) whenever I push a block.  Apologize for the video quality.

 

[alex_79]

39 minutes ago, Karl G said:

It looks great on Stella. I'll need a NTSC version before I can try it on my UnoCart to see how the latest version looks on real hardware to my eyes.

The right difficulty switch selects the TV format: A=NTSC B=PAL

[+Karl G]

Oh - I had missed or forgotten that.  Thanks.  ?

[+Andrew Davie]

2 hours ago, sramirez2008 said:

Forgot to mention that I'm experiencing screen roll (latest ROM) whenever I push a block.  Apologize for the video quality.

 

 

Soko Screen Roll.MOV 1.76 MB · 1 download

OK, thanks. I'll work on that!

 

[spspspsp]

I play on an NTSC CRT, and I am experiencing screen roll too. It doesn't happen every time, but seems to align with the pulsing of the border blocks.

 

Speaking of which, while I do like the "rainbow" in the background, I think the pulsating border blocks are a bit over the top. It makes it hard to concentrate on the puzzle.

[spspspsp]

The pulsating issue might be a bug that has creeped in since I don't see it mentioned anywhere in the thread. What is happening is that instead of just the small squares that indicate where boxes are to be pushed pulsing, the squares, the boxes, and the puzzle border are pulsing in sync with one another.

[+Andrew Davie]

1 hour ago, spspspsp said:

The pulsating issue might be a bug that has creeped in since I don't see it mentioned anywhere in the thread. What is happening is that instead of just the small squares that indicate where boxes are to be pushed pulsing, the squares, the boxes, and the puzzle border are pulsing in sync with one another.

 

That sounds like a bug with the fade code. I'll look into it!

 

[+Andrew Davie]

10 hours ago, sramirez2008 said:

Forgot to mention that I'm experiencing screen roll (latest ROM) whenever I push a block.  Apologize for the video quality.

 

 

Soko Screen Roll.MOV 1.76 MB · 1 download

That video appears to be showing the whole wall pulsing. That's not right. I missed it and thought it was just crappy filming/interaction with TV frame rate. If the walls are pulsing, as reported below... that's definitely a bug in the fade code. Strange it doesn't show up on stella but does on hardware. I have some hunting to do!!

[alex_79]

The pulsating walls are there in 6502ts/stellerator, Javatari and z26. So stella seems to be off in this case

[+Andrew Davie]

8 minutes ago, alex_79 said:

The pulsating walls are there in 6502ts/stellerator, Javatari and z26. So stella seems to be off in this case

Thanks. Confirmed here on Z26, too. So, I've found a Stella bug! That's interesting, I'll have to pass that on.

I think it's probably a non-initialisation of a variable rather than an emulator bug. The startup state of RAM is what's the difference.

It will be much easier to find now I have Z26 showing the failure happening. Expect a new binary soon.

 

[alex_79]

1 minute ago, Andrew Davie said:

Thanks. Confirmed here on Z26, too. So, I've found a Stella bug! That's interesting, I'll have to pass that on.

I opened an issue on github already.

 

[+Andrew Davie]

Thank you to those who have tested on hardware and given feedback. I do believe I've found and fixed the bug that was causing the pulsing of the wall colours. It was an interesting one - and actually two bugs for the price of one.  The first was a bug in my code where I forgot that I was writing to switchable RAM, and instead of writing to the write addresss, I was writing to the read address. Easy to do. But what was interesting was that Stella appears to have a bug where it actually allowed writing to the read address. So it worked in Stella, but not on hardware or some other emulators. And it was just lucky that the colours were pulsing and showing this - that was because the write in question was setting the destination colour for the fade, and the fade routine just happens to use zero as an initialisation value, and if your destination colour is also zero (which should never happen) then the fade-up code gets stuck in an endless loop. Anyway, two bugs effectively cancelling each other out - the bad write on my part, and the accepting of the bad write on Stella's part. Two writes make a wrong?

So, that's fixed, I think.

I have also as a quick-n-dirty increased the segment timing allocated to the man movement. This might help fix/reduce the roll that some have reported. That roll is basically because too much time is being taken by the man code - more than it "asked" for. So the solution is to either ask for a larger amount of time (this fix), or - better yet - split the man code into multiple sub-tasks which all take much less time, and then do them one by one. That's more programming work, but a much better approach. I might get to that in a day or two.

Meanwhile, here's a version with the bug-fix. I would appreciate any feedback on the result. I did test in Javatari and it seems OK.

 

 

sokoboo_20190911c.bin

Edited September 11, 2019 by Andrew Davie
minor update - nicer fade to black

[+Andrew Davie]

In the last version, there are still issues with colour fading - one of the colours occasionally does not fade in.

Please ignore that. I'll fix it soon. Gah.

 

[+Andrew Davie]

As an aside, I tested on the interesting "JAVATARI" emulator, which brings to mind many years ago I had an online slide-rule emulator which I called "JavaSlide". I got a cease-and-desist from lawyers for the owners of the Java trademark on that one, and they forced me to rename it. In protest I took it down instead. Bastards. Anyway, I wonder why "JAVATARI" didn't suffer the same fate. TWO trademarks in one!!

 

[+sramirez2008]

40 minutes ago, Andrew Davie said:

Thank you to those who have tested on hardware and given feedback. I do believe I've found and fixed the bug that was causing the pulsing of the wall colours. It was an interesting one - and actually two bugs for the price of one.  The first was a bug in my code where I forgot that I was writing to switchable RAM, and instead of writing to the write addresss, I was writing to the read address. Easy to do. But what was interesting was that Stella appears to have a bug where it actually allowed writing to the read address. So it worked in Stella, but not on hardware or some other emulators. And it was just lucky that the colours were pulsing and showing this - that was because the write in question was setting the destination colour for the fade, and the fade routine just happens to use zero as an initialisation value, and if your destination colour is also zero (which should never happen) then the fade-up code gets stuck in an endless loop. Anyway, two bugs effectively cancelling each other out - the bad write on my part, and the accepting of the bad write on Stella's part. Two writes make a wrong?

So, that's fixed, I think.

I have also as a quick-n-dirty increased the segment timing allocated to the man movement. This might help fix/reduce the roll that some have reported. That roll is basically because too much time is being taken by the man code - more than it "asked" for. So the solution is to either ask for a larger amount of time (this fix), or - better yet - split the man code into multiple sub-tasks which all take much less time, and then do them one by one. That's more programming work, but a much better approach. I might get to that in a day or two.

Meanwhile, here's a version with the bug-fix. I would appreciate any feedback on the result. I did test in Javatari and it seems OK.

 

 

sokoboo_20190911c.bin 32 kB · 1 download

I can confirm (on real HW) that the pulsing is fixed, the screen roll is fixed and the colors look really good.  Just realized that the pulsing is what made it appear too bright for me.

[+Andrew Davie]

22 minutes ago, sramirez2008 said:

I can confirm (on real HW) that the pulsing is fixed, the screen roll is fixed and the colors look really good.  Just realized that the pulsing is what made it appear too bright for me.

Thanks for testing/confirmation!

I did actually reduce the brightness of the BG stripes based on your feedback.

I should probably do another version with them back at the brighter intensity to see if that works, too.

 

[+Andrew Davie]

This fixes the occasional non-fading colour. It was when the random colour was colour #0 + intensity (any) - this clashed with my special use of "0" to flag an initialisation requirement for the fade code. Anyway, hopefully that's the last of the fade issues.

 

sokoboo_20190911d.bin

 

I have also made some minor changes to the background rainbow intensities, in an effort to even them out. In the previous version the rainbow background did not scroll when you did a look-around. This version does.

Edited September 11, 2019 by Andrew Davie

[christo930]

On 7/14/2019 at 9:39 AM, Andrew Davie said:

I reckon I could have a working playable version in under a week

But the real question is WHY?

[+Andrew Davie]

Quote

“Some men see things as they are and say why—I dream things that never were and say why not.”
― George Bernard Shaw

 

[adamchevy]

Wow, this looks really good!!!! So cool to see Rockford playing the Sokoban game [emoji846] 

Good to see you coding the '2600 again, Andrew!

 

And too bad that I joined AtariAge only 1.5 years ago, so I missed the opportunity to buy Boulder Dash for the '2600 (which was one of my favorite games on the C64)

 

If you ever get the chance to buy a copy of boulder dash for the 2600, take my advice cherish it.

[alex_79]

19 hours ago, Andrew Davie said:

I have also made some minor changes to the background rainbow intensities, in an effort to even them out. In the previous version the rainbow background did not scroll when you did a look-around. This version does.

 

In case it looks still too bright on a real CRT (I can only test in Stella+LCD, and it looks fine there), did you consider changing the "character" for the background to some different pattern? In that way, you could reduce the perceived brightness without having to actually change the colors.

 

[+Andrew Davie]

This is a NTSC-only version.

I have spent quite some time working on the visuals - in particular, the colour usage and contrasts, some modifications to the characters themselves as well. I've also worked on a bit of code to optimise the intensities so that they are all roughly the same for each colour. It's looking OK now. I need to do all this for PAL, but for now here's the latest NTSC version.

 

sokoboo_20190912_NTSC.bin