Gdash

[CWS]

I noticed a little graphics bug with PAL emulation: There is a faint darker grey shadow drawn on the side of each object that does not fully fill a cell (e.g. letters of the status line in sdash or Rockford himself). It's not always but very often. It looks strange.

[LogicDeLuxe]

Perhaps you could allow five different numbers for amoeba time, magicwall time and slime permeability, too?

I mentioned these in the R'n'D-Forum.
Except for SlimePermeabilityC64, which can take an optional seed parameter. If this is really desired, we could change that seed parameter to SlimePermeabilityC64.seed instead.

[LogicDeLuxe]

I see, you use something like
SnapEffect=EXPLOSION1
Wouldn't it be more consistent to use
Effect=SNAPEffect EXPLOSION1
instead? Just an idea.

- I'd like to have the option to apply the current cave timing settings to all the caves at once, just in case the game I'm importing doesn't have any timing settings.

Since BDCFF supports this, this makes sense, at least for some parameters.

- It would be nice to have a next/previous cave button in the editor.

Indeed. I'd also like to have this. Makes it much more convenient to quickly check a caveset.

- Eventually I'd like to have the option to choose between C64 and Atari sound sets.

Sound themes would make sense, just like it is done with graphic themes.

Also, does anyone have any cave timing suggestions to replicate the Atari BD2? Right now I'm using "BD2 timing, 12, 6, 3, 1, 0."

Since the Atari has a higher CPU clock and the implementation there also takes much less rastertime, the milliseconds based timing should be very close. You still have to measure the exact timings, though.

[CWS]

I'd like to have the option to apply the current cave timing settings to all the caves at once, just in case the game I'm importing doesn't have any timing settings.

Since BDCFF supports this, this makes sense, at least for some parameters.

I agree to that. At the moment it's only possible to reset each single option. A general button for that would be nice.

It would be nice to have a next/previous cave button in the editor.

Indeed. I'd also like to have this. Makes it much more convenient to quickly check a caveset.

Yes, that would be a good idea. There could be included two arrows (one left and one right) right next to the index button in the task bar.

Eventually I'd like to have the option to choose between C64 and Atari sound sets.

Sound themes would make sense, just like it is done with graphic themes.

I thought of this, too! I think the easiest way would be this: a subfolder like /usr/local/share/gdash/sounds. In the subfolder /sounds (or /soundsets) there could be another subfolder called /classicsounds or /gdashsounds or /atarisounds and so on. And a option in prefs to choose what sound folder should be used (of course, the one shipped with gdash has to be used as default). This would be especially a good idea because at the moment all sounds are in /usr/local/share/gdash along with all other things - cave sets are in subfolders there but sounds not. Looks messy at the moment.

[cirix]

I see, you use something like
SnapEffect=EXPLOSION1
Wouldn't it be more consistent to use
Effect=SNAPEffect EXPLOSION1
instead? Just an idea.

Not consistent. You said we should stay consistent with c64. a falling boulder scanned is changed to a firefly by the effect table: Effect=fallingboulderscanned firefly. This is not an effect in this sense.

[LogicDeLuxe]

I noticed poor "true" randomness in the editor.

If you start a cave several times in a row, the amoeba grows exactly in the same pattern each time, given you don't block the amoeba differently, which is quite common in some caves, where you don't have access to the amoeba area right in the beginning. Other random events like pushing boulders also "breaks" that predictable pattern. A good cave to check this is BD3 CAVE K if you don't push boulders and don't blast the wall.
The same thing happens with other random elements like ghost movements.

Sound and animation seems to be independent from this, though.

This only happens in the editor. It is not reproducible in a regular game. If you close and reopen the editor, the randomness is completely different, though repeatable as before.

[LogicDeLuxe]

Effect=fallingboulderscanned firefly. This is not an effect in this sense.

Besides it's Effect=BOULDERd FIREFLYl which is the way some games actually did this, it is as consistent as BOULDERbouncingeffect, MAGICWALLbouldereffect, AMOEBAbouldereffect etc.
I know, it is not actually part of the effect table, but deeply into the code. Though I already extended the effect table with those pseudo-elements to simplify custom effects in The new Dash Dimension which worked out well. I also intend to do this in XDC, so there will be an extended default effect table including those pseudo-elements.

Btw. there is a significant difference between Effect=BOULDERd FIREFLYl and Effect=BOULDERbouncingeffect FIREFLYl
Applying an effect to BOULDERd also affects a pushed boulder, while BOULDERbouncingeffect only influences a boulder which was falling before, since only the code looks up this pseudo-elements.

Currently, CrLi patches the code with the effect bytes whenever a cave starts. This requires a separate copy instruction for each effects and also uses bytes in cave file, even when it doesn't divert from its "default value". That is what Prof. Knibble implemented and is indeed an improvement over the old method. In XDC, there will be just the default effect table, which can be copied to the actual effect table with a simple loop, and only effects actually used in the cave will require extra bytes. Just like you don't need effect instructions in the BDCFF file if not desired.
I know, having basically a second effect table will take extra space which defeat the saved bytes in the cave, though I cleverly arranged the elements so I can shorten the tables by 64 bytes each, thus the difference in size is minimal.
The biggest thing will be probably the scroll routine anyways, since speed is much more important there than size.

[CWS]

Another small bug: with the option "Overview (game)" most of the marked elements are shown with the marks. This should be only the case when selecting "Overview" (without "game").

Something completely different: Is it possible to include an option in prefs with which it can be set if the element box should be automatically closed when selecting one element or not. Sometimes it would be nice if the element box closes after selecting one, sometimes it would be nice if it would stay open. Or maybe it could be solved as in CLCK on C64. With the left mouse button box stays open, with the right mousebutton box is closed after selecting an element.

And something concerning sdash: After loosing a game could you show the last selected cave? At the moment it always shows the first cave. Maybe this could be an option for the option menu?

non-sloped and sloped brickwalls can be hammered with the pneumatic hammer but do not disappear. Magicwalls and explodeable titan walls can not be hammered - wouldn't that be logical that these both could be hammered as both are destroyable?

I think there should be an option in cave properties/compatibility that mega stones can be pushed after eating a sweet.

[cirix]

Besides it's Effect=BOULDERd FIREFLYl which is the way some games actually did this, it is as consistent as BOULDERbouncingeffect, MAGICWALLbouldereffect, AMOEBAbouldereffect etc.
I know, it is not actually part of the effect table, but deeply into the code.

That is not a reason, and I'm also not really interested in HOW any game implemented this. The only important thing is what the user sees. The user will only care what he sees. It is up to the programmer how he implements it. Also, the file format MUST NOT make any assumptions about the internals of the program. (Just for an example: a) gdash does not have an effect table b) gdash does not have any "delayed" elements which are different from the original ones. Still, it seems to work, I think. And I hope it is the most compatible clone, ever.) That is the main problem of bdcff. It is not common in any way. Most if it just would not make any sense for emerald mines, for example.

Therefore, this is the point I'm asking you to not waste my time with saying that my game should be compatible with

• a) a completely different game
  b) some game which does not even exist.

And I suggest you to do this favour to yourself, too: don't waste your time, either.

[CWS]

Don't be angry at him - I'm sure it was well-intentioned. As he is at the dawn of programming his one engine it's certain that many things are rushing through his head at the moment. A true perfectionist with the best insights of the Boulder Dash source. I know this - I'm also a perfectionist and it's exhausting and annoying sometimes - for all involved parties... But no offence!

You are totally right - it's the most compatible clone ever - and the best one I've ever encountered in my life! And it's working on many platforms - the best decision ever made! I must admit I do not play any other clones anymore. GDash accomplished the goal that no other clone ever reached - it's better than the good old original game! And that's not an exaggeration!

Another thing I just want to add to my last posting: I think it would be really the best idea that clicking with the left mouse button on an element in the element box closes the box immediately, but using the right button it stays open. This would allow me to design a new cave even faster! With this method you do not have to include any option in preferences or such thing - just using the mouse buttons.

[cirix]

Ah, and something else: Why is the border color not used? It can really change the impression the player gets of a cave sometimes!

I don't really have place for that on the screen. The C64 had a 320x200 screen, and a very big border. GDash also opens a 320x200 screen -> no place for the border. I do not want to open a larger screen (or window), as it would mess up with the standard VGA resolutions which can be used for fullscreen (320x200, 640x400... and maybe 1280x800 on 16:9 screens - that's what I also use on my notebook. Note that it is exactly 4x the original resolution! The globe in UFO: Enemy Unknown globe is a circle at last - if you also like that game, too.)

[RTADash]

1280x800 on 16:9 screens - that's what I also use on my notebook.

Me too, I can also attest that it takes up the full screen with no gaps. (And it looks great, too!)

[Dustin]

Ah, OK, I get it, that would be a too big effort indeed.

[Dustin]

I noticed that there's a difference in the random fill if you set it by the "classical" random fill or as an object. For example I tested with the fill
Space 60
Boulder 50
Diamond 9
If I set this with the random seed 10 in the "classical" random fill, I get indeed the fill of Bd1, cave A/1. But if I set this as an object (rectangle from 1,1 to 38,20), there comes out a completely different division! Why is this so and, more important for me personally, is there a possibility to reproduce the BD1 A/1 random fill (say) when I set the random fill as an object?
(This would be very nice; then I could make the RockFort games in Gdash much closer to the bremake version and wouldn't have to test through all the seeds again! the thing is that I have to use the object random fill as to vary densities between the levels.)

[LogicDeLuxe]

I noticed that there's a difference in the random fill if you set it by the "classical" random fill or as an object. For example I tested with the fill
Space 60
Boulder 50
Diamond 9
If I set this with the random seed 10 in the "classical" random fill, I get indeed the fill of Bd1, cave A/1. But if I set this as an object (rectangle from 1,1 to 38,20), there comes out a completely different division! Why is this so and, more important for me personally, is there a possibility to reproduce the BD1 A/1 random fill (say) when I set the random fill as an object?
(This would be very nice; then I could make the RockFort games in Gdash much closer to the bremake version and wouldn't have to test through all the seeds again! the thing is that I have to use the object random fill as to vary densities between the levels.)

Your right. I guess, a different random number generator is used. Besides, it's 0,1 to 39,20 what the original fill does, and it draws the steelwall border afterwards. It still is different. I think, it should be possible to reproduce the same behavior for exactly your reason. Different random number generators are nice, but there should be the possibility to choose from them.

Maybe, we could have objects RandomFillC64 and RandomFillPatternless, or add an algorithm parameter somewhere before the element list. Which could be "C64" or "patternless" then. Since there are no BDCFF files using it yet, there is nothing to break for now.