Boulder Dash Forum

Hi,

I uploaded a new version. Please uninstall the original first.
This one does not contain too many new features, rather some bugfixes.
Of course all bug reports and suggestions are kept in mind (and in the todo file )

Among others, this version autodetects the loaded png graphics, if it is a "true color" one, with many colors (like the boulder rush theme; and c64 colors are not used then), or a png file with only a few ones, which encode the original c64 colors. Check the installed "cells_c64.png" file, and you see what I mean. If anyone has the time for that, I'd be happy if you sent me any new graphics, or any original character set converted (for example, bd3 space, atlantis, and the like).

Some of the bug reports are not really bugs, I think. For example, LogicDeLuxe: there is no time penalty element (which is really a GRAVESTONEeffect or something like that), as the game internally handles subtracting time. Also, there are some caves, ussually from special, modded versions of the original game, which are converted incorrectly. Those should be fixed in the editor, and saved in bdcff, but only later, as the bdcff saving does not handle some elements in mapped caves.

Also, I'd like to tune the timing emulation of the game, and I would be happy if you sent me reports like "a cave with too much falling walls runs too slow", or "bd1 cave i, which has a lot of boulders and diamonds, runs too fast". With these, I can fine-tune the timing, or at least I hope so. I think you should send me these in private messages, not to fill this forum, as it is not really important for everyone. Unfortunately, it is only a rough emulation of the original timing, and will never be perfect.

bye

cirix wrote:there is no time penalty element (which is really a GRAVESTONEeffect or something like that), as the game internally handles subtracting time.

It is an element in 1stB and CrLi. If it isn't in your engine, there should be at least a way to retain compatibility to those.

I think speed issues are not the biggest problem - they can easily be solved by using the ms based timing, correcting by hand. Maybe a switch can be used in cave properties if the specific C64 delay you used to make it even more compatible should be used or not.

The biggest problem is that changes could not be saved correctly. I thought I correct the speed issues by myself and used the "felt" correct values in each cave of my CWS Boulder Dash 2 game. But after saving it I can not load it anymore. I mean I could load it but all caves are destroyed. There must be a severe problem in saving. Moreover it's saved as BDCFF but the correct extension is not added to the filename so it can not be loaded by GDash without renaming the file first! Or - if you know it - you save your file with a ".bd" extension.

It seems that saving as BDCFF works e.g. with Boulder Dash 1 but saving e.g. Crazy Dream 8 does not work - same as my CWS Boulder Dash 2. Caves are totally destroyed.

I think that's the biggest problem at the moment as no new game can be made with GDash as it is not saved correctly.

CWS wrote:The biggest problem is that changes could not be saved correctly.

As I already pointed out, the lines are truncated as soon as an element occurs which has no default mapcode. BD1 and BD2 games aren't affected as they don't use mapcodes, and even if they did, they rarely use those non working elements.

Automatically adding the .bd extension is a good idea.

Ok, after the reason why this happens has been found I hope the next version can be used to correct old and creat new games!

By the way: Is it a bug in BDCFF or in GDash?

gdash, of course. that will be the next bug to correct. i just hate writing code which saves and parses files...

bye

I found the real problem with timing in GDash for which I can not find a solution (maybe LogicDeLuxe can help):

Timing on C64 Boulder Dash runs in relation to the speed of each cave. So timing is not really seconds based. It's almost seconds but not exactely. Time is running just a little bit faster in GDash.

That's also the reason why I am not able to get the correct speed on my CWS Boulder Dash 2. If I take cave 12 by example in my game - if I'm using 120 ms (instead of C64 delay 8.) Rockford is running too fast but I need the same time as on the C64 version to get from the one side of the cave to the other one (which would be the correct solution to this problem). So timing would be the same but it's more difficult to play because Rockford is running much faster (and, of course, the enemies).

I'm almost certain that there are many games with bare time for certain caves (some only have a few seconds to solve the cave/intermission). Delay would be the same - enemies and Rockford would move in the (almost) exact same speed as on C64. But time is running a little bit faster. So such caves can not be solved. Take cave 12 of my game again - with delay 8 on C64 it takes until time reaches 192 to run to the left, up, end then to the right border again. If I use delay 8 on GDash time is at 190. The difference is not much but it could be larger on other games/caves.

On with GDash newly designed caves it does not matter but as virtually all games are converted from C64 at the moment this could be a problem.

I really can not imagine what to do because of this.

The timer is slower on PAL machines. While on NTSC machines one real time minute takes in fact 60 seconds on the Boulder Dash timer, on a PAL machine one real time minute only takes 50 seconds on the Boulder Dash timer.
This is true for all engines except for CrLi, which also has the slower timer on NTSC machines in order to stay more compatible. I made the decision for the slower than real time seconds because all fan games were PAL based, and keeping it that way increased the compatibility for imported caves in CLCK. (Recently, we got some NTSC based fandom right here, though)

Thinking of this, a video standard attribute might be a useful addition to the BDCFF. Something like this:
VideoStandard=PAL|NTSC


In addition to this, we should calculate the correct hatching delay. While BDCFF and some other clones count them in frames (which is a good idea in general, since this does not interfere with other settings), C64 Boulder Dash has always a 4 seconds (in Boulder Dash time) delay. If we have calculated the actual frametime of the cave, we can easily calculate the hatching delay which matches 4 seconds.

A bug in BD1 and unfixed PLCK games cause a 6 seconds delay instead, but this certainly is a "feature" we don't need, as this can not even be tested in the official Construction Kit. Btw., his seems to be the only bug ported from the Atari version.

LogicDeLuxe wrote:The timer is slower on PAL machines. While on NTSC machines one real time minute takes in fact 60 seconds on the Boulder Dash timer, on a PAL machine one real time minute only takes 50 seconds on the Boulder Dash timer.
This is true for all engines except for CrLi, which also has the slower timer on NTSC machines in order to stay more compatible. I made the decision for the slower than real time seconds because all fan games were PAL based, and keeping it that way increased the compatibility for imported caves in CLCK. (Recently, we got some NTSC based fandom right here, though)

Thinking of this, a video standard attribute might be a useful addition to the BDCFF. Something like this:
VideoStandard=PAL|NTSC

The idea with the BDCFF addition VideoStandard=PAL|NTSC is the best one I could image! So it should be no problem to make a minute on PAL machines 50 seconds in GDash.

hi fans

i uploaded a new version, which adds only one feature, correctly saving map-based caves in bdcff files. i didn't have much time to test it, but is seems to work ok. you can download it from the usual link, http://jutas.eet.bme.hu/~cirix/gdash/

technical stuff:

logicdeluxe:
it does not yet support 2-character map codes, but it should be enough for all caves for now.

videostandard attribute is nice, maybe a paltiming=true/false would be better, as ntsc is "real", and pal is the one which is not.

hatching delay is also important; maybe it should be connected to the current c64 timing attribute, which gdash uses, but bdcff standard does not yet (i think) have.
that is, c64 timing=true: variable frame time, using delay loop and elements ckdelay value, hatching = 4secs; c64timing = false: correct, milliseconds-based timing, hatching = 21 frames.

the hatching delay can unfortunately not be calculated easily, as on the c64 (and gdash in c64 timing emulation mode), frame times differ. caves can speed up... imagine a cave full of fireflies and amoeba, an explosion happens, and the cave speeds up. for example crazy light 9, two deaths. this speed up happens even before hatching. so calculation is almost impossible, "simulation", ie. playing the cave, is much more easier. that is why i suggest c64 timing to use 4s (6s) for hatching, and milliseconds-based to use 21frames.

cws:
i speeded up your cwsbd2 cave 1, does it work now?

bye

cirix wrote:videostandard attribute is nice, maybe a paltiming=true/false would be better, as ntsc is "real", and pal is the one which is not.

Just remember that almost 99 % of all available C64 Boulder Dash games are PAL! It's interesting that there are almost no NTSC games.

cirix wrote:hi fans
cws:
i speeded up your cwsbd2 cave 1, does it work now?

Yes! It feels much much better! I think it should be solvable now (I tried it some times and it should work - but I didn't succeed at the moment - it's really hard!). Speed feels like on C64! Thank you!

Now cave 11: It also feels too slow. Delay 140 - 145 ms is much more like on C64 then with cave delay 5 (about 195 ms).

By the way: Saving seems to work now! Wow! Thanx! I do not know if it will be even better with 2-character map codes but it would be certainly the best to be as most compatible as possible...

And: If noticed you added a question mark to "wait for scrolling" in the todo list. I think you should wait for scrolling - otherwise it's almost impossible to play some caves. Or should there be an option in cave properties which is marked by default to wait for scrolling and could be unmarked if it shouldn't? Would be nice...

cirix wrote:hatching delay is also important; maybe it should be connected to the current c64 timing attribute, which gdash uses, but bdcff standard does not yet (i think) have.

Actually, if CaveDelay is set, it implies C64 timing. If CaveDelay is not set, FrameTime is used instead. Both may be specified, so BDCFF engines which don't support CaveDelay can fall back to FrameTime.

that is why i suggest c64 timing to use 4s (6s) for hatching, and milliseconds-based to use 21frames.

Agreed, HatchingDelay should default to 4 seconds whenever CaveDelay is specified, since this implies a C64 cave. Unless it is overridden with another HatchingDelay value, of course.

Can you please add the .bd extension automatically when saving games? I always forget and then I've to rename the file via the OS to open it in GDash...

It would also be great if the Load window can show all files optionally (not only special extension).