XDC engine development thread (alpha version)
Moderator: Admin
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
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.
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...

---- Boulder Dash Fansite ----
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
There are three settings XDC can handle.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...
Regular size of 40x22:
Code: Select all
Size=40 22 0 0 39 21
Code: Select all
Size=40 22 0 0 19 11
Code: Select all
Size=20 12 0 0 19 11
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
).

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

---- Boulder Dash Fansite ----
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
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.Arno wrote:- It behaves like a normal cave (no instant life, no warp after faillure), but it clearly has Intermission=true in the bdcff.
Currently, the engine automatically makes any cave selectable once played. It doesn't for intermissions, though.- The bdcff has Selectable=false, but once the cave is played, it becomes selectable (even in the higher levels).
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.
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
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.
- 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.
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
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.
- 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.
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
New BDCFFcompiler version: http://www.file-upload.net/download-128 ... 0.exe.html
- Amoeba, Amoeba2 and Magicwall properties.
- Bugfix: initial number of lives.
- Amoeba, Amoeba2 and Magicwall properties.
- Bugfix: initial number of lives.
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
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.
- Waits for scrolling when active guy wraps around.
- Waits for scrolling at hatching.
- Support for amoeba and amoeba2 maximum size and spread probabilities.
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
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.
- Bugfix: Randomly wrong Atari colors.
- Bugfix: Default amoeba size.
- Bugfix: Amoeba and magicwall timers now work without specifying a TV-system.
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
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.
- 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.
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
Indeed. The final version will. It's not high priority right now, though.CWS wrote:A Unix version would be very much appreciated. Without Windows it's not possible to use the compiler.
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.