Gdash

[Arno]

Czirkos Zoltan is developing a new BD clone called Gdash for Windows and Linux.

The current version is available online at:
https://bitbucket.org/czirkoszoltan/gdash/

There is also any2gdash.exe, a tool that converts memory snapshots of BD1, BD2, PLCK, Crazy Light and 1st Boulder caves to the Gdash format!

Czirkos told me that the game also reads and writes BDCFF files although it's not 100% error free (I haven't tested yet...). And it uses the original graphics, and the engine is pretty close to the original.

If this is all true, this game would potentially be the best BD clone ever!
Unfortunately I've very litte time recently, but can't wait to try this much promising clone!!!

[LogicDeLuxe]

You don't have permission to access /~cirix/gdash/gdash-0.9-installer.exe on this server.

[Arno]

The files are available now!

[LogicDeLuxe]

Looks promising. Most features of C64 engines and The New Dash Dimension seem to be there already. No sound, though. I guess, it will have Atari sounds finally as it apparently is much Boulder Rash inspired. Having also SID sounds in addition to that would be great.
Certain caves crash immediately.
I don't like those Boulder Rush default colors. Hopefully, the final version will support custom colors.

The "full screen" feature seems to be actually a "maximized window" feature, which isn't too useful, as it makes a window a lot bigger than the actual cave in the average game. A true full screen and low-res mode would be a good idea.

I noticed one interesting thing: Multiple Inboxes have synchronous flashing, which doesn't exist on any C64 engine, yet Rockfords do appear in the original C64 pattern which is actually caused by the asynchronous flashing behavior.

I wonder, why BD1 engine games sometimes have a BD1 extension and sometimes, they have a NO1 extension?

I also wonder, when it is supposed to convert Crazy Light caves, why is there none in the collection coming with the game?

[CWS]

Wow! Finally a good new clone!

I wonder if it would be possible to compile the Linux version on MacOS X?

Keep on doing your great work Zoltan!

[cirix]

hi folks,

at last i'm registered to the forum, so i can reply

thank you for the feedback so far!

LogicDeLuxe:
- unfortunately the windows version of gtk+ does not support fullscreen mode correctly. as i'm not really into windows programming, i think this will be of minor importance for some time.
- for colors, you can edit the cells_gfx.png file that is installed with the game. you can also use play|select theme to load the new and to resize it.
- synchronous flashing of inboxes: maybe i can realize the "checkerboard", but the correct appearing of rockfords is more important. that is already implemented.
- bd1/no1: technical reasons. no one's final boulder was the first collection i imported to the game. its files on the disk are a little bit different than the in-memory bd1 cave data documented by Peter Broadribb - the no one file was missing some bytes, colors and the like. the .no1 files are c1541 -extracted from finalbd.d64.
- crazy light caves: you can use the any2gdash tool to import them from a c64 snapshot. my game does not have a labyrinth generator yet... also borderless caves work a little bit different.

CWS:
i think it is possible. try gcc and the gtk+ for mac to compile. http://developer.imendio.com/projects/gtk-macosx
so far, i've tried it on linux, win, and *bsd, and it worked.

bye

[LogicDeLuxe]

- bd1/no1: technical reasons. no one's final boulder was the first collection i imported to the game. its files on the disk are a little bit different than the in-memory bd1 cave data documented by Peter Broadribb - the no one file was missing some bytes, colors and the like. the .no1 files are c1541 -extracted from finalbd.d64.

Interesting. I never did take a look at the actual file format. Its own format, just to save some bytes for colors? That sounds insane.

- crazy light caves: you can use the any2gdash tool to import them from a c64 snapshot. my game does not have a labyrinth generator yet...

I guess, the labyrinth generator can't be automatically imported anyways, because it is hardcoded in the Crazy Dream 9 engine, and only used there. I wanted a quick way to use the CLCK as usual, and added those mazes in the engine (including the title screen).

I noticed that most Crazy Dream 3 caves are broken (those can crash the game). IIrc, I did some extensions to the drawing instructions. I don't have any documentation for them, unfortunately. Though, I think, I used the spare bytes after the colors for Diego Effects.

Both issues would be of an equally low priority as the Crazy Dream 7 engine, I guess, since there is only one game using them.

I see that PLCK caves don't get their names or selection table converted. My XXX2DAS code has a detection for named PLCK caves, and it reads out the selection table in all cases. (No PLCK engine displays those names, though)
And 1stB/CrLi cave names should be no problem either, since they are documented in the Dash-FAQ.

About the chasing Boulders, that's one of the little parts of the code, I never touched, so reading through disassemblies is the only way to be accurate, I'm afraid.

Crazy Dream 1 and De Luxe Caves 3 require diagonal movement for all caves. It's an engine wide hack in those games, which was later added to 1stB as an per cave option.

Some caves of mine require the buggy BD1 magic wall behavior. Not only do they behave different then intended, but they aren't playable at all: De Luxe Caves 1 Cave L, De Luxe Caves 2 Cave A, Deluxe Caves 3 Cave A

And are you following the discussion about BDCFF definitions over here? http://www.artsoft.org/forum/viewtopic.php?t=1547 A lot was cleared out in the last few weeks and probably still will. So BDCFF support should be considered alpha state for now.

[cirix]

Hi!

LogicDeLuxe:

- NO1 format on final boulder disks: yes, only the colors and the unused bytes are missing from those files, compared to BD1 format. That is why caves had the same color, independent of which game you loaded (eg. cave c was always brown). The NO1 loader imported this, added its own colors, and generated the byte pointers.

- I'm also planning a labyrinth generator. I don't know if there are any caves which uses this, apart from your crazy dream 9 game. The exact algorithm is only important if there are "predictable" mazes, like predictable random elements used in the usual caves.

BTW, GDash also supports unpredictable caves, just try setting the random seed value to -1, and the cave will be different any time you play. Also you can set required diamonds to a negative value, and then required diamonds will be all diamonds found in the cave (the game counts them after generation) MINUS the number you gave. You can use this if there are some diamonds trapped under boulders and the like.

- Importing cave names, I'm planning to do that for CrLi and PLCK.

- Unfortunately I don't have too many information for Crazy Dream 3. I think there's no point in trying to automatically convert nonstandard caves; maybe convert them and then edit by hand, saving it in BDCFF. Also, for example diagonal movements in BD1, there is no reasonable way for any2gdash to find information about it in a memory snapshot.

- I checked the new BDCFF description, I think I will incorporate suggestions found there

bye

[cirix]

LogicDeLuxe:

as I mentioned, there are things that are currently not imported from snapshots. One more example for that is the cave selection table in PLCK cave sets. I remember versions of Knibble packer which allowed runtime selection of difficulty, and updating the cave selection table. For easy, you could select all caves, for hard, only the standard A, E, I, M. This way, it is not really a property of the caveset...

Currently, gdash detects if it finds a standard 4cave+1intermission cave layout while loading plck caves, and sets the usual selection table.

bye

[LogicDeLuxe]

- I'm also planning a labyrinth generator. I don't know if there are any caves which uses this, apart from your crazy dream 9 game. The exact algorithm is only important if there are "predictable" mazes, like predictable random elements used in the usual caves.

Since your engine is open source, others could just take the maze generator, then. I think, predictable mazes should use the same random number generator as the random elements. That was my idea for my next engine. My BDCFF-proposed object for this looks like this:

Code: Select all

Maze=x y seed number_paths_x number_paths_y path_thickness wall_thickness path_element wall_element [type] [replace_element]

seed=-1 means totaly random, ie. the cave appears different every time you play.
If replace_element is given, the maze is drawn over this element only, which makes it possible to have mazes in a none rectangular shape.
type can be

perfect: a perfect maze (default)
braid: a maze with no dead ends. Pacman style.
unicursal: without any junctions.

BTW, GDash also supports unpredictable caves, just try setting the random seed value to -1, and the cave will be different any time you play.

It's already in my proposal for the random object.

Also you can set required diamonds to a negative value, and then required diamonds will be all diamonds found in the cave (the game counts them after generation) MINUS the number you gave. You can use this if there are some diamonds trapped under boulders and the like.

This is a good idea. Maybe we should add this to the BDCFF as well.

- Unfortunately I don't have too many information for Crazy Dream 3. I think there's no point in trying to automatically convert nonstandard caves; maybe convert them and then edit by hand, saving it in BDCFF.

I eventually will write a universal converter, which not only should write BDCFF, but also convert back to common C64 engines, maybe some PC engines too.

Also, for example diagonal movements in BD1, there is no reasonable way for any2gdash to find information about it in a memory snapshot.

As you could basically check the walking code, it's probably not that important since there are only two games using it, and those are even different engines. Also, there are some games with common Diego Effects for all caves hardcoded in the engine. Those came before the Effect Kit 3.x and the effect enabled No One Packer was there. Also this can not be detected by analyzing the caves, but could by copying the bits from the engine, whenever a cave with no Diego Effects detected is converted, but probably also not worth the effort. I think, a command line option to the converter to force those settings would be a good idea.

[CWS]

i think it is possible. try gcc and the gtk+ for mac to compile. http://developer.imendio.com/projects/gtk-macosx
so far, i've tried it on linux, win, and *bsd, and it worked.

As I'm not very much into compiling or similar is there a quick introduction into this matter so I'm able to compile your great new game on Mac OS X? What do I do with gtk-macosx?

[CWS]

The more I use GDash the better it is! Man, this new clone is great! Better than ever! Good, the full screen thing is not solved yet and sounds are missing but I've never seen such a great clone!

It would be nice if the graphics and sounds could be replaced optionally by a more modern version (like my creation for Boulder Remake).

And a title picture for each game would be nice (if there is none a general title pic should be used). Maybe the title screen of the importet C64 game could be used for each single game? That would be really retro!

And I think there should be at least 2 or 3 different size versions of the window, of course, with double or tripple size graphics. You know it looks weird on a 20 " monitor at the moment...

Thanx for listening! And keep on doing your fabulous work!

[cirix]

CWS:

unfortunately i don't know mac at all, so i cannot help...


the graphics can be replaced, just check the cells_gfx.png that is installed with the game (c:\program files\gdash). after loading it (use play|select theme) the game will also ask you about resizing.

you can also have any resolution in cells_gfx.png. the two things important are:
a) keep the order of elements in the image
b) cells to be squares.
the original cells are 16x16 pixels, so the png is 128x512 pixels. if you use 32x32 cells, the png will be 256x1024 pixels, and gdash will also load that.
i recommend resizing the original png and pasting the cells one by one; if you do this, it would be nice if you sent me the result, as i could include it in the game as a different theme!

bye

[CWS]

Wow, thank you! I didn't see this option until you mentioned it!

I simple resized your original cells_gfx.png with Photoshop. Looks great with double size!

Now give us sound and we are happy for the moment!

One idea for future versions: I like the element variations of Boulder Remake a lot! So there are four different version of each element in the game. The good thing is that not all four different versions have to be used (for original C64 style only one version is used). But there is the possibility to use e.g. four different kind of boulders and diamonds in a game (maybe different shapes and colors). This would be really nice! The Boulder Remake autor also included 8 animation frames so animations are much smoother. The good thing is that for original C64 style graphics each animation could be used twice so you have the original C64 style animation type. This problem is really solved perfectly by the Boulder Remake autor!

Sorry you can not help with compiling it on MacOS X. Maybe there is someone else here who could help? At the moment I'm playing it on my PC but as I do not like Windows a MacOS X version would be very much appreciated.

[Arno]

One idea for future versions: I like the element variations of Boulder Remake a lot! So there are four different version of each element in the game. The good thing is that not all four different versions have to be used (for original C64 style only one version is used). But there is the possibility to use e.g. four different kind of boulders and diamonds in a game (maybe different shapes and colors). This would be really nice!

I personally would prefer to have the original C64 colors. That is, in the png file, one version of each element (or animation frame) in default colors, which vary in the game per cave according to the colors specified in the BDCFF or snapshot.

Perhaps it's the best idea to make both variants optional!