Gdash

[LogicDeLuxe]

Interesting that I did not noticed the problem with the random generator. But I'm not as deep in it.

Noticed a pattern?
And you don't really need such big caves to notice certain similarities. Take a closer look at the first cave of BD1 for example:

[LogicDeLuxe]

Deluxe Caves 3 cave h: There should be no acid, but glued diamonds and glued dirt instead. The difference should be detectable by looking at the graphic pointer table. Also there are Diego effects defined in the bytes $16 and $17. Diagonal movement is a global property in this game.

[CWS]

Interesting that I did not noticed the problem with the random generator. But I'm not as deep in it.

Noticed a pattern?

Man, this is REALLY big! I must say it's hard for me to find a pattern. But maybe it's like with this 3D-Pictures - it should work but I have never seen any pattern in it. Have you ever seen such a 3D-Picture? Grrr. I hate that...

And you don't really need such big caves to notice certain similarities. Take a closer look at the first cave of BD1 for example

Ok, I see it. But it's in the original C64 Boulder Dash 1, too (I checked it some minutes ago just to be sure)! Is that bad?

Deluxe Caves 3 cave h: There should be no acid, but glued diamonds and glued dirt instead. The difference should be detectable by looking at the graphic pointer table. Also there are Diego effects defined in the bytes $16 and $17. Diagonal movement is a global property in this game.

There are soooo many different engines, I think mostly very costomized. Do you think it is possible to implement all of these engines into GDash and its converter without risking any intersections?

[LogicDeLuxe]

I mainly write what's not working for the games which come with Gdash. And since they are bundled, they should work.

There are soooo many different engines, I think mostly very costomized. Do you think it is possible to implement all of these engines into GDash and its converter without risking any intersections?

It's not simple, but if the converter looks at certain tables or routines, it is possible.

The most tricky part are those "unused bytes" $16 and $17 in BD1 engines which are in fact used for general purpose in all those different extensions, maybe $00 as well. A very interesting extension is Frusti Dash (I didn't took a look at the code, yet), for which we would need even some more BDCFF extensions.

The BD2 extensions by Rockford are easy and already implemented.

Still missing is PLCK with global Diego effects, though this should be easy to detect. Whenever a PLCK cave without Diego effects is found, we could just insert the hardcoded bytes from the engine to them.

Also global diagonal movements in BD1 and PLCK could be detected by looking at the code which decides the direction of walking.

And here is yet another global mod: Deluxe Caves 1 has vertical growing walls. Also detectable by looking at the growing wall code.

[cirix]

Hi

Yeah, the random generator repeats itself in a very short period. It was a year ago or more, when I fiddled around with some random generators, and added glib's (part of gtk+) own predictable random generator to the game. But I did not like it, as I think the patterns generated by the C64 code are nice.
You see these are two different things, patterns and periodicity. It is nice to have patterns, and bad to have visible periodicity. C64 code has both; whereas the glib random generator is a very advanced one, and has neither.

Sometimes I think importing a game which has only one instance makes no sense. I mean, you mention deluxe caves 1, for example, with an only game using hardcoded vertical growing walls. Detecting this would take hours of looking at the disassembly and finding growing wall part and the like. These "specialities" will be bundled as bdcff later. Import as BD1, change a few things in the editor (or even with notepad, a simple search&replace would do!!!), and save as bdcff. If I'm finished with proper and final bdcff code, these issues will be solved in minutes.

[CWS]

Although it would be nice if all BD games ever released on C64 would be converted right I also think that it's not worth the enormous efforts. As we have someone in our middle that is knowing all the problems, they could easily solved with changing the faulty parameters in the bdccf converted caves. Maybe a list of all problems that are detected by now would do the trick? Or is anybody else able to offer some code for perfect converting?

[cirix]

But maybe it's like with this 3D-Pictures - it should work but I have never seen any pattern in it. Have you ever seen such a 3D-Picture?

hey that would be nice a picture which looks like cave, but if you cross your eyes, suddenly a big rockford figure appears

[LogicDeLuxe]

Since an advanced random number generator would be optional (for compatibility reasons), I see no disadvantage in having it. If you want really random looking distributions, you use it, if you want old style patterns or a C64 compatible cave, you just don't use it. It must be open source, though, so anybody writing a BDCFF compatible clone will be able to use it.

Sometimes I think importing a game which has only one instance makes no sense. I mean, you mention deluxe caves 1, for example, with an only game using hardcoded vertical growing walls. Detecting this would take hours of looking at the disassembly and finding growing wall part and the like. These "specialities" will be bundled as bdcff later. Import as BD1, change a few things in the editor (or even with notepad, a simple search&replace would do!!!), and save as bdcff. If I'm finished with proper and final bdcff code, these issues will be solved in minutes.

That's a good think. Maybe you should mention it in a known issues text file and list the affected games/caves there, so that people stop wondering or getting confused by problematic caves. And we could consult that text file before reporting issues you might know already.

[CWS]

That's a good think. Maybe you should mention it in a known issues text file and list the affected games/caves there, so that people stop wondering or getting confused by problematic caves. And we could consult that text file before reporting issues you might know already.

Maybe you can help making this list? I do not know any second man who is able to do that with 100 % accuracy...

As soon as all available C64 Boulder Dash games are converted right the main focus should be making new games with this great clone.

[cirix]

Maybe you should mention it in a known issues text file and list the affected games/caves there, so that people stop wondering or getting confused by problematic caves

That's a good idea. I'm already collecting your notes about the caves; some issues are already fixed, some not. As soon as bdcff code is almost ready, this list will make sense; and also, it will be very easy to repair those caves and bundle them as bdcff instead of original cave data.

[LogicDeLuxe]

Bouldi Dash 1 Cave 01 (and probably most of the other Diego Effect enabled PLCK caves):
Explosion effects don't work. This is due to the different way those effects are implemented in PLCK and 1stB/CrLi. PLCK patches the last byte of the explosion sequence in the effect table while 1stB/CrLi does it in the code for the last element in the explosion sequence which is represented by EXPLOSION6 in BDCFF.

In BDCFF, the defaults are
PLCK: Effect=EXPLOSION5 EXPLOSION5
1stB/CrLi: Effect=EXPLOSION6 SPACE

The Explsions turn into Boulders effect would look like this:
PLCK: Effect=EXPLOSION5 BOULDERd
1stB/CrLi: Effect=EXPLOSION6 BOULDERd

Thinking of this, we might rename EXPLOSION6 and DIAMONDBIRTH6 to EXPLOSIONeffect and DIAMONDBIRTHeffect to be consistent with the other effect Elements.

[LogicDeLuxe]

You should add $a9 $1c $85 as an alternate effect signature, as there is an alternate version of the Effect Kit 3.1 having this one.

[CWS]

I noticed that the threshold of the amoeba is indicated in percent. In CLCK 3.0 its set via the number of cells it occupies (200 is the default value). It is really a problem. It's default value is 22.7 but after setting another value it's not possible to set it back to 22.7. Maybe it should be a reset button in the same line to be able to set back to 22.7? And I would recommend to show the real size (e.g. "22.7 % (200 cells)") and maybe the possiblity to set the percentage OR the real cell size (it I set e.g. "250" cells is should be "28,4 percent" if cave size is 40 x 22). Same with "Probability of pushing stone", "Grawth ratio" of Amoeba and "Spread ratio" of Acid. Please give use an additional absolute value like in CLCK 3.0 with a reset button to be able to reach e.g. 3.1 again...

[cirix]

hi,

new version:
http://jutas.eet.bme.hu/~cirix/gdash/

short list of changes:
- fast forward mode
- graphics, color changes, support for any color (not just 16 default colors)
- visible part of caves
- other small changes, tools, bug fixes
- better handling of inconsistent bdcff files
- cave random elements setup tool
- any2gdash better support for diego effects

as usual, please uninstall previous version first, as the encoding of imported caves changed.

bye

[LogicDeLuxe]

Nice improvements
But also some bugs introduced:
- When opening the "cave settings" dialog while the editor window is rather small, it opens higher than the editor window, which can be off screen.
- The element selector appears behind the "cave settings" window, which is a bit annoying. Same thing for the "any color picker".

Some suggestions for the element selector:
- Falling Diamonds and falling Boulders should be considered "for effects".
- Time penalty is missing, which should be in the "for effects" section.
- Open Outboxes should be visually different from the normal ones.
- The glued Diamond is missing, which should be in the "normal elements" section.

Crazy Dream 2 Cave E: The explosion pattern does not match the original due to the lack of 1stB's imperfect top/bottom border behavior. GDash's perfect redirecting behavior sure is a nice feature, but unfortunately not that compatible.