Gdash

[RTADash]

gdash and sdash cannot interpret the same file differently. if this is the case, you must be using different versions of gdash and sdash; as the same source file is linked into both of them.

I was using version 20080903 of both of them - I just that meant in terms of playing in sdash versus editing in gdash. It might of been a windows vista security issue, but gdash kept crashing when I tried to save changes to the BDCFF caveset - that's why I edited them manually in notepad. Alas, this wasn't an issue in sdash because it doesn't save cavesets.

[cirix]

hi

logicdeluxe:
i haven't really thought about which maze algorithm to use. the recursive would not be easy to implement on a c64. neither would be the growing tree (see the daedalus page for the explanation), but i think the growing tree would be the best.

but it is easy to switch - or does anybody use "predictable" mazes?

bye

[LogicDeLuxe]

or does anybody use "predictable" mazes?

Not yet. I plan to do mazes in XDC, and since GDash is the best option for the cave author, it should offer a C64 friendly maze algorithm.

A temporal array should be no problem. The virtual screen buffer can be used for this. Thus you have about 3.5 kB working space available. Should be plenty for usable algorithm, I think.
A pain would be excessive stack usage, since the C64 only has 256 bytes there. So recursive algorithms better be avoided.

I also might implement cavern and/or crack mazes in XDC. So if you implement those, think of a C64 friendly implementation there as well.

[cirix]

hi

rtadash: if gdash crashes, that is 99.9999% the problem of gdash. please try to reproduce the bug, and explain to me in pm how to make it crash! for example, by loading boulder dash 1, editing cave e, drawing a line here, drawing a rectangle there, saving and BOOM it crashed.

logicdeluxe: unfortunately both the recursive algorithm and the growing tree algorithm need a stack, or some memory organized as a stack. therefore, we might stick to your crazy dream 9 algorithm - which might be called the hunt and kill (see the daedalus page).
about crack mazes: aren't boulder dash caves too small for crack mazes? maybe if you drew a cave with the original objects (use the freehand tool), which is similar to the crack maze you are intending to design? and send me the bdcff or a screenshot, so i can see and understand the idea.

bye

[LogicDeLuxe]

CaveScheduling is ignored by GDash in the [GAME]-section. Using it there would make sense, since you rarely have cave sets with more than one timing model in it.

about crack mazes: aren't boulder dash caves too small for crack mazes?

Why do you think so? Here is a 40x22 crack maze in Daedalus:

Looks usable to me.
As said, I'm not sure about implementing it anyways.

Unlike in perfect, unicursal and braid mazes, any position could be blocked by a wall in crack or cavern mazes. Thus it would be very handy if we could force a certain entry and/or exit position, so you can build upon it in true random mazes.

[Dustin]

Hi,
I've got a little problem with the converter to CLCK format. Somehow I cannot open the converted file, neither with the CLCK (it cannot find the file) nor directly in the VICE emulator. Can you help me, please?

[LogicDeLuxe]

Hi,
I've got a little problem with the converter to CLCK format. Somehow I cannot open the converted file, neither with the CLCK (it cannot find the file) nor directly in the VICE emulator. Can you help me, please?

Did you export a cave or a game? If your file is a cave, you can open it in CLCK. If it is a game, you can only open it in the link tool or in the cave packer.

[LogicDeLuxe]

Player birth is missing from the Element menu. This is used as an effect in the first Cave of Crazy Dream 9 for instance.

[Dustin]

Where do I have to save the exported cave? Somehow the CLCK cannot find the file...

[cirix]

hi

Dustin: use any d64 utility to copy the saved file to a c64 disk image. like star commander or c1541 which comes with vice.

or optionally, let vice read files from the filesystem.

bye

[LogicDeLuxe]

For copying files into, out of, within or between images, I recommend 64copy

While CLCK works with d64 images, it is very limited in disk space. A d81 image is highly recommended for use in VICE, so disk changes can be avoided completely.

[CWS]

I do not know what OS you use but on MacOS X with Power64 you can simply create a disk image you like (D64, D81, etc.) and drag & drop the file from the Finder into the image. No separate program needed.

[cirix]

hi

0915, featuring

- many new sounds (some are optional, stolen from c64 games )
- 2 separate flags for hatching delay, so no more confusion (old bdcff has to be corrected in the gdash editor, though)
- correct speed of bd2 intermissions
- different graphic scaling for game and editor
- graphic scaling for sdash
- scale2x
- scrolling title screen
- sdash themes (only from bmp)
- negative "diamonds needed" count at hatching
- optional name-of-game in sdash status bar
- others


if there is some bug, tell me.

two questions:

- after playing many caves, how would you correct the volume of sounds? ie. "amoeba should be more quiet", "stones should be louder"

- you have written much about editing bdcff files by hand. for example, correcting the hatching delay thing in a text editor, or putting cavescheduling tag in the game section. why are these important? what are the things, which cannot be done in the editor? (cannot be done at all / cannot be done comfortably).
the thing is, you see, there was an ancient, un-published version of gdash, which had its own file format besides bdcff. that was real xml (with libxml2), and that one did not have any of the mentioned disatvantages (induced by trying to be compatible with c64 or old, outdated bdcff files.) but that was dropped, as i did not want to maintain the code of two different formats at the same time.
just had to tell.


bye

[LogicDeLuxe]

- you have written much about editing bdcff files by hand. for example, correcting the hatching delay thing in a text editor, or putting cavescheduling tag in the game section. why are these important? what are the things, which cannot be done in the editor? (cannot be done at all / cannot be done comfortably).

While it is not important for GDash to work, there are several reasons to support this:

- The BDCFF logic demands this. Other (future) engines may have parsers which don't have that restrictions, and therefor files which have those settings global will not work as intended in GDash.

- Readability. That one is one goal of BDCFF. If settings are the same throughout the entire game, it makes much sense to have those set globaly.

- Space. While this certainly is no issue in a BDCFF file itself. It would make things much easier when it comes to converting to other systems. In my XDC engine, there will be a "global cave" which has all the default settings, even the DIRT field and the STEELWALL border. My engine will first set and draw everything of that "global cave" before processing each actual real cave. The idea is a common base which is shared by all or most caves, thus saving RAM of the very limited C64.
Luckily, BDCFF pretty well supports this by design. At least for all those settings. The default drawing is implied by Initialfill and Initialborder.

Once my XDC engine is done, you might even consider allowing cave objects in the [game] section, but without any [cave] section as well.

Now, I'll check out the new GDash version.

[cirix]

gdash has that global cave internally, but that one cannot be seen in the editor. it wouldn't be very intuitive... one does not think "ok, let's design a bd1 caveset". anyway, in gdash, i think i will put "set bd1 defaults", "set bd2 defaults"... menu items in the editor for caves.

another thing i wanted to mention: yes, i know that rockford looks "crying" when you select scale2x. this afternoon i did hq2x (see http://www.hiend3d.com/hq2x.html page), but it is not really better - in that one, rockford looks like a devil i suppose every graphics theme will have a different scaler, which is best suitable for it.
nearest, bilinear, scale2x, hq2x:


maybe if we want pretty 2x c64-look-alike graphics, it really must be done by hand.

bye