XDC engine development thread (alpha version)

Everything about the various Boulder Dash tools, and other stuff created by the fans.

Moderator: Admin

User avatar
CWS
Member
Posts: 429
Joined: Wed Jul 11, 2007 2:32 pm
Location: Austria - Europe

Post by CWS »

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?
User avatar
LogicDeLuxe
Member
Posts: 637
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

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?
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.

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.
User avatar
CWS
Member
Posts: 429
Joined: Wed Jul 11, 2007 2:32 pm
Location: Austria - Europe

Post by CWS »

LogicDeLuxe wrote:
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?
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.

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! :)
User avatar
LogicDeLuxe
Member
Posts: 637
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

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.
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.
Look at GDash - it is doing well! :)
That's exactly the reason why I think, there is no need for another cross platform engine for modern systems.

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.
User avatar
LogicDeLuxe
Member
Posts: 637
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

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.
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

Wow, looks great :D Thanks for sharing! What filetype is the output format of the compiler, and how can I play the caves in VICE?

In No One 1 Cave B, the behaviour of falling diamonds and fireflies is different to the Gdash version. Is this intended?
User avatar
LogicDeLuxe
Member
Posts: 637
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

subotai wrote:What filetype is the output format of the compiler,
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.
and how can I play the caves in VICE?
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.
If you need a tool for copying into d64, try 64copy.
Then, just load your d64 in VICE as usual.
In No One 1 Cave B, the behaviour of falling diamonds and fireflies is different to the Gdash version. Is this intended?
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.
It was a helpful report anyway, since I can check out, why this difference was there in the first place.
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

Thanks, works fine with the loader. When I compile No One's Boulder 1 myself, it works as intended :D
User avatar
LogicDeLuxe
Member
Posts: 637
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

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.
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

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.
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.

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.
User avatar
LogicDeLuxe
Member
Posts: 637
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

subotai wrote:Does the engines support CLCK elements or effects? A Vexpanding wall for example in the cave map is an unknown element.
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).
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.
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

Thanks, it works :D

Code: Select all

[map]
...
[/map]
Point=2 2 BUTTERFLYr
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. :cheers:

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?
User avatar
LogicDeLuxe
Member
Posts: 637
Joined: Sun Jul 15, 2007 12:52 pm
Contact:

Post by LogicDeLuxe »

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?
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.
I implemented a simple hysteresis for triggering and stopping scrolling. I didn't notice any difficulties.
subotai
Member
Posts: 251
Joined: Sun Jan 25, 2009 4:19 pm

Post by subotai »

LogicDeLuxe wrote:Have you examples where this makes a difference?
I remarked this in Dustin's RockFort Cave A. I don't think that it makes a difference for most games/caves.
zsom
Member
Posts: 84
Joined: Sat Apr 10, 2010 5:46 am

Post by zsom »

Hello.
Is there is something in the subject xdc engine?

Regards
Post Reply