Boulder Dash Forum

*) Sometimes I have the feeling that GDash is not as fast as the real
one. Is this my computer or is the speed of the game a little bit slower
than it should be?

Feels right to me. The scrolling is a bit different, though I like it the way it is.

*) In editor: When using the "Point" drawing tool it would be nice if it
draws the selected object as long as I press the button. Not only single
elements at single clicks. Would be easier to draw. Or add another tool
which can do this.

When drawing a map, continues drawing makes sense, but when building Point-objects, it pretty much would defeat its purpose of using little RAM. This could be an option, but the user should aware of what he's actually doing then.

*) I think the "Draw:" and "Fill:" menus are too complex. Don't you
think it would be better to show all elements in the sidebar or similar?
Maybe another sidebar on the right side of the screen? Or at the bottom?
Or even above? At the moment it is not the fastest method to select the
item I need. Maybe in the "View" menu, another sidebar with all objects
(including description as in the pullup-menus)?

In my upcoming engine, I thought of organizing them in the way they are in CLCK, but giving them tool tips describing them. In addition, I'd add a submenu with the internal elements for use with effect commands.

*) When Rockford is running out of the screen on right side, it should
appear on the left side one line under it. Now he is comming in in the
same line.

In fact, this should be optional, but available.

editor or importing tools
- eg enable diagonal movements for all caves

There should be command line options for those special cases. Also there are some games with global Diego Effects which also needs a parameter.

I like the fact, that you release the code under GPL. It's not the best idea to bundle the engine with the official graphics, though. This better be an add-on I'd say. If you like, you may use my Dash Dimension graphics for the official elements to bundle them with your engine. The additional elements should be fine taken from CrLi, as they never were commercially distributed.

I think as long as nothing is earned by this project First Star Software does not matter. They only do not like using "Rockford", "Boulder Dash" or the original Levels from Boulder Dash 1, 2, 3 or 4. They never said anything about graphics or sounds. And if they say something they will e-mail not to use it. As long as they do not mail all is ok. By the way: In my opinion they can not do anything about useing C64 data, there is no international law - they can only awe or threat you but nothing else. If you live in the US maybe they have possibilities but here in Europe...

The only thing I would do is to remove the original Boulder Dash 1, 2, 3 and 4 from the official distribution. You can offer it in another game pack. If FSS does not like it you can easily remove the game pack and the main program is untouched.

I love how this handles the 5 levels and the drawing instructions - excellent work, cirix!!

I only have 2 things to take note of:
1) I'm almost positive this is a bug: When map-drawn caves are converted the converter places hidden exits where regular exits should be, and vice-versa.

2) I haven't found a way to directly save changes to caves [and keep them in gdash format] without writing a BDCFF file or something like that. If the level editor is to be used for people creating their own gdash cavesets, this is a very important thing to have.

Other than those, I think this is amazing!

RTADash wrote:I haven't found a way to directly save changes to caves [and keep them in gdash format] without writing a BDCFF file or something like that. If the level editor is to be used for people creating their own gdash cavesets, this is a very important thing to have.

Are you sure, the games you are editing actually are in a Gdash format to begin with? As I understand, all games coming with the game are still the native C64 cave data with merely the engine removed. And since the editor has much more options then the original C64 engine, saving back isn't possible.

On the other hand, if you start creating a new game from scratch, it should be in deed possible to save the changes. BDCFF should be fine for that purpose, as long as all Gdash features are supported.

To address the issue of editing games and save them back to its original format, my upcoming engine will have a restriction setting to ensure that the caves are compatible to the target engine. Maybe, such a thing could be added to the Gdash editor as well. This would include not having a level feature for PLCK, 1stB and CrLi games.

EDIT:
I added the AltDirt attribute to the data base. If you want to export a forced on Dirtmod cave, use this BDCFF line:
AltDirt=DIRT

The problem is that I get this when loading a BDCFF:

**ERROR **: file caveset.c line 301 (caveset_from_new_bdcff): should not be reached aborting...

and then a Runtime error.
and...

**ERROR **: file caveset.c line 664 (caveset_save_cave_func): should not be reached aborting...

when saving.

Unfortunately I can't get any2gdash to work, even in a DOS emulator.

I have WindowsXP with service pack 2 if it matters.

hi

i (hope i) corrected the saving/loading error. sorry for this; anyway, bdcff saving is still preliminary, i don't really like working on that (writing a parser is just boring), but i will. the new installer is uploaded.

other changes:
- crli correct diagonal moves
- remaining time added to score
- slower explosions compatibility flag for 1stb and up
- new title screen by cws
- (simple but nice) pal emulated gfx

bye

I noticed one really annoying bug: Boulders can not be pushed while carrying a bomb.

cirix wrote:- (simple but nice) pal emulated gfx

Actually, this should be called a scanline emulation.

PAL is a color system. A PAL emulation would require separating color from brightness and averaging the color part from the previous line to the current line and applying a low pass filter to it. Would be nice to have this as well, of course. Brightness should not be filtered, unless you intend to have a CVBS emulation as well.

With all this attention to detail, we really need the original font as well, reconstructing BD's status line.


You should put a copy of the GPL licence file in the install dir and also mention that it is released under GPL in the about window.

Yet another bug: Your help window is broken.

LogicDeLuxe wrote:I noticed one really annoying bug: Boulders can not be pushed while carrying a bomb.

You are right! This is really annoying. Some caves can not be solved because of this bug!

LogicDeLuxe wrote:

*) Sometimes I have the feeling that GDash is not as fast as the real
one. Is this my computer or is the speed of the game a little bit slower
than it should be?

Feels right to me. The scrolling is a bit different, though I like it the way it is.

It's interesting - on my PC GDash seems faster as on MacOS X. Not THAT much but noticable.

*) I think the "Draw:" and "Fill:" menus are too complex. Don't you
think it would be better to show all elements in the sidebar or similar?
Maybe another sidebar on the right side of the screen? Or at the bottom?
Or even above? At the moment it is not the fastest method to select the
item I need. Maybe in the "View" menu, another sidebar with all objects
(including description as in the pullup-menus)?

In my upcoming engine, I thought of organizing them in the way they are in CLCK, but giving them tool tips describing them. In addition, I'd add a submenu with the internal elements for use with effect commands.

A more straightforward menu would really be nice. At the moment it takes too long to find the element I want. Maybe a sidebar with all elements in it, sorted in groups with description, would be the best solution?

as doing my phd in electrical engineering, i think i REALLY know what pal is and how it works. just simply people call this "striping" pal emulation in vice.

cirix wrote:as doing my phd in electrical engineering, i think i REALLY know what pal is and how it works. just simply people call this "striping" pal emulation in vice.

My VICE has "Double scan" and "Double size" in the "options" menu. If "Double scan" is unchecked and "Double size" is checked, I get scan line emulation. There is also a "PAL Emulation" which is completely unrelated to that scan line emulation and does the color thing. So don't blame VICE for miss naming.

Shouldn't be the menu "Cave Editor" placed in the "File" menu? It does not seem to fit in "Play". I noticed it today for the first time that it would better fit in the "File" menu, right after "Load internal game" (with a devider line above and under it).

Two things I would like to see in the next version:

Can you please additionally add the four colors for the cave in the tool bar right besides the "Draw join" tool (like the pullup-menus for the elements)? It would be faster to see the result than with the cave settings.

And please add a drawing tool for ongoing drawing. The "Draw single object" tool is not efficient for that kind of task.

By the way: I think "Load and save snapshot" would also fit better in the File menu. Same as "Cave editor". Would be logical.

LogicDeLuxe wrote:

cirix wrote:as doing my phd in electrical engineering, i think i REALLY know what pal is and how it works. just simply people call this "striping" pal emulation in vice.

My VICE has "Double scan" and "Double size" in the "options" menu. If "Double scan" is unchecked and "Double size" is checked, I get scan line emulation. There is also a "PAL Emulation" which is completely unrelated to that scan line emulation and does the color thing. So don't blame VICE for miss naming.

I like the PAL mode of GDash. Real PAL emulation would be nice but I think not that important (the code should be available through the VICE distribution).

Name it simply "Scanline mode" in the Prefs and all are happy...