Boulder Dash Forum

cirix wrote:unfortunately. sdl only supports runtime fullscreening and unfullscreening on x11 (not even on windows), so i do not use it.

ScummVM can swap between fullscreen and window during runtime anytime.

cirix wrote:
unfortunately. sdl only supports runtime fullscreening and unfullscreening on x11 (not even on windows), so i do not use it.
ScummVM can swap between fullscreen and window during runtime anytime.

do code it, send me the patch, i will apply it. i don't really care these things.

In your BDCFF, BOX should be called SOKOBANBOX. It was renamed to avoid confusion quite some time ago.

Your char code definitions should not use the &. This is reserved since BDCFF should support parsers with HTML like character coding. (Just like <, >, [ and ] shouldn't be used as char codes.

hi

new version released, *0901.

changes include:
- small bugfixes
- fast forward in sdl version
- 44khz ogg vorbis sounds, selectable 44khz mixing
- crli exporting vertical expanding wall bug corrected
- different sounds for different actions (more to come), eg. stirring, teleporter, pneumatic hammer, falling wall
- original c64 font for status bar
- slime obeys gravity; waiting stones, bladders, falling walls optionally obey gravity
- bladder push direction obeys gravity changes
- mega boulder (new element proposed by Sendy)
- sloped dirt, brick wall and steel wall (new elements proposed by Sendy)
- some small bdcff errors
- crazy dream 7 timing

still no replays, but next release

bye

hi

do you think that...
- rockford should be able to push a mega boulder, if he ate the sweet (candy)?

what do you think, how should gdash handle replays? always remember all caves played (or successful playing of caves)? how should the user be given the option of saving some replays, and some other not? should replays be in a separate file?
popping up a window every time after playing a cave is of course not an option...


bye

cirix wrote:hi

do you think that...
- rockford should be able to push a mega boulder, if he ate the sweet (candy)?

As this is no official Boulder Dash element until now I think this could be made optional!

cirix wrote:do you think that...
- rockford should be able to push a mega boulder, if he ate the sweet (candy)?

Maybe, you could make it a variable, so that the author of the cave sets a number of how many sweets are needed to make it pushable. A zero could mean never. And negative could mean sweet count minus number.

Alternatively, you could make it use up sweets, ie. for every sweet eaten, the megaboulder could be pushed one step.

Hi,
I discovered a mistake in my version; I don't know if it was already mentioned here (I haven't read everything...)

If a boulder/diamonds falls from another one, and if it has a choice to which side it falls, it should fall to the left side, but it actually falls right in Gdash.

Dustin wrote:If a boulder/diamonds falls from another one, and if it has a choice to which side it falls, it should fall to the left side, but it actually falls right in Gdash.

It behaves exactly like the C64 version for me. Just checked in BD1 Cave I/1.
C64:

Gdash:

There is a reproduceable bug: After loading Crazy Dream 7, selecting cave "Push", eating the sweet and pushing the stone to the very right so it falls through the magic wall, GDash crashes, in my case GDash quits immediately and leaves no crash log. It behaves like this every time I try it that way.

One problem I'm noticing is that BDCFF files saved in an older version that loaded up fine [in that version] are now said to have errors all of a sudden.
Also, the Inbox has been taking an inordinately long time to open in those BDCFF-saved games, when it was also fine before.

hi

Dustin: you are using an old version. this bug (related to implementing gravity) was corrected in this one.

RTADash: check the timing settings of the cave. Hatching delay might be seconds for c64-schedulings, and frames for milliseconds-based. No consensus for that in the BDCFF, unfortunately. I will also check the game.

CWS: that one affects all magic wall caves.



!!
so i uploaded a new version, *0903. the magic wall error discovered by CWS is now corrected. no other changes.

bye

Thank you for the fix! It's working now!

Another thing: It would be nice if the graphics in sdash could also be set to double or triple size.

If I set full screen the computer switches to 640 x 480 but graphics are about 320 x 200 so it's not fully full screen.

The Scheduling type only lists BD1, CD7 and Construction Kit. But what about CLCK? Does it have the same timing as Construction Kit? Really? And BD2? Does it have the same timing as BD1? How does it detect which timing is the correct?

Would it be possible to set the graphic scaling independently for the game and the editor? For instance, I'd like to play in "double" while I prefer the editor window at "normal".

CWS wrote:The Scheduling type only lists BD1, CD7 and Construction Kit. But what about CLCK? Does it have the same timing as Construction Kit? Really? And BD2? Does it have the same timing as BD1? How does it detect which timing is the correct?

Didn't you do the research on this?

There sure are differences. BD2 is probably slightly faster due to code optimizations than BD1. Intermissions are the same speed as caves, which was not the case in BD1.

1stB has more code optimization than PLCK which makes it faster, but also more elements to animate which makes it slower: Slime (which has its own graphics now), biter, bladder, ghosts and 3 quarter of the magicwall added. That means more raster time used, so that the difference between an empty cave and a heavily loaded cave is even more apparent than in PLCK, while an empty cave is still pretty fast.

CrLi is very slightly faster, since it lacks the ghost animation.

Crazy Dream 7 sure would be the slowest since it has also alternate fireflies and butterflies. Also introduces water and cows. Thus, much more rastertime used up. Also the sample playing routine and the reappearing hammered walls have major impact on the speed.

All engines since PLCK would have the same TV field based timing (20 ms resolution on PAL), I think, but the maximum speed possible would be quite different, apparently.