Boulder Dash Forum

As I said - we need a quick and simple solution. The new maintainer of GDash, meonwax, won't dig too deep into the code, only mild not too complex changes are possible. All other things have to be done by cirix - and he doesn't have the time to continue.

On a C64 the milling time is never 0 - even if it's set at 0. But on modern computers in GDash 0 is 0. And that's the real difference.

What we can say at the moment is that milling time 0 is infinite only at BD1, BD2 and PLCK.
But I do not know what it started to change - was it in 1stB, Crazy Dream or the latest Crazy Light.
But I suspect that at least everything from LogicDeLuxe is using 0 really as 0 (but it's not really 0 but at least 0.5 or such).
So it COULD BE that the milling time 0 is about 0 beginning with the 1stB engine.

The best method of finding out would be contacting LogicDeLuxe and ask him.

I have a feeling that we might start to misunderstand each other in parts, so I make an overview to ensure we're talking about the same things

Problem:
GDash and earlier BD engines have different interpretations of the magic wall milling time if it's set to zero:
- BD1, BD2, PLCK: 0 means infinite
- CLCK 3.0: 0 means until the next second starts
- GDash: 0 means exactly one frame
- Other engines (1stB, earlier CLCK versions): not sure yet, and it's also secondary for the moment because relatively few fancaves use these englines

The vast majority of fancaves in the CAVES folder is made either with BD1 or PLCK engine. Whenever any of these caves uses milling time 0 (meaning infinity), then GDash misinterprets it for "one frame", making these caves unsolvable because the magic wall doesn't work.

There are also (much fewer) fancaves made with CLCK where milling time 0 should mean "until the next second starts", and that's also misinterpreted by GDash for "one frame only". Also these caves might become unsolvable (as the aforementioned CWS BD2 cave).


Solution idea 1: Without any programming issues

This would mean that we would have to fix all the buggy fancaves per hand. In the many fancaves where 0 should mean infinity, we would have to set the milling time to 999, and in the few fancaves where 0 should mean "until the next second starts", we could set the milling time to 1. This would mean a lot of unpleasant work, however. And whenever we add new fancaves, the same problem would still be there.

Solution idea 2: With a minimum of programming, my suggestion

Dustin wrote:Add the option "milling time 0 is infinite", default setting "on".
"On" means 0 is treated as 999
"Off" means 0 is treated as before (magic wall works for one frame)

This would not require to add any new GDash features.
My idea is that because the default setting is "on", now all fancaves with milling time 0 are interpreted as infinity.
This would automatically fix all the many BD1/PLCK fancaves with milling time 0.
The relatively few caves where milling time 0 is really 0 (either "until the second ends" or "one frame") would then have to be changed by hand:
a) If 0 should mean "until the next second starts": Set the new option "off", change milling time from 0 to 1 (not a perfect solution but close).
b) If 0 should mean "one frame", then set the new option "off" and leave milling time 0. (Perfect solution)


Solution idea 2, your version:

CWS wrote:An additional option in the magic wall settings like „Milling time 0 is infinite“.

*) if option „Milling time 0 is infinite“ is activated, value 0 should be handled the same as 999.
*) if option „Milling time 0 is infinite“ is deactivated, value 0 should be the period until the next second starts.

Very similar to my suggestion, but mine has two advantages as far as I see:

(1) In the current GDash version, the magic wall milling time is unconnected with the cave timer. This would have to be changed if 0 can mean "until the next second starts". In my suggestion, there's still no connection between milling timer and cave timer, so as far as I can see, my suggestion is easier to program.

(2) In my suggestion, 0 can still mean "one frame", which means that GDash-original fancaves with milling time 0 can work as before.


Independant of this, I'm going to PM Logic DeLuxe now because of the 1stB and early CLCK engines

I wrote your solution in the GitHub issue: 0 is same as 999 or otherwise left alone at 0.

Super, thanks!

You may include the "Alchemyst Dig!" entries in the new cave archive for GDash as long as the folder is /Alchemystics. Do not include DangerDash yet. That series is being worked on right now.

Hi, I'm going to improve the \caves folder now, which may take two weeks or so. First of all, I want to clean up the \various folder. So please, if a new version comes out in this time, then don't make changes in the \caves folder (or let me know if you do)

I have a question about the .gds and .bd formats.

If I fix a .gds- cevset in the \caves folder and try to save the fixed version, GDash doesn't allow me to just overwrite the .gds file, but it wants to save the fix as a new .bd file. Is it OK to do that and then delete the buggy .gds file, or does that make any difference?

Hi Dustin.
In my opinion, *.gds files are compressed by any2gdash.exe *.vsf emulator files.
We will not do anything with these files.
Gdash only saves in *.bd format

I think that after correcting the incorrect *.gds files, it is worth removing them and leaving the correct *.bd file only then

Regards

Thanks zsom!

I see, now that I looked at it, that the .gds files are way smaller than .bd files.
Alright, so I intend to do it this way (save fixed games as .bd and remove the former .gds if it was buggy)

zsom wrote: ↑Sat Jul 29, 2023 8:58 am Hi Dustin.
In my opinion, *.gds files are compressed by any2gdash.exe *.vsf emulator files.
We will not do anything with these files.
Gdash only saves in *.bd format

I think that after correcting the incorrect *.gds files, it is worth removing them and leaving the correct *.bd file only then

Regards

Do you still have any2gdash.exe? I'm missing this file.

Yes.
Write me an email at zsommk@gmail.com and I will send you any2gdash.exe

Good morning everyone.
In thanks to Dustin for continuing the "Stage Game" series
and recording my replays for him, I noticed that the replays of caves where the player uses the "POT" item will play poorly afterwards.
This problem was already present in earlier versions of Gdash.

Could this be checked and possibly fixed?

Have a nice day

Please post an Issue at GitHub!

About the magic wall timer.
In BD1, BD2 and PLCK, it was a one byte value with an independent timer. It is set with a one byte value.
The timer works by counting interrupts, ie. 60 per second on NTSC. Whenever it reaches 60, the magic wall's second timer is increased and then compared against the set value. Thus 0 really means 256 Boulder Dash seconds, not infinite. There is a serious bug, though, the time still runs when the game is paused.

In 1stB, Prof. Knibble re-implemented the timers from scratch while optimizing the game. It is now a 2-byte value, and it counts along with the cave time, thus somewhat less precise unfortunately. At least, pausing the game does not affect it anymore. Another side effect is, that the timer waits for hatching, which already is an option in Gdash. And being a 2-byte value, it can be theoretically far longer then 999, but you shouldn't really design a cave you need to spend that much time, thus I kept it at 3 digits. After all, the game is not designed with save states in mind.

As the relationship to the cave time is of really no benefit for cave designers, but only a compatibility thing, it should be handled with the "scheduling type" property in the "difficulty" tab, imho. For some reason, there is no 1stB setting there.
Whenever scheduling is set to BD1, BD2 or PLCK, 0 should be read as 256 while loading the cave from the binary file.

Keep in mind that this does not only affect the magic wall timers, but also the amoeba timers in every regard, since those work exactly the same. In fact, before PLCK, there really was only one timer shared for magic wall and amoeba.

Another thing got my attention: The tooltip for "scheduling type" is wrong! The empty delay loop is only true for BD1. All other engines count interrupts. The PLCK and CRLI delay values are thus increments of 20ms on PAL machines, as long as the computer can keep up with the speed. Thus, a value less than 5 does not speed up the game any further without engaging some CPU turbo. This was discussed somewhere here in the forum.

Interesting information! Now I got the confirmation that the magic wall timer was different in the original releases and changed beginning with 1stB (I suspended this already).

I’m not sure if it doesn’t matter if we use 0 as infinite as I do not know a cave with time as large as 256. But if this is absolutely necessary we could rename the option to „Milling time 0 = 256“.

Concerning the „tooltip“: Do you mean the help text is not correct or do you mean the function itself does not work as intended? I’m asking because I’m right in the middle of updating and correcting the german translation.

I would recommend to visit the GDash GitHub site and add every faulty or missing option as an Issue so that it will not be forgotten.