Rocks'n'Diamonds with GDash game engine

[Agetian]

Grats on getting 4.4.0.0 released, Holger! it's a really nice milestone release and I'm happy you've seen the project through to completion!
I have a little report based on playing the latest release. It seems like the sound priorities and/or sound mixing is incorrect sometimes, which causes certain sounds to be skipped completely. This is easily seen, for example, in the Firefox 01 level set, cave 3, where you have a lot of expanding walls. As you move around and the walls expand (while you eat dirt and collect diamonds), you'll notice that a lot of the "wall expanding" sounds are missing and the walls expand silently. If you compare it to the reference GDash implementation, you'll see that all the expanding wall sounds are heard in the original implementation. Not having these sounds is slightly disorienting, as in this game you have to rely a lot on the audio hints to figure out what's happening when (almost as if you're in a rhythm game ). Hope this is easy enough to fix

P.S. This seems to affect other sounds too, but it's more difficult to consistently reproduce. For example, on Firefox 01, cave 2, there will be a lot of butterflies exploding against the amoeba. Most of the time you'll hear the explosion sounds, but in a few runs, I've seen diamonds fall a couple times without hearing the prior explosion sound, which means that the explosion sound got cut off by something else.

Good luck to you and merry Christmas! May all your wishes come true!

- Agetian

[CWS]

One thing I noticed is that it seems at least with 60 fps vsync time seems to be running a bit faster than in GDash.

I made a tight time limit for collecting the next clock in my CWS Boulder Dash 3 cave Around The Clock. In GDash I can reach the next clock barely in time in 60 fps vsync, in R'n'D time runs out half the way.

And would it be possible to add an option in the game menu for the Boulder Dash engine to automatically continue playing after loosing a life? Would be more Boulder Dash-like...

[igormakovsky]

That's for sure, best xmas present ever!

I'm sure that would've been my dream at the age of 6 when I've launched Boulder Dash for the first time on my Speccy with dad.

Can anybody check if the following snapping behaviour is fine for the true BD engine, please?
Snapping jewels to the left makes elements fall freely, while snapping to the right makes elements stuck with each move.

https://igormakovsky.com/asmysl/bd-snaps.mp4

Merry Christmas everybody! Wish only jewels and boulders in awesome RnD BD fall on our heads!

[artsoft]

There is also another (quite recent) graphics set, "Boulder Rush graphics by CWS", which is a highly improved version of the Boulder Rush graphics set. I will also add this graphics set to the GDash cave collection, as a custom graphics set which can be selected as an alternative to the two already provided graphics sets. [...]

I know, I've done that graphics set...

Yes, I know.

It did not make its way into the final 1.0.0 GDash level package, but will hopefully be available with the next update!

[artsoft]

But I have to admit that it would be nice to be able to edit larger parts of the playfield without changing the tile size that is too small.

Can't you just use a different window size for the editor only? At least as large that regular Boulder Dash caves can be displayed as a whole.

Yes, that would be possible, although it would mean that window size would always change before and after test-playing a level set from the editor.

I will create a custom artwork set with different window sizes for game and editor, and will see how that works. (And I'll also add an alternative artwork set with 30x18 game window size (as used by the Krissz engine, if I remember right), which might work as well here.)

I think it should be in ~/Library/Application Support - no matter if there is user data or not. For example the emulator PCSX2 also uses user data like texture packs which could be manually copied there but it's still in ~/Library/Application Support.
Moreover you can always use the menu "go to - Library" in the Finder menu bar, even if the Library folder is hidden.

Sounds reasonable. And I could add an option to the "info" menu that opens a file browser in the user data directory, so it would not matter if it's hidden or not.

I'll think about this, will experiment with possible solutions, and see what might work best. But generally, I think you're right here that R'n'D should use "standard" directory locations for its data, if possible and feasible.

[artsoft]

Grats on getting 4.4.0.0 released, Holger! it's a really nice milestone release and I'm happy you've seen the project through to completion!

Thank you!

I have a little report based on playing the latest release. It seems like the sound priorities and/or sound mixing is incorrect sometimes, which causes certain sounds to be skipped completely. This is easily seen, for example, in the Firefox 01 level set, cave 3, where you have a lot of expanding walls. As you move around and the walls expand (while you eat dirt and collect diamonds), you'll notice that a lot of the "wall expanding" sounds are missing and the walls expand silently. If you compare it to the reference GDash implementation, you'll see that all the expanding wall sounds are heard in the original implementation. Not having these sounds is slightly disorienting, as in this game you have to rely a lot on the audio hints to figure out what's happening when (almost as if you're in a rhythm game ). Hope this is easy enough to fix

P.S. This seems to affect other sounds too, but it's more difficult to consistently reproduce. For example, on Firefox 01, cave 2, there will be a lot of butterflies exploding against the amoeba. Most of the time you'll hear the explosion sounds, but in a few runs, I've seen diamonds fall a couple times without hearing the prior explosion sound, which means that the explosion sound got cut off by something else.

May it be possible that this only affects sound effects for game elements that are outside the visible area? Both R'n'D and GDash use some sort of stereo sound effect handling to locate sounds that are far left or right, with at least R'n'D not playing sounds anymore if they are too far away from the visible playfield.

I might change this for the BD engine to be handled just like in the GDash engine, if this should be the reason for the problem you have encountered.

Good luck to you and merry Christmas! May all your wishes come true!

Thanks again!

[artsoft]

One thing I noticed is that it seems at least with 60 fps vsync time seems to be running a bit faster than in GDash.

Yes, that's right. If you set screen updates to 60 fps (as required for 60 Hz VSync), the whole game engine will run faster (as scrolling would not be smooth otherwise).

I made a tight time limit for collecting the next clock in my CWS Boulder Dash 3 cave Around The Clock. In GDash I can reach the next clock barely in time in 60 fps vsync, in R'n'D time runs out half the way.

That should not happen. Could you provide me with a test level that shows this misbehavior in R'n'D, while it works as expected in GDash? Then I should be able to fix this problem.

And would it be possible to add an option in the game menu for the Boulder Dash engine to automatically continue playing after loosing a life? Would be more Boulder Dash-like...

I'm not sure if I understand this right. If you die in R'n'D with BD engine, you are asked to play again and can continue playing the same level. What kind of behavior do you think of instead? If possible, I might change it so it might feel more GDash-like instead.

[artsoft]

That's for sure, best xmas present ever!

I'm sure that would've been my dream at the age of 6 when I've launched Boulder Dash for the first time on my Speccy with dad.

I'm pleased that you like it, and happy about those childhood memories!

Can anybody check if the following snapping behaviour is fine for the true BD engine, please?
Snapping jewels to the left makes elements fall freely, while snapping to the right makes elements stuck with each move.

https://igormakovsky.com/asmysl/bd-snaps.mp4

Merry Christmas everybody! Wish only jewels and boulders in awesome RnD BD fall on our heads!

Yes, that's indeed original behavior that can also be experienced in GDash. It's caused by the scanning order of the playfield. Such asymmetrical game element behavior is in fact quite common in GDash (and also in the R'n'D engine here and there).

[Agetian]

May it be possible that this only affects sound effects for game elements that are outside the visible area? Both R'n'D and GDash use some sort of stereo sound effect handling to locate sounds that are far left or right, with at least R'n'D not playing sounds anymore if they are too far away from the visible playfield.

I might change this for the BD engine to be handled just like in the GDash engine, if this should be the reason for the problem you have encountered.

Hmm, I'm not sure... Judging by cave 03 (and the expanding walls case), it affects sounds in the visible area as well, since the missing sounds come from the expanding walls that expand as you eat the dirt next to them. That seems to be my impression, anyway... But that said, I believe that in BD engine (GDash), there's no real "cut off point" for the sounds, and you hear everything, even it happens in a different part of the cave outside the visible area. I might be wrong though, prolly needs some additional research

- Agetian

[CWS]

I made a tight time limit for collecting the next clock in my CWS Boulder Dash 3 cave Around The Clock. In GDash I can reach the next clock barely in time in 60 fps vsync, in R'n'D time runs out half the way.

That should not happen. Could you provide me with a test level that shows this misbehavior in R'n'D, while it works as expected in GDash? Then I should be able to fix this problem.

Just play the cave "Around the clock" of my CWS Boulder Dash 3 with 60 fps vsync in GDash and in R'n'D. It's included in R'n'D. You will see for yourself.

I'm not sure if I understand this right. If you die in R'n'D with BD engine, you are asked to play again and can continue playing the same level. What kind of behavior do you think of instead? If possible, I might change it so it might feel more GDash-like instead.

I meant without any question asked - just continue with the next life. Same as it was always in Boulder Dash. Maybe you can add this as an option in the engines menu.

[artsoft]

Hmm, I'm not sure... Judging by cave 03 (and the expanding walls case), it affects sounds in the visible area as well, since the missing sounds come from the expanding walls that expand as you eat the dirt next to them. That seems to be my impression, anyway... But that said, I believe that in BD engine (GDash), there's no real "cut off point" for the sounds, and you hear everything, even it happens in a different part of the cave outside the visible area. I might be wrong though, prolly needs some additional research

I did some testing and debugging, and was able to find a problem with sound precedence in the native BD sound engine. It's fixed now, and the expanding wall sounds in the test level mentioned should be correct now! Will be released soon with the first patch version 4.4.0.1.

Regarding playing sounds by distance in GDash, you are indeed right! This is handled a bit differently in the R'n'D implementation of the BD sound engine; maybe I will change this (but would have to do some more testing first).

[artsoft]

Just play the cave "Around the clock" of my CWS Boulder Dash 3 with 60 fps vsync in GDash and in R'n'D. It's included in R'n'D. You will see for yourself.

Thanks! I already did some testing, could not find something suspicious so far. However, choosing "normal speed" or "fast speed" (as required for 60 Hz VSync) should not make a difference game engine wise -- it's just playing faster (which makes things harder than with normal speed, of course).

I meant without any question asked - just continue with the next life. Same as it was always in Boulder Dash. Maybe you can add this as an option in the engines menu.

Ah, now I understand! I will think if I can find a good solution for this problem. At least, a good point!

[Agetian]

I did some testing and debugging, and was able to find a problem with sound precedence in the native BD sound engine. It's fixed now, and the expanding wall sounds in the test level mentioned should be correct now! Will be released soon with the first patch version 4.4.0.1.

Regarding playing sounds by distance in GDash, you are indeed right! This is handled a bit differently in the R'n'D implementation of the BD sound engine; maybe I will change this (but would have to do some more testing first).

Nice to hear it! Yeah, I'd argue that making it consistent with how GDash sounds would be important too, it doesn't come up very often, but there are some advanced caves where there's a timed event (e.g. an explosion) that might happen across the cave, and you need to be able to hear the explosion to know when exactly it happened to time your actions relative to that.

- Agetian

[CWS]

Just play the cave "Around the clock" of my CWS Boulder Dash 3 with 60 fps vsync in GDash and in R'n'D. It's included in R'n'D. You will see for yourself.

Thanks! I already did some testing, could not find something suspicious so far. However, choosing "normal speed" or "fast speed" (as required for 60 Hz VSync) should not make a difference game engine wise -- it's just playing faster (which makes things harder than with normal speed, of course).

It's like I already wrote: set both games GDash and RnD to 60 hz vsync. In GDash the first clock can be reached in that cave, in RnD the time seems to run a little bit faster and the clock can't be reached. In 50 fps it's working, of course. And I know that game runs faster in 60 Hz - I only want to point out that GDash seems to have a different timer for 60 Hz than RnD.

I meant without any question asked - just continue with the next life. Same as it was always in Boulder Dash. Maybe you can add this as an option in the engines menu.

Ah, now I understand! I will think if I can find a good solution for this problem. At least, a good point!

That would be a significant improvement for the Boulder Dash engine!

[CWS]

I also think that with the Boulder Dash engine there should be 3 lifes. Not endless tries.