Rocks'n'Diamonds with GDash game engine

[artsoft]

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?

Yes, I know, this is currently less than inconvenient.

Maybe I will add a color picker one day (maybe with support for selected color palettes, like Atari colors etc.).

Until then, a workaround would be to use a color picker that displays the RGB values of the chosen color... Maybe I should just check if there is a color picker written in C using SDL that I can readily add to the level editor.

[artsoft]

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?

Yes, I would then just use the "light boulder" graphics from BoulderCaves+.

Agetian, do you know if the "heavy boulder" from the Krissz engine behaves the same as the "mega stone" from GDash?

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

Cool. So I should probably change the element's name from "mega ..." to "heavy ..." to make it more clear what those rocks/boulders/stones do.

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

I managed to force installing those python libraries that are not available in Homebrew, and BoulderCaves+ now runs (more or less fine, but indeed with bad sound).

However, I can only run the default "Boulder Dash" level set, but not any other set, as this gives a long Python error message, which effectively is this error:

Code: Select all

    with open(filename, "rU") as f:
         ^^^^^^^^^^^^^^^^^^^^
ValueError: invalid mode: 'rU'

Not sure what's going wrong here...

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

That's right, so it is cool that others were able to fork it and continue development!

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.

Definitely yes! Feel free to send me anything interesting via PM, or use the mail address at artsoft.org .

[Agetian]

Yes, I would then just use the "light boulder" graphics from BoulderCaves+.

Good idea, by all means go for it

Cool. So I should probably change the element's name from "mega ..." to "heavy ..." to make it more clear what those rocks/boulders/stones do.

Yeah, probably either name would be fine I'll confirm in a couple days if the heavy boulder is the same as mega functionally, too.

I managed to force installing those python libraries that are not available in Homebrew, and BoulderCaves+ now runs (more or less fine, but indeed with bad sound).

However, I can only run the default "Boulder Dash" level set, but not any other set, as this gives a long Python error message, which effectively is this error:

Code: Select all

    with open(filename, "rU") as f:
         ^^^^^^^^^^^^^^^^^^^^
ValueError: invalid mode: 'rU'

Not sure what's going wrong here...

Yep, the bad sound issue can be fixed by downgrading miniaudio. Sadly, I don't remember which version worked, I want to say 2.5 or 2.3 but I'm not sure

Oh, the crash should be easily fixed by replacing rU with just r, the U mode was deprecated and I guess removed in the recent Python

Definitely yes! Feel free to send me anything interesting via PM, or use the mail address at artsoft.org .

Will do I'll e-mail you what I have (the research notes etc.) when I'm back in town in a couple days! Will be happy to cooperate if you need any further help or explanations.

- Agetian

[artsoft]

I'll confirm in a couple days if the heavy boulder is the same as mega functionally, too.

Cool, thanks!

Yep, the bad sound issue can be fixed by downgrading miniaudio. Sadly, I don't remember which version worked, I want to say 2.5 or 2.3 but I'm not sure

Currently, I use these library versions:

Code: Select all

$ python3 -m pip install soundcard
Collecting soundcard
  Using cached SoundCard-0.4.3-py3-none-any.whl.metadata (13 kB)
...
Successfully installed cffi-1.17.0 numpy-2.0.1 pycparser-2.22 soundcard-0.4.3

$ python3 -m pip install sounddevice
Collecting sounddevice
  Using cached sounddevice-0.5.0-py3-none-macosx_10_6_x86_64.macosx_10_6_universal2.whl.metadata (1.4 kB)
...
Successfully installed sounddevice-0.5.0

$ python3 -m pip install miniaudio
Collecting miniaudio
  Using cached miniaudio-1.61-cp312-cp312-macosx_11_0_arm64.whl.metadata (25 kB)
...
Successfully installed miniaudio-1.61

$ python3 -m pip install synthplayer
Collecting synthplayer
  Using cached synthplayer-2.5-py3-none-any.whl.metadata (7.2 kB)
...
Successfully installed synthplayer-2.5

Oh, the crash should be easily fixed by replacing rU with just r, the U mode was deprecated and I guess removed in the recent Python

I already guessed that, too, and changed it accordingly. Loading BDCFF files works fine now!

(The only affected file was "bouldercaves/bdcff.py".)

I'll e-mail you what I have (the research notes etc.) when I'm back in town in a couple days! Will be happy to cooperate if you need any further help or explanations.

Thanks a lot! This could all be very useful if one day I should decide that R'n'D urgently needs a Krissz compatible BD engine.

But joking aside, I will be happy if I manage to get the GDash based BD engine perfectly working and fully integrated into R'n'D, and I think it will be the last "native engine" to be added to R'n'D.

Regarding the Krissz BD engine: As far as I can tell (not being a registered user at the moment), there is quite a huge number of caves available for this game engine, but apparently there is no way to download them or otherwise access them in a way that they could be played in any other game engine. (And yes, I have read what you have tried to achieve and what happened when you tried to access those caves, which is really a pity. )

Nevertheless, with BoulderCaves+, there is an open source game engine available which apparently is at least close to the original engine, so if there should ever be a situation where all those caves are freely accessible, it would also be possible to not only play them in BoulderCaves+, but also be able to port the current Python code to extend existing BD engines like GDash to maybe also support Krissz style BD levels (either by extending the engine itself, or, more likely, by adding an alternative BD engine to play all those caves).

And don't hurry, but enjoy your holidays!

[Agetian]

Nice, glad you got the game working! Pretty sure MiniAudio is the culprit when it comes to the choppy sound, I'll experiment with it when I'm back, can't remember the version number...

Yes, there's a ton of caves in that engine I'll tell you everything I know soon, just in case you need it some day and find some use for it. There's quite a lot of info I was able to gather while I was registered, hehe. If anything, it might provide some insight into the functionality of high quality contemporary BD engines and might be a good source of info for some additional features that might be of eventual interest.

Thanks a lot! I'll get back to you soon

- Agetian

[Agetian]

Alright, I sent you all the info that I have, please let me know if it reached you. Most of it may not be very relevant to your current developments since you're targeting GDash in terms of compatibility (and, as I observed before, rightly so), but there are a few features you may want to eventually integrate, so I'm happy to share my findings with you. There's one feature of Krissz Engine that's quite universal and that may be relevant to you as well (and I haven't mentioned it in my e-mail, so I'm mentioning it here): Krissz Engine is the only engine I'm aware of (choosing from C64, GDash and BoulderCaves[+] ) that gets the timing of the game perfectly right. What I mean is the following: if you set up a test map (standard 40x22 stuff) filled with dirt and start moving Rockford, eating the said dirt, in GDash you'll notice that the sound of Rockford eating dirt is uneven (sometimes it'll be exactly rhythmic but sometimes there will be steps that will sort of "break out" and "break the rhythm"). Basically, not all steps take exactly the same time in GDash (and the same is true for BoulderCaves and also even the original C64 games). In Krissz Engine, the time between steps is always the same provided that your PC can run the game fast enough (and basically any contemporary PC can do that, obviously). This makes it possible to treat BD almost as a rhythm game of sorts, where you can rely on the sound of steps in figuring out when you can move next (and when you can't). This makes it a lot easier to speedrun caves (since timing is predictable), which makes Krissz Engine about the only engine I'm aware of that's good for "pro level" Boulder Dash where you'd need to time things perfectly. I tried to fix this issue in BoulderCaves+ but I was never able to figure out what's causing it and how to fix it exactly. I'm not sure how GDash engine behaves in Rocks'n'Diamonds, but if this wasn't fixed yet, it may be a good thing to look into (not sure if you'd want to introduce it as an option or just the default, I'd say it should just be the default behavior and the steps should always be evenly timed if possible).
Hope this helps!

- Agetian

[artsoft]

Alright, I sent you all the info that I have, please let me know if it reached you.

It did! Just wrote a quick answer to confirm this. It's indeed a lot of information that's highly valuable when trying to emulate existing game engine behavior (even though the focus is currently on the GDash engine, but support for certain aspects of the Krissz engine might be useful at a later stage).

There's one feature of Krissz Engine that's quite universal and that may be relevant to you as well (and I haven't mentioned it in my e-mail, so I'm mentioning it here): Krissz Engine is the only engine I'm aware of (choosing from C64, GDash and BoulderCaves[+] ) that gets the timing of the game perfectly right. [...] Basically, not all steps take exactly the same time in GDash (and the same is true for BoulderCaves and also even the original C64 games). In Krissz Engine, the time between steps is always the same [...] I'm not sure how GDash engine behaves in Rocks'n'Diamonds, but if this wasn't fixed yet, it may be a good thing to look into (not sure if you'd want to introduce it as an option or just the default, I'd say it should just be the default behavior and the steps should always be evenly timed if possible).

First of all, the GDash engine in R'n'D should behave exactly the same as in standalone GDash.

That said, cave timing is indeed a very interesting aspect of the game engine, and I know that the original author of GDash has put quite an effort to emulate it as close to the original as possible (that is, the original game on the Atari and C64).

And that's indeed the reason for the "uneven" timing of the game engine when playing most classic caves -- also see the post above regarding caves with lots of amoeba not running smoothly. The reason is that, on the C64, certain game elements (like the amoeba) required more CPU cycles than other (simpler) game elements, possibly slowing down the engine depending on game elements in the cave.

GDash apparently emulates this quite accurately, even for different cases like platforms (Atari, C64) and programs (BD1, BD2 etc.). This can be found in the "scheduling type" setting of the engine in the level editor.

However, there's also the scheduling type "milliseconds", which should guarantee a constant engine speed, regardless of the type of game elements on the playfield.

So my assumption is that the Krissz engine (probably having a focus on newly created games) simply does not bother with perfect speed compatibility of classic caves (which it also includes and which can be played with it, if I'm not wrong).

You can simply test this: Load the classic BD game into GDash (or R'n'D) and play with both the cave-specific (non-smooth) scheduling type settings, and the settings changed to "milliseconds". That should make the difference regarding slighly choppy or constantly smooth game engine speed and player movement.

So, in the end, "perfectly right timing" depends on what you want to achieve.

The default scheduling type for newly created caves in GDash (and R'n'D with GDash engine) should always be "milliseconds" (and a game cycle delay of 160 milliseconds for perfectly smooth player movement and scrolling).

[Agetian]

That said, cave timing is indeed a very interesting aspect of the game engine, and I know that the original author of GDash has put quite an effort to emulate it as close to the original as possible (that is, the original game on the Atari and C64).
And that's indeed the reason for the "uneven" timing of the game engine when playing most classic caves -- also see the post above regarding caves with lots of amoeba not running smoothly. The reason is that, on the C64, certain game elements (like the amoeba) required more CPU cycles than other (simpler) game elements, possibly slowing down the engine depending on game elements in the cave.
GDash apparently emulates this quite accurately, even for different cases like platforms (Atari, C64) and programs (BD1, BD2 etc.). This can be found in the "scheduling type" setting of the engine in the level editor.
However, there's also the scheduling type "milliseconds", which should guarantee a constant engine speed, regardless of the type of game elements on the playfield.

Oh, that's very interesting! I wasn't aware of what exactly the different scheduling types do, now it makes sense Thanks a lot for clarifying this aspect!

So my assumption is that the Krissz engine (probably having a focus on newly created games) simply does not bother with perfect speed compatibility of classic caves (which it also includes and which can be played with it, if I'm not wrong).
You can simply test this: Load the classic BD game into GDash (or R'n'D) and play with both the cave-specific (non-smooth) scheduling type settings, and the settings changed to "milliseconds". That should make the difference regarding slighly choppy or constantly smooth game engine speed and player movement.
So, in the end, "perfectly right timing" depends on what you want to achieve.
The default scheduling type for newly created caves in GDash (and R'n'D with GDash engine) should always be "milliseconds" (and a game cycle delay of 160 milliseconds for perfectly smooth player movement and scrolling).

Indeed, Krissz's Engine doesn't seem to aim at perfectly recreating any particular classic BD. Thus, it's made to look and behave very similar to a classic BD game (both tile set-wise and when it comes to cave scanning order, at least in the New Engine), but it doesn't reflect the scheduling types of the older C64 / Atari titles. It's using constant timing, so I'm assuming it must implement millisecond-based scheduling (and manages to do it very well, too). The classic BD1/2 caves were made for Krissz Engine in the past (both the old one and the new one), they play very well in that engine but they're definitely not frame by frame compatible with the original BD1/2 behavior on C64 or Atari

- Agetian

[igormakovsky]

Been playing BD3 with space tileset, while toggle smooth moving on.

Noticed that snapping, which replaces the tiles with "space" looks pretty confusing when something is drawn in it:
Space (empty) sprite being moving towards the direction of snapping. That's not a bug, that's just how RnD smooth engine deals with growing elements, like moving walls, amoeba, etc. It looks OK with literally empty space, yet a bit confusing when something is put on it, like, say, stars in this case.

Here's video of what I mean: https://igormakovsky.com/asmysl/bd-space.mp4

[LogicDeLuxe]

The biggest difference on classic scheduling is between BD1 and BD2. In BD1, there is just a delay loop wasting a predetermined number of cycles, depending on the level, thus it is very dependent on what's going on in the cave. This is also the reason, intermissions are significantly faster, since those have the cavescan reduced to 12 lines, iirc.
From BD2 on, the delay is based on TV field counts. Most of the time, the engine can keep up with a delay of 5 or 6 to keep a steady timing. Less than 5 doesn't increase the speed any further, as this is about the time the game needs for the cave scan without a CPU turbo (interrupts included).
GDash calculates the proper delay from all of this when those classic scheduling types are in use.
This is also why a CPU turbo has a ridiculous effect on BD1 and barely any on BD2 onwards.
There are some measurements on that somewhere on this forum.

[artsoft]

The classic BD1/2 caves were made for Krissz Engine in the past (both the old one and the new one), they play very well in that engine but they're definitely not frame by frame compatible with the original BD1/2 behavior on C64 or Atari

Indeed, most of these caves of the classic BD games still play very well even if not perfectly emulated (with a few exceptions), which IMHO shows their quality -- but this depends of what you like to play, of course. If you like puzzles and action that's not timed to frame-exact movement, they work very well, while newly created caves for the Krissz engine apparently do exactly that (requiring frame-accurate game play).

[artsoft]

Been playing BD3 with space tileset, while toggle smooth moving on.

Noticed that snapping, which replaces the tiles with "space" looks pretty confusing when something is drawn in it:
Space (empty) sprite being moving towards the direction of snapping. That's not a bug, that's just how RnD smooth engine deals with growing elements, like moving walls, amoeba, etc. It looks OK with literally empty space, yet a bit confusing when something is put on it, like, say, stars in this case.

Here's video of what I mean: https://igormakovsky.com/asmysl/bd-space.mp4

You are perfectly right here, and your demo video shows this graphical glitch very well.

I have changed how snapping diggable game elements looks like now, so the "empty space with stars" in BD3 do not move towards snapping direction anymore (which indeed looks wrong here, as those stars should not move), but will be changed to the background graphics without moving now.

Thanks for reporting this small, but nasty looking graphical bug.

[artsoft]

The biggest difference on classic scheduling is between BD1 and BD2. In BD1, there is just a delay loop wasting a predetermined number of cycles, depending on the level, thus it is very dependent on what's going on in the cave. This is also the reason, intermissions are significantly faster, since those have the cavescan reduced to 12 lines, iirc.
From BD2 on, the delay is based on TV field counts. Most of the time, the engine can keep up with a delay of 5 or 6 to keep a steady timing. Less than 5 doesn't increase the speed any further, as this is about the time the game needs for the cave scan without a CPU turbo (interrupts included).
GDash calculates the proper delay from all of this when those classic scheduling types are in use.
This is also why a CPU turbo has a ridiculous effect on BD1 and barely any on BD2 onwards.
There are some measurements on that somewhere on this forum.

Thanks for this interesting insight into the inner workings of the classic BD engines, which explains very well why it is required to have those different scheduling types (and how it works!) for better emulation of the classic BD caves!

[igormakovsky]

Thanks for reporting this small, but nasty looking graphical bug.

Thank you very much. Actually, I disliked this space theme very much, been fan of original BD design with clear empty spaces. But, anyway, I appreciate for your attention towards such small details.

[Agetian]

Indeed, most of these caves of the classic BD games still play very well even if not perfectly emulated (with a few exceptions), which IMHO shows their quality -- but this depends of what you like to play, of course. If you like puzzles and action that's not timed to frame-exact movement, they work very well, while newly created caves for the Krissz engine apparently do exactly that (requiring frame-accurate game play).

Agree about the originals As for the Krissz Engine caves, not all of them require frame level precision, of course, but some of them do, yes, particularly the ones that are designed around the cave scanning order effects and are designed as puzzles for those who are well aware of the side effects of the cave scanning algorithm. That said, there were many easier caves too which did not require frame-level precision or even cave scanning order knowledge.

- Agetian