Boulder Dash Forum

New version: http://www.file-upload.net/download-127 ... 3.zip.html

Bugfix: Inbox in PLCK maps no longer crash XDC.

New BDCFFcompiler: http://www.file-upload.net/download-127 ... r.exe.html
Replace the version in the last zip file with it.

Bugfix: improperly set scroll properties.

Thanx! How do we switch the scrolling on/off per cave in BDCFF? I didn't find an attribute in the current document for that...

Arno wrote:Thanx! How do we switch the scrolling on/off per cave in BDCFF? I didn't find an attribute in the current document for that...

There are three settings XDC can handle.

Regular size of 40x22: No scroll, ie. 20x12 visible while the engine still processes the entire 40x22 of the cave: And if you don't need the invisible part, but just 20x12 The latter one is a bit faster, as the engine doesn't scan the lower lines at all, like BD1 does with intermissions.
You can easily set those sizes by GDash as well, so you don't even need a text editor to do that.
Also IntermissionSize and CaveSize are supported by BDCFFcompiler using the same values to specify common sizes.

Wow, this makes me happy!!!
I uploaded a preview of the game that I want to release for ages:
http://www.boulder-dash.nl/down/Tiny_bd_xdc.zip

Two strange things happen with the intermission (cave 5):
- It behaves like a normal cave (no instant life, no warp after faillure), but it clearly has Intermission=true in the bdcff.
- The bdcff has Selectable=false, but once the cave is played, it becomes selectable (even in the higher levels ).

Arno wrote:- It behaves like a normal cave (no instant life, no warp after faillure), but it clearly has Intermission=true in the bdcff.

I will look into it. There likely are several bugs in there at the moment. Currently, I change the BDCFFcompiler to have an analysis pass before the actual conversion takes place. This allows me to optimize several things. Ie. if no attributes about the borderproperties is specified, BDCFFcompiler will enable or disable scanning and wraparound automatically, depending if anything but steelwall is placed on the borders.

- The bdcff has Selectable=false, but once the cave is played, it becomes selectable (even in the higher levels ).

Currently, the engine automatically makes any cave selectable once played. It doesn't for intermissions, though.
I thought, it is rather annoying when running out of lives in an unselectable cave and forces you to replay the previous caves in this case, and this behavior prevents such a situation.

Level specific cave selection like it was present in some versions of original BD isn't supported. In XDC, selectable is always set for any level.

New version: http://www.file-upload.net/download-128 ... 8.zip.html

- BDCFF analysis pass. This enables autodetecting required border properties for instance, so the optimal setting can be used along with other things.
- All XDC-elements are recognized by BDCFFcompiler now. Not all are implemented in XDC yet, though.
- Bugfix: ignored flags. This affected the intermission in Arno's example.
- Bugfix: bonus life for each 500 points work again. (disabling this feature is a command line option in BDCFFcompiler).

Known problems: The RandomFill object is interpreted, but doesn't work yet and can crash BDCFFcompiler. RockFort1 should work as soon as this is fixed, except that one intermission also needs the "count diamonds at hatching"-feature, which is on the todo list as well.

New BDCFFcompiler: http://www.file-upload.net/download-128 ... 9.exe.html

- RandomFill object supported.
- PALtiming supported. All timing values will be converted, so be aware of roundoff errors.
- Initial number of lives can be set between 3 and 6.
- In plain C64 mode, amoeba color is only used for walls if there actually is amoeba (or slime 2) in the cave. Otherwise, wall color is used as specified.
- Bugfix: Required diamonds >99 will no longer require >99 for every level.
- Bugfix: Levelspecific Raster objects.
- Bugfix: Command line options really work this time.

Tested with Rockfort1.bd. There are still some missing features and minor issues, but most of it is playable.
- One problem are intermissions with not enough time to scroll all the way before hatching. That will be solved, as a wait for scrolling routine is on the todo list anyways, ie. mainly for leaving the cave and entering it on the opposite side, which has no such delay yet either.
- The other problem is the inbox in cave a. While inboxes are used to be placed either with a PLCK map or with a point object, this one uses FillRect. Thus, the cave does not scroll before Rockford is hatched and detected by the active scan routine. The same problem would occour on any other existing object based engine on the C64.

New BDCFFcompiler version: http://www.file-upload.net/download-128 ... 0.exe.html

- Amoeba, Amoeba2 and Magicwall properties.
- Bugfix: initial number of lives.

New version: http://www.file-upload.net/download-128 ... 1.zip.html

- Waits for scrolling when active guy wraps around.
- Waits for scrolling at hatching.
- Support for amoeba and amoeba2 maximum size and spread probabilities.

New BDCFFcompiler: http://www.file-upload.net/download-129 ... 2.exe.html

- Bugfix: Randomly wrong Atari colors.
- Bugfix: Default amoeba size.
- Bugfix: Amoeba and magicwall timers now work without specifying a TV-system.

New BDCFFcompiler: http://www.file-upload.net/download-129 ... 3.exe.html

- Diagonal movements.
- Short explosions.
- Map objects. In contrast to a [map] section, the map object can be used on any subset of the cave, ie. it doesn't have to be the entire size of the cave. Maps are still restricted to PLCK objects, though as you rarely need more than 16 different objects, a few Add objects can just replace the default elements with those you need using just a few extra bytes, while another map object would need more bytes in the majority of cases.

BDCFF page updated.

A Unix version would be very much appreciated. Without Windows it's not possible to use the compiler.

CWS wrote:A Unix version would be very much appreciated. Without Windows it's not possible to use the compiler.

Indeed. The final version will. It's not high priority right now, though.

In the meantime, does it work with WINE?
Would a DJGPP compile run in DOSemu? http://www.file-upload.net/download-129 ... s.exe.html

Also with low priority, I probably will test it on the Amiga, to see, if it works fine with Motorola CPU's.

well, releasing the source code would solve that, i guess