Boulder Dash Forum

Maybe a menu where you could just tick the target engine and have a choice between "Gdash native" and "CrLi",

i think there will never be such a thing. gdash tries to detect non-exportable options and effects when exporting, and issues warning messages.

and the bd inside faq says:
038D 0001 Magic Wall Sound $F0=on, $D0=silent
gdash sets this to f0 when exporting. maybe that is f1? most crazy light caves have f1 at that position. well.

i think there will never be such a thing. gdash tries to detect non-exportable options and effects when exporting, and issues warning messages.

What does GDash exactely do? Does it show warning messages only and writes these effects in the file with any placeholder or something or does it simply not write these effects to the exported file?

CWS wrote:

i think there will never be such a thing. gdash tries to detect non-exportable options and effects when exporting, and issues warning messages.

What does GDash exactely do? Does it show warning messages only and writes these effects in the file with any placeholder or something or does it simply not write these effects to the exported file?

As GDash has effects CrLi doesn't, there simply is no way to write them. Same with any hardcoded parameters like the 2 seconds hatching delay, Voodoo undestructible etc. GDash simply has no means to do anything about it.
Placeholders can and must be used for elements not available in CrLi, though.
Such a restricting feature I suggested would keep newbies to use such features in the first place, so he don't have to read up any details about the CrLi engine, but can just start making caves. Gdash sure is an alternative to the Crazy Light Construction Kit, as it uses the power of modern operating system which leads to a more convenient editing environment.

The export feature saves sequences of only 2 identical bytes with the escape byte, ie. it basically "compresses" 2 bytes into 3, thus making the caves bigger than necessary.

I think the way you implemented the Maze and RandomFill is okay. As you don't have fully implemented the Levels attribute yet, I wonder about one thing. I assume the engine will expect as many seed values as there are levels, right? This is a very important detail which has to be documented in the BDCFF specs.

And will you support Replace_Element in mazes too, so that none rectangular mazes will be possible? (Which is actually possible in Crazy Dream 9 already, although I only made use of this possibility in the title screen)
Alternatively, we could use a Maze_Auxiliary element instead of a Replace_Element and grow the maze in the way Crazy Dream 9 does. This might be a bit easier to implement, but also less intuitive for the cave designer, so I still would suggest the Replace_Element. Should be even feasible on a C64, I think.

I see, you fully support Crazy Dream 9 now, which certainly isn't a bad thing as such, but isn't it against your "will be tweaked manually"-policy?

Your bias parameter in mazes has no text in the setup dialog. At least not in the German version.

And I don't think that "Labyrinth" is a good translation of maze. It's the same as in English: http://en.wikipedia.org/wiki/Labyrinth
See also Labyrinth in Daedalus for details.
"Irrgarten" is the common term for "maze" in German.
And yes, those are often confused indeed.

The NONE element is a good thing, we should document in the BDCFF specs as well.

CWS

What does GDash exactely do? Does it show warning messages only and writes these effects in the file with any placeholder or something or does it simply not write these effects to the exported file?

There are no such effects in CrLi, so it will use the default values. GDash simply tells the user, which effect is incompatible. For elements, it uses steel wall instead. (But certainly those caves will not work properly.)

I see, you fully support Crazy Dream 9 now, which certainly isn't a bad thing as such, but isn't it against your "will be tweaked manually"-policy?

It is, but there is only one game, the CrDr9, and I decided to hardcode the mazes into the game. It identifies CrDr9 by cave names and checksums, so it won't be a problem, I think.

And will you support Replace_Element in mazes too

I have the code to do that, but it is not included in the released version yet. It is very hard to combine it with the wall&path width parameters.
Currently, GDash internally generates a maze with single-element-width paths and walls, and then scales it up for the requested path and wall sizes. If I would use replace_element, the positions of the replace elements should be "compatible" with the path&width sizes selected by the user... And that is a very uncomfortable thing, requiring the user to tweak these parameters by hand, not seeing the maze until he "accidentally" finds the correct values.
I think we should think about how a non-rectangular maze should be created in the editor, some comfortable and easy to understand way. And then it would be easier to think about how those are to be implemented.

As you don't have fully implemented the Levels attribute yet, I wonder about one thing. I assume the engine will expect as many seed values as there are levels, right? This is a very important detail which has to be documented in the BDCFF specs.

No, it always writes and reads 5 seed values. It is much easier that way.

cirix wrote:No, it always writes and reads 5 seed values. It is much easier that way.

So the 5 levels remain hard coded in your engine then? No more, no less? Is fine with me, though there are cases where people liked to have a different number of levels.

I think we should think about how a non-rectangular maze should be created in the editor, some comfortable and easy to understand way. And then it would be easier to think about how those are to be implemented.

Sounds reasonable. I don't have a better idea than the replace element right now, though.
Is there going to be the cavern type of maze? This sure is best suitable for shaped mazes, but also rather unsuitable for paths and walls thicker than 1 unfortunately.

Keep in mind that the entire maze generation algorithms should be as efficient as possible in terms of memory usage and speed. Then there is a good chance that I can port it to my next engine on the C64 the same way.

Then, the algorithm's codes should be documented with the BDCFF as well, so every one implementing a BDCFF parser would be able to reproduce the same mazes with the same parameters (unless seed=-1). (The random placement code is also still missing from any BDCFF documentation)

I also have another idea for Cut and Paste objects. There should be rotate and mirror parameters with it. That way, we could create symmetrical sections including random placed elements.
Like
Paste=X Y [rotate_left | rotate_right] [mirror_x] [mirror_y]

hi

i uploaded a new version, 20080715. gdash now comes in two flavours, a gtk+ and an sdl version. the new sdl version has sound, c64 look-and-feel and joystick support. the usual gtk+ version has the editor.

the sdl version is not really finished, but everything works in it. (for the curious: i'm not really into trying to merge these two. both sdl and gtk/glib has its own timing routines, event handling and the like. and i think it would not be easy, or possible at all, to make them work together. also, i will not code the editor in sdl, as it would be a pain.) to compile, now it also needs sdl and sdl_mixer.

other changes include:
- crli export enhancements
- one extension (*.gds) for all cave binaries
- replace fill crash solved
- on windows, the installer registers *.bd and *.gds, and you can start gdash from the shell by right-clicking on a file and selecting "open" or "edit"
- any2gdash now included in the installer
- the editor game overview shows which cave is selectable
- boulder pushing works differently for different gravitation directions
- ...

as the caves are changed, it is important to uninstall the original gdash. hope everything works.

two things i'd like you to help me with:
- if you find any errors in the english sentences in gdash, please tell me in email or a private message.
- if you have any caves which you would like to be included in the gdash installer, also send them to me.

bye

Thank you cirix!! Sounds make the sdl versiony a really good approximation of the C64 feeling!

This is great! Go Sounds!!!

hi

the vice emulator gave me the inspiration, i managed to use sdl and gtk together.
i uploaded a new version, 20080722 to http://jutas.eet.bme.hu/~cirix/gdash/
both the with-editor and the c64-like version have sound.

please give me some feedback, if the windows version works seamlessly! on linux, gtk and sdl work together correctly.

bye

I will test them.

And keep them two versions, ie. a separate SDL only version. This makes it easier to port it to handhelds, since SDL is available on many platforms.
I might try a GP2X port when I find the time.

Crazy Dream 9 "Random Maze" should have dirt path but has space path instead.

In German menus "zur Übersicht konvertieren" "Übersicht löschen" etc.. Übersicht really is confusing. It should be called Karte instead.

Nice to have sounds, though there are a bunch of issues:

Increasing tones of the last 9 seconds shouldn't be looped. And unlike the Atari version, every one of them should be heared rapidly when the level is finished and the remaining time is rewarded.

Diamond pickup sound seems to share the channel of the last 9 seconds sound and also the walking noise. On the C64, only the last 9 seconds sound shares a channel with the walking noise. The Diamond pickup sound can be played simultaneously. (Eventhough this requires more than one Rockford in the cave)

Explosions are silent while the last 9 seconds sounds are playing. This should be the other way around, ie. explosions have the higher sound priority.

Diamond pickup sounds and Boulder rolling sounds shouldn't fade out when played rapidly.

Amoeba can be heared before the start signal, but shouldn't. (Unless the game is paused and unpaused that is). The Amoeba also has sound during pause mode which shouldn't be.

Amoeba sound is played for an inactive amoeba, but shouldn't.

The Amoeba sample is quite repetitive, while the build up effect is a luxurious 7 seconds, eventhough it isn't played for more than 4 seconds in the game.

The walking noise should play as fast as the actual walking, but isn't.

The sounds from the last moments of the cave are playing over and over again when the time is up. After time up, there should be no sound at all, once the last tone is faded off.

Most of those sound issues should be come by with emulating the sounds rather than playing samples. It doesn't require a complex SID emulation, as Boulder Dash does use very basic synthesis only. Some simple triangle and noise generation with ADSR and volume adjustment is all which it needs.

hi

i will correct most of the sound errors. and i think i will not use a sid emulator or something like that... i'm not willing to code it. and this way, with samples, the sound can also be "themed."

one interesthing thing is that the sound is somewhat different, when mixed by the linux and the windows version of sdl. i don't think i can do anything about it... that is why bonus score seconds sound different on windows. on the linux version, every "ding" can be heard (for 9, 8, 7, ... seconds).

one bugreport by myself: the game currently allows playing after the time is up so this is a bonus version

bye

hi

if you want to compile, you can select the dependencies with the usual --with flags, for example:

./configure --without-gtk && make

will compile the sdl version with sound, and no gtk+ is needed.
if you compile the sdl version, sdl, sdl-devel (the development libraries, check libsdl.org), sdl-mixer, and sdl-mixer-devel are needed.

glib is always needed, as it is used for many other things. (also, glib-devel is always needed). there are no other special dependencies.

i will write about these things in the readme file later.

bye