XDC engine development thread (alpha version)
Moderator: Admin
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
The 2nd amoeba is there for a long time already (and used in several caves in Crazy Dream 10). The other suggestions most likely will never be supported in XDC for various reasons.CWS wrote:I wonder what's about the gravity switch, 2nd amoeba, the nut, the nitropack, the water, the lava, the replicator, the teleporter, the pneumatic hammer and the conveyor belt?
In the past, I coded the CrDr engine, which was a bit over the top and therefore some caves were rather slow. I want to avoid making that mistake again. I spent quite some thoughts of how I could optimize things. Plus the graphics are all in use already anyway.
I only thought if XDC is cross platform - and I think most users will use it on a modern platform - these elements would be no problem. Look at GDash - it is doing well!LogicDeLuxe wrote:The 2nd amoeba is there for a long time already (and used in several caves in Crazy Dream 10). The other suggestions most likely will never be supported in XDC for various reasons.CWS wrote:I wonder what's about the gravity switch, 2nd amoeba, the nut, the nitropack, the water, the lava, the replicator, the teleporter, the pneumatic hammer and the conveyor belt?
In the past, I coded the CrDr engine, which was a bit over the top and therefore some caves were rather slow. I want to avoid making that mistake again. I spent quite some thoughts of how I could optimize things. Plus the graphics are all in use already anyway.

- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
The construction kit will be cross platform. The engine is not meant to be cross platform. There might be an Atari version someday, but I did not decided on that either.CWS wrote:I only thought if XDC is cross platform - and I think most users will use it on a modern platform - these elements would be no problem.
That's exactly the reason why I think, there is no need for another cross platform engine for modern systems.Look at GDash - it is doing well!
In contrast to GDash, XDC is designed for creating games for the C64 from the beginning on, as there is still a big Boulder Dash fanbase on this platform.
While XDC currently has some features not supported in GDash, I think GDash will eventually. Should not be too hard to implement those, especially for the advanced drawing objects, since I will provide C implementations for the construction kit anyway.
Also the graphics could be enhanced there, like it is already done with the carried bomb and its burning fuse.
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
Here is a beta release of XDC: http://gratissaugen.de/files/xdc-2012-12-11.zip
This time, not for showing new features, but to thoroughly test the existing ones.
This release includes:
- some precompiled classic and some newer games for evaluating the stability of the engine. The final release will come without games separately.
- BDCFFcompiler.exe: Try at your own risk. Games may or may not work. Run without parameters to see a list of options. HEX edit the loader programm to enter your files for caves, title, intro, enemies and highscore.
- No One's enemy designer adopted for XDC charsets. (included on d64)
Known bugs in XDC:
- [LimitedColors]-attribut in BDCFF files does not work correctly.
- Telescope arm is broken. (Not used in the caves on this disk image)
Known bugs in BDCFFcompiler:
- Some combinations of attributes might result in unexpected behavior or broken caves.
Todo:
- bug fixes
- last few physics.
- a cross platform construction kit replacing BDCFFcompiler.
Feedback is welcome.
The next release may take some time since I am currently working on other things as well. Thus, take your time with this release.
This time, not for showing new features, but to thoroughly test the existing ones.
This release includes:
- some precompiled classic and some newer games for evaluating the stability of the engine. The final release will come without games separately.
- BDCFFcompiler.exe: Try at your own risk. Games may or may not work. Run without parameters to see a list of options. HEX edit the loader programm to enter your files for caves, title, intro, enemies and highscore.
- No One's enemy designer adopted for XDC charsets. (included on d64)
Known bugs in XDC:
- [LimitedColors]-attribut in BDCFF files does not work correctly.
- Telescope arm is broken. (Not used in the caves on this disk image)
Known bugs in BDCFFcompiler:
- Some combinations of attributes might result in unexpected behavior or broken caves.
Todo:
- bug fixes
- last few physics.
- a cross platform construction kit replacing BDCFFcompiler.
Feedback is welcome.
The next release may take some time since I am currently working on other things as well. Thus, take your time with this release.
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
It is XDC's own binary format. It is not fully documented yet (though still similar to the draft in the starting post) and may change during development.subotai wrote:What filetype is the output format of the compiler,
Copy the compiled caveset into a d64 image. Then make a copy of a loader file and hex edit your new caveset filename in (or just replace an existing caveset with yours). The byte in front of the string has to be the length of the string.and how can I play the caves in VICE?
If you need a tool for copying into d64, try 64copy.
Then, just load your d64 in VICE as usual.
This was not intended. It is caused by a different starting direction. You can easily reproduce this in GDash by changing the Firefly starting direction to downwards.In No One 1 Cave B, the behaviour of falling diamonds and fireflies is different to the Gdash version. Is this intended?
It was a helpful report anyway, since I can check out, why this difference was there in the first place.
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
I just checked No One 1:B. It is FIREFLYd in the BDCFF file I used. Either, it was a different version of the game (not uncommon by No One), or I accidentally changed it. I'm glad, it was not an XDC bug. 
As an exercise, I made a lot of object optimization in those caves to keep the files as small as possible. This is not only the use of rasters (which weren't available in BD1) instead of multiple lines, but also the deletion of objects which didn't appear at all to begin with, because another was drawn entirely over it, it replaced the same object, or a filled rectangle was used too narrow to actually make use of the inner element, etc.. Although many drawing objects differ, the result should be the same in all caves.
The only cave, which really is expected to behave slightly differently is Don Pedro 9:I, since the magic wall bug emulation is slightly off due to cave scan optimation.
Also colors are optimized in some caves, usually the brighter variant for color 3 if possible, and green amoeba when in DTV or Chameleon enhanced mode.
Another noticealbe difference is the seconds left, which is realtime now, and thus adjusted +20% for PAL caves.

As an exercise, I made a lot of object optimization in those caves to keep the files as small as possible. This is not only the use of rasters (which weren't available in BD1) instead of multiple lines, but also the deletion of objects which didn't appear at all to begin with, because another was drawn entirely over it, it replaced the same object, or a filled rectangle was used too narrow to actually make use of the inner element, etc.. Although many drawing objects differ, the result should be the same in all caves.
The only cave, which really is expected to behave slightly differently is Don Pedro 9:I, since the magic wall bug emulation is slightly off due to cave scan optimation.
Also colors are optimized in some caves, usually the brighter variant for color 3 if possible, and green amoeba when in DTV or Chameleon enhanced mode.
Another noticealbe difference is the seconds left, which is realtime now, and thus adjusted +20% for PAL caves.
Many of the BDCFF files that can be dowload on Arno's website have wrong starting directions for the elements. This surely is a bug in the converter or somebody changed it manually. Maybe, you took this BDCFF file (it is FIREFLYd in Cave B). If I remember right, Arno used Tim Stridmann's converter.LogicDeLuxe wrote:I just checked No One 1:B. It is FIREFLYd in the BDCFF file I used. Either, it was a different version of the game (not uncommon by No One), or I accidentally changed it.
The converter of cirix is the best you can get for the moment. The only problems that I know with this converter are the wrong value for slime permeability in PLCK caves and the wrong starting direction for butterflies in CLCK caves. Unfortunately, cirix never fixed these problems. So I created my own patch to fix the BDCFF files.
Does the engines support CLCK elements or effects? A Vexpanding wall for example in the cave map is an unknown element. When I try to compile my games, some elements are missing. I don't use many special elements or special features. Some other things are messed up.
Last edited by subotai on Sat Dec 15, 2012 12:18 pm, edited 1 time in total.
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
It does support several CrLi elements, but not all of them. VEXPANDINGSTEELWALL is supported, though via drawing objects only. MAPs are only supported for PLCK elements (those 16 available in the original PLCK). If you want to convert your maps and have only few non-PLCK elements, you can just add objects (ADD inclusive).subotai wrote:Does the engines support CLCK elements or effects? A Vexpanding wall for example in the cave map is an unknown element.
Unlike CrLi, all expanding wall types can be present simultaneously in XDC too, just like in GDash.
Several effects are supported by XDC, but many of them are currently broken in the converter and may crash XDC, so better avoid them at this time.
Thanks, it works
If you want to make this work in Gdash, you have to use the "object" section.
I always wanted to play Dustin's RockFort in a C64 emulator. Very nice that you added this game.
One more point. I don't know if this was already mentioned. My first intention when playing some caves was that the player gets very close to the border after the scrolling has started, especially when moving to the left or to the right. If I move slowly, the scrolling starts as intended. I think that this makes some caves much harder to play. What do you think?

Code: Select all
[map]
...
[/map]
Point=2 2 BUTTERFLYr
I always wanted to play Dustin's RockFort in a C64 emulator. Very nice that you added this game.

One more point. I don't know if this was already mentioned. My first intention when playing some caves was that the player gets very close to the border after the scrolling has started, especially when moving to the left or to the right. If I move slowly, the scrolling starts as intended. I think that this makes some caves much harder to play. What do you think?
- LogicDeLuxe
- Member
- Posts: 635
- Joined: Sun Jul 15, 2007 12:52 pm
- Contact:
Have you examples where this makes a difference? I would be interested in examples for various BD engines, as they behave slightly differently to begin with.subotai wrote:I don't know if this was already mentioned. My first intention when playing some caves was that the player gets very close to the border after the scrolling has started, especially when moving to the left or to the right. If I move slowly, the scrolling starts as intended. I think that this makes some caves much harder to play. What do you think?
I implemented a simple hysteresis for triggering and stopping scrolling. I didn't notice any difficulties.