Thoughts on Where from here after 4.4.2.0
Posted: Fri Jun 12, 2026 5:12 am
I like to acknowledge each release with a heartfelt '3 cheers for Holger', so, just like always, big thanks to Holger for the new release. Maybe even bigger this time, as this release looks very interesting, with changes in so many areas. I like the way that the announcement clearly groups the changes.
Holger you wrote:
"additions to improve Emerald Mine support
[cut]
added checkbox to use EM/DC style duration in “moves” instead of seconds"
I am curious about this, as I thought that DC was handled within the RnD engine? This belief was based upon my believing that the EM engine only handled elements within the sections of the palette,
- EM
- EMC
- TEXT [first one of two]
At least when a level is changed from the RnD engine to the EM engine,
these are the sections that remain.
It seems I had a simplistic understanding. Holger have you time to discuss this?
I probably should wait for your reply, but this ties into my belief that the division of the palette into BD, EM, EMC, RND, DC2, DX is neither logical nor optimal (I don't have a problem with the other divisions). I think that it would be better to be able to put the non-GE, non-CE, no-REF elements into one pot, and be able to filter them by choice of engine from a dropdown (this should be optional so there is the ability to place an element irrespective of engine),
and choose to sort the visible elements by, say:
- description A-Z
- token A-Z
- element type, at a high level, eg all normal walls together, all steel walls together, all monsters, and so on.
This might also tie in to dicussions about how EM elements behave differently under EM and RND engines. To take an example, Fake Acid; this is not on the palette at all, but is an EM element; it is stated that the player can move through it; this is true under the EM engine, but under the RND engine, it behaves like wall. I would love to have this element easily available under both engines, and be walkable through by the player, under both engines.
I had an idea, is there any way that element behaviour could be moved outside of the individual engines, to an 'element' subsystem, which the engines then call? Hence the logic for say Fake Acid could be defined in one place, and then there would just be calls to it from the engines which are allowed to use it.
I get that on the face of it, this would be harmful to an engine accurately mimicking the original engines for EM, SP, BD etc; but, this could be dealt with by keeping the different algorithms for one element or element type together, and ensuring that an engine calls its algorithm for the element, if there are engine-specific algorithms for an element; it not, attempt to use the general one? The last part is assuming that it is possible for different engines to share an algorithm; even if not, it might be logically beneficial to keep the various flavours of an algorithm adjacent to each other.
I had better come clean here and admit that I would quite like to make a few of the elements under BDX engine become available under the RND engine (as fully functional elements, not just wall-like elements), even if there is not much chance of making that happen. I accept that there are BDX features that could not be ported to RND, such as the wrap-around, and that's fine, I don't want to bring them across; I like RND without the wrap-around.
On the other hand there are aspects of Boulderdash that none of the engines seem to emulate, such as true-diagonal movement - for monsters, and/or player - I've seen this in some forks of BD running on a C64 emulator - and I would love for this to become available within RND, in all the engines that it makes sense for - BDX I suppose - and definitely RND engine.
Also I love TheOnyxGuy's "R'n'D in WIDESCREEN" release, but I don't think I will be using it much unless it is integrated into the app as a built-in feature, choosable by going into Settings and checking a checkbox or selecting from a dropdown list.
And while I'm on Dream Street, wouldn't it be great to release with the ability to run in 64-by-64 pixel graphics?
A combination of widescreen and 64-by-64 pixel graphics would go someway to making up for the screen-gobblingness of the 64-by-64 pixel graphics. I believe that certain members have produced 64-by-64 pixel graphic strips over the years, although I guess they would be a bit out-of-date now.
Wouldn't it be good if the graphic strips could be auto-converted, so 2 sets of files wouldn't have to be maintained? - I guess this would mean down-scaling from 64 sq to 32 sq, and I guess this wouldn't be considered good enough, since auto-down-scaled graphics would not look as good as manually designed graphics. But for some of us, they would be.
John
Holger you wrote:
"additions to improve Emerald Mine support
[cut]
added checkbox to use EM/DC style duration in “moves” instead of seconds"
I am curious about this, as I thought that DC was handled within the RnD engine? This belief was based upon my believing that the EM engine only handled elements within the sections of the palette,
- EM
- EMC
- TEXT [first one of two]
At least when a level is changed from the RnD engine to the EM engine,
these are the sections that remain.
It seems I had a simplistic understanding. Holger have you time to discuss this?
I probably should wait for your reply, but this ties into my belief that the division of the palette into BD, EM, EMC, RND, DC2, DX is neither logical nor optimal (I don't have a problem with the other divisions). I think that it would be better to be able to put the non-GE, non-CE, no-REF elements into one pot, and be able to filter them by choice of engine from a dropdown (this should be optional so there is the ability to place an element irrespective of engine),
and choose to sort the visible elements by, say:
- description A-Z
- token A-Z
- element type, at a high level, eg all normal walls together, all steel walls together, all monsters, and so on.
This might also tie in to dicussions about how EM elements behave differently under EM and RND engines. To take an example, Fake Acid; this is not on the palette at all, but is an EM element; it is stated that the player can move through it; this is true under the EM engine, but under the RND engine, it behaves like wall. I would love to have this element easily available under both engines, and be walkable through by the player, under both engines.
I had an idea, is there any way that element behaviour could be moved outside of the individual engines, to an 'element' subsystem, which the engines then call? Hence the logic for say Fake Acid could be defined in one place, and then there would just be calls to it from the engines which are allowed to use it.
I get that on the face of it, this would be harmful to an engine accurately mimicking the original engines for EM, SP, BD etc; but, this could be dealt with by keeping the different algorithms for one element or element type together, and ensuring that an engine calls its algorithm for the element, if there are engine-specific algorithms for an element; it not, attempt to use the general one? The last part is assuming that it is possible for different engines to share an algorithm; even if not, it might be logically beneficial to keep the various flavours of an algorithm adjacent to each other.
I had better come clean here and admit that I would quite like to make a few of the elements under BDX engine become available under the RND engine (as fully functional elements, not just wall-like elements), even if there is not much chance of making that happen. I accept that there are BDX features that could not be ported to RND, such as the wrap-around, and that's fine, I don't want to bring them across; I like RND without the wrap-around.
On the other hand there are aspects of Boulderdash that none of the engines seem to emulate, such as true-diagonal movement - for monsters, and/or player - I've seen this in some forks of BD running on a C64 emulator - and I would love for this to become available within RND, in all the engines that it makes sense for - BDX I suppose - and definitely RND engine.
Also I love TheOnyxGuy's "R'n'D in WIDESCREEN" release, but I don't think I will be using it much unless it is integrated into the app as a built-in feature, choosable by going into Settings and checking a checkbox or selecting from a dropdown list.
And while I'm on Dream Street, wouldn't it be great to release with the ability to run in 64-by-64 pixel graphics?
A combination of widescreen and 64-by-64 pixel graphics would go someway to making up for the screen-gobblingness of the 64-by-64 pixel graphics. I believe that certain members have produced 64-by-64 pixel graphic strips over the years, although I guess they would be a bit out-of-date now.
Wouldn't it be good if the graphic strips could be auto-converted, so 2 sets of files wouldn't have to be maintained? - I guess this would mean down-scaling from 64 sq to 32 sq, and I guess this wouldn't be considered good enough, since auto-down-scaled graphics would not look as good as manually designed graphics. But for some of us, they would be.
John