Boulder Dash Forum

Wish you to relax and gain more energy, enjoy beautiful rockery landscapes, fireflies and butterflies!

Thanks! Back from vacation now!

As an amoeba that wasn't stopped, I will drop some rocks, while you're away.

Let's have a look at those new posts!

In parallel, I have launched Marek Roth's tutorial, you've just mentioned, to observe the multi-rockford cave 09 and: boom — "?" signs again

upd: There are plenty of the "?" in other caves of this levelset, as well.

upd: All the times I faced "?" it meant to be jewels.

Indeed, and there are still some other elements that are also not covered by the current code.

I plan to cover all missing elements with the next release.

You've mentioned <=0 values, but you can't put a negative value in RnD GDash cave creator. Has this to be fixed then?

Yes, this is currently not supported by the R'n'D editor and has to be fixed for those BD levels that use it (or new ones that should use it).

Can you please add support for light boulders?

As far as I know, this is a game element from the Krissz BD engine, which is closed source, so adding it to the GDash engine would require testing all possible cases of interaction with other GDash game elements in the Krissz engine (that are also implemented in this engine), without being easily able to test-play caves created in the Krissz engine with the GDash engine (after adding the light boulder element), as also the existing caves for the Krissz engine are not publicly available for download. Plus, as altermaven already wrote, it would be tough to add that new element consistently to the GDash engine (that is, without breaking things). Nevertheless, it should not be impossible, but would be a task for the time when the GDash engine in R'n'D is stable and fully working.

The Lost Caves 10, cave 16 (intermission)

How do you make intermissions look like this one, cut from the sides, not observable whole:
...
While actually they look like this in cave editor:
...
And when you test them in editor, they look big like this.

There is a flag and also clipping coordinates to detect and display intermission caves in BD cave files, used to clip the visible area when playing, while the whole (standard sized) cave is displayed in the level editor (without clipping).

However, when playing from the level editor, only the intermission flag is available, but not the clipping coordinates (which, as far as I can tell, are not used by any existing cave set, at least those in BDCFF format), so when playing from the level editor, the whole cave is displayed. I'm looking for a workaround to play those caves just like usually, but for newly created intermission levels, it might be desired to really use different (non-standard) cave sizes, so this must somehow be solved.

What is the difference between "exit" and "save & exit" after triggering settings? As far as I see, "exit" saves changes for the current session only, but if you exit the game, the changes then won't be saved. Is that how it is intended to work?

Yes, exactly. But I must admit that it might be unexpected behavior when one is used to modern settings dialogs (which usually immediately take effect and are also saved / persisted).

Because I sometime toggle settings and then press "esc" a few to times to get to the main menu as soon as possible and then face old settings after the restart.

Because they have been changed, but the changes were not permanently saved.

I mean, is there any situation when I want to toggle something and not to save the new settings permanently?

Yes. At least theoretically, graphical changes (like selecting broken graphics sets) might leave the game in an unusable state, so exiting and restarting would fix things (if the changes were not saved).

I'm currently testing Super Boulder Dash by Chaos and some of his levels seem unsolvable due to some changes in timing.

Here, take cave 015 (intermission)
...
When played in RnD GDash it just moves too fast. Not like in the video of a successful run here:
https://youtu.be/dSvhPveZjPE?si=bPt-EqwOi6fbeEk0&t=754

This problem exists in both the original GDash game and the GDash engine in R'n'D. The problem is that the bottom explosion is halted in the original game during hatching, while it immediately continues (followed by falling diamonds) in the GDash engine.

This is a special case that has to be detected and handled differently (that is, fixed) in the GDash engine.

Just to be sure engine works as intended in GDash, because I cannot test it in the original GDash, please check:

A set of 6 jewels are falling and rockford using snap left to collect jewels mid-fall while they fall of the boulder to left.
...
In RnD Gdash player would collect the 2nd, 4th and 6th. While missing the 1st, 3rd and 5th. Is it like in original?

At least it works exactly the same in the original GDash game and in the GDash engine used in R'n'D.

I haven't tested how this works in the original game engine on the C64. Has anybody else tested this?

This is the second in the row question, that I can't test myself in original gdash, so excuse me if that isn't a bug and it's just how it meant to be played.

This is the cave 14 in Arno Dash 16. It's a fun room where much depends on randomness of falling objects through slime. I've died plenty of times and noted that every time you play it again, the same pattern of falling objects repeats every time. Why is it applying the same seed again, I believed that boulder dash is all about random generation and unpredictableness? Is it like this in original or is it only happens in RnD?

At least for slime, there is a setting regarding "predictability", that is used to explicitly use the same random seed for the behavior of slime in every instance of playing a game. That is, this is not a bug, but a feature.

Caves can be created with or without predictable slime by using this flag; its default value, however, is "use predictable slime".

artsoft wrote: ↑Fri Aug 09, 2024 5:26 pm

Can you please add support for light boulders?

As far as I know, this is a game element from the Krissz BD engine, which is closed source, so adding it to the GDash engine would require testing all possible cases of interaction with other GDash game elements in the Krissz engine (that are also implemented in this engine), without being easily able to test-play caves created in the Krissz engine with the GDash engine (after adding the light boulder element), as also the existing caves for the Krissz engine are not publicly available for download. Plus, as altermaven already wrote, it would be tough to add that new element consistently to the GDash engine (that is, without breaking things). Nevertheless, it should not be impossible, but would be a task for the time when the GDash engine in R'n'D is stable and fully working.

Light boulders are actually very easy to add and only require minimal testing. They are merely standard boulders with the delay factor of 0 (so, the boulder is moved immediately without any delay, which makes it possible to move it right across gaps). A light boulder behaves exactly as a standard boulder would provided that the delay is zero. I researched Krissz's Engine in the past when I was still registered on the site, and managed to make a compatible Python clone in the form of an updated BoulderCaves fork, you can check out here if you're interested, it includes some Krissz's Engine caves as well: https://github.com/Agetian/bouldercaves
The graphic for the Light Boulder is a simple slightly squished (2px, for memory) standard Boulder. The graphic is included in my port if you're interested as well. I did some extensive testing in the past and I can confirm that the Light Boulder behaves the same as it would on Krissz's website. Some light boulder-based caves are included with the port, too. All of the interesting side effects of this element (e.g. being able to freely move it across gaps to the right but not to the left, since it'll fall down into the gaps when moved in the left direction) come naturally from the game's cave scanning order peculiarities, so as long as CSO is implemented correctly, the Light Boulder should work fine (and as desired) as well, it doesn't need any special "exceptional" treatment. There are also no special interactions for this element that would need additional and separate support.

Sadly, to get my fork to run correctly these days, you may need an older version of the audio library it uses, the latest versions produce choppy sounds for whatever reason. Can't remember what version it was off the top of my head, maybe 2.5... I haven't gotten back to it in quite a while.

On a side note, it's actually very unfortunate that Krissz's Engine is still not open source (and moreover, you have to sort of be in the "in circle" to even know about the game, let alone get a chance to play it), and none of the caves exclusive to the Krissz's site have been released in any publicly available way, with the author seemingly still insisting on the community being closed and somewhat "secretive", I'd say. I know I'll be sad when all of this incredibly legacy (of thousands and thousands of unique high quality caves) goes down when something happens to the resource or when its author loses interest in supporting it any further. But oh well.

Anyways, back on track - if you're interested, light boulders are indeed an easy thing to implement The much harder thing to implement properly (from Krissz Engine features) would be the infinitely scrolling caves, a unique feature of Krissz's Engine which I tried to somewhat replicate in my port with mixed results (it works correctly but it's jerky and slow on Python, even when using an optimized implementation like Pypy). I haven't seen any other BD implementation with that feature to this day and it's kinda sad that it remains unique only to a highly closed game implementation with highly limited availability. The maps built around the feature are some of the most unique and unusual I've played in any BD game.

P.S. Kudos to you for integrating a true BD engine to Rocks'n'Diamonds! It's great to finally see a proper compatible engine implemented in R'n'D, I'm a huge fan of your game! GDash was an amazing choice for the BD engine, I'd say the best one out there available publicly.

- Agetian

igormakovsky wrote: ↑Sat Aug 03, 2024 11:49 am

In RnD Gdash player would collect the 2nd, 4th and 6th. While missing the 1st, 3rd and 5th. Is it like in original?

This is expected behavior and might be a good candidate for those Cave Scanning Order threads:
https://www.boulder-dash.nl/forum/viewtopic.php?t=652 and
https://www.boulder-dash.nl/forum/viewtopic.php?t=639

Light boulders are actually very easy to add and only require minimal testing.

Yes! Moreover, they're already present!
It's a common rock with push probability equals 100:



This is screencast video I've made:
https://igormakovsky.com/asmysl/bd.mp4

Then why not add heavy boulders, as well? (Push probability equals 0)

When playing some fast paced caves with lots of amoeba I'm observing a slight, yet visible lack of fps, when amoeba grows too big.

It is clearly visible at the moment amoeba turns to rocks and engine starts run perfectly smooth again.

Cycle delay has to be: 0

Just like a reference or an example:


Cave can be something like that, or you can add more moving objects in the cave or make it larger.

I'm playing on m1 max, so that isn't about processor limits or such.

Agetian wrote: ↑Sun Aug 11, 2024 9:18 am

artsoft wrote: ↑Fri Aug 09, 2024 5:26 pm

igormakovsky wrote:Can you please add support for light boulders?

...

Light boulders are actually very easy to add and only require minimal testing. They are merely standard boulders with the delay factor of 0 (so, the boulder is moved immediately without any delay, which makes it possible to move it right across gaps). A light boulder behaves exactly as a standard boulder would provided that the delay is zero.

Very good to know! So light boulders could either be directly created in the R'n'D or GDash level editor by changing the normal boulder's push probability (as shown by igormakovsky), or (to be able to have both types of boulders in the same level) it could easily be added as a separate game element, with just the push probability changed accordingly.

igormakovsky wrote:Then why not add heavy boulders, as well? (Push probability equals 0)

Agetian, do you know if the "heavy boulder" from the Krissz engine behaves the same as the "mega stone" from GDash? Is it also just the different push probability? If so, it would already be there! If not, it would be interesting if there are other differences which would have to be emulated to get a Krissz style "heavy boulder".

Sadly, to get my fork to run correctly these days, you may need an older version of the audio library it uses, the latest versions produce choppy sounds for whatever reason. Can't remember what version it was off the top of my head, maybe 2.5... I haven't gotten back to it in quite a while.

Apparently that's indeed the show stopper for running it on my Mac at the moment. Installing "Tkinter" using "brew" was easy ("brew install python-tk"), but when starting it (using the file "launcher.py"), it complains about not being able to find the required sound libraries. Is it possible to start it without sound? Or do you know how to install what's required for having sound in Python (may it be choppy or not)?

On a side note, it's actually very unfortunate that Krissz's Engine is still not open source (and moreover, you have to sort of be in the "in circle" to even know about the game, let alone get a chance to play it), and none of the caves exclusive to the Krissz's site have been released in any publicly available way, with the author seemingly still insisting on the community being closed and somewhat "secretive", I'd say. I know I'll be sad when all of this incredibly legacy (of thousands and thousands of unique high quality caves) goes down when something happens to the resource or when its author loses interest in supporting it any further. But oh well.

Cannot agree more here! That's why all things R'n'D are open and freely available, so everybody can take the code and everything else and do a fork or whatever (as it has been done with the GDash code more than once, for example). (OK, what's still missing for R'n'D to be fully open with *really* everything is releasing the PHP code for the high score server and provide something like a nightly dump of the score database and tapes directory, which is indeed planned for the future.)

Anyways, back on track - if you're interested, light boulders are indeed an easy thing to implement

Yes, I'll do that!

The much harder thing to implement properly (from Krissz Engine features) would be the infinitely scrolling caves, a unique feature of Krissz's Engine which I tried to somewhat replicate in my port with mixed results (it works correctly but it's jerky and slow on Python, even when using an optimized implementation like Pypy). I haven't seen any other BD implementation with that feature to this day and it's kinda sad that it remains unique only to a highly closed game implementation with highly limited availability. The maps built around the feature are some of the most unique and unusual I've played in any BD game.

Sounds interesting -- so apparently this is not the usual "wrap around" feature, but the cave is handled as if it would have no borders, seamlessly scrolling around and around if you move up, down, left or right? Any YouTube videos available of such caves running with the Krissz engine?

P.S. Kudos to you for integrating a true BD engine to Rocks'n'Diamonds! It's great to finally see a proper compatible engine implemented in R'n'D, I'm a huge fan of your game! GDash was an amazing choice for the BD engine, I'd say the best one out there available publicly.

Thanks! And yes, I also think that the GDash engine is currently the best BD engine available, especially as it has a huge library of caves available ready to play with it, which is great to test if everything works as it should inside R'n'D (being able to easily compare everything to original GDash side by side)!

igormakovsky wrote: ↑Fri Aug 16, 2024 11:15 am When playing some fast paced caves with lots of amoeba I'm observing a slight, yet visible lack of fps, when amoeba grows too big.

It is clearly visible at the moment amoeba turns to rocks and engine starts run perfectly smooth again.

Cycle delay has to be: 0

Just like a reference or an example:
...
Cave can be something like that, or you can add more moving objects in the cave or make it larger.

I'm playing on m1 max, so that isn't about processor limits or such.

Processor should not be a problem here, but the GDash engine supports dynamically variable game cycle delay to emulate the original C64 behavior (which could get slower or faster depending on the type and number of game elements in a cave).

So, for the level displayed above, could you please have a look at the "scheduling type" in the level editor ("CONF" -> "Engine" -> "Config")?

When setting this to "Milliseconds", you should not encounter any delays or slowdowns, but a constant game engine speed, while the other settings might indeed result in visible changes of game speed.

When setting this to "Milliseconds", you should not encounter any delays or slowdowns

Yes, it's just how you said! Thanks!

I can hardly name a right color through RRGGBB format in editor.

Can you, please, add some color palette, like in Photoshop, where you can choose the right color with a cursor?

artsoft wrote: Very good to know! So light boulders could either be directly created in the R'n'D or GDash level editor by changing the normal boulder's push probability (as shown by igormakovsky), or (to be able to have both types of boulders in the same level) it could easily be added as a separate game element, with just the push probability changed accordingly.

Yep, Krissz Engine caves that have light boulders typically have standard and/or heavy boulders as well, so it's best to add it as a separate element Is it possible to tweak the graphic as well to make it distinct?

artsoft wrote: Agetian, do you know if the "heavy boulder" from the Krissz engine behaves the same as the "mega stone" from GDash? Is it also just the different push probability? If so, it would already be there! If not, it would be interesting if there are other differences which would have to be emulated to get a Krissz style "heavy boulder".

Pretty sure it's the same as the mega boulder, a boulder you can't push at all because its delay probability is 100, but I can check the BoulderCaves source when I'm back from vacation on Monday

Apparently that's indeed the show stopper for running it on my Mac at the moment. Installing "Tkinter" using "brew" was easy ("brew install python-tk"), but when starting it (using the file "launcher.py"), it complains about not being able to find the required sound libraries. Is it possible to start it without sound? Or do you know how to install what's required for having sound in Python (may it be choppy or not)?

Do you know if you can get pip installed on a Mac? (It's a package manager for Python). If it's possible to do that, you can easily install miniaudio and synthplayer packages using pip, which should satisfy the requirement for the audio. If that's not possible, let me know and we can think some more

Cannot agree more here! That's why all things R'n'D are open and freely available, so everybody can take the code and everything else and do a fork or whatever (as it has been done with the GDash code more than once, for example). (OK, what's still missing for R'n'D to be fully open with *really* everything is releasing the PHP code for the high score server and provide something like a nightly dump of the score database and tapes directory, which is indeed planned for the future.)

Totally! This also ensures survivability for GDash imo as I believe the original is no longer in development:)

Sounds interesting -- so apparently this is not the usual "wrap around" feature, but the cave is handled as if it would have no borders, seamlessly scrolling around and around if you move up, down, left or right? Any YouTube videos available of such caves running with the Krissz engine?

Yes, indeed, the cave looks and scrolls seamlessly in all directions, but the cave scanning order is unaffected, so it still scans the cave normally, which causes some interesting side effects on the unseen borders - something that a lot of caves utilizing this feature exploit in various creative ways
Speaking of which, I have a lot of research data still stashed in my backups, including detailed info on how infinite scrolling works and other features of the engine. I stored it exactly in the hopes that I would eventually meet someone interested who would be able to use that practically. If you're interested, I can PM you the details. This will be better than guesstimating these features via videos imo Let me know if it's alright to PM you.

Thanks! And yes, I also think that the GDash engine is currently the best BD engine available, especially as it has a huge library of caves available ready to play with it, which is great to test if everything works as it should inside R'n'D (being able to easily compare everything to original GDash side by side)!

Indeed! Now I can have the perfect engines for BD , Supaplex, and Emerald Mines all in one place

- Agetian