Current state of text based levelformats

Discussion around programming R'n'D, its source code and its tools.

Moderators: Flumminator, Zomis

Post Reply
dave
Posts: 77
Joined: Mon Aug 13, 2007 2:06 am
Contact:

Post by dave »

HerzAusGold wrote:
Dave wrote:
these are not animations. they are equivalent to decor or the 4 different steel/wall/etc images. these occur in caves from the beginning.
Hm, can you give an example?
sure, play the original kingsoft emerald mine 1 level 4. run up and you see a long line of ameuba across the top which are not all the same.
HerzAusGold wrote:
Dave wrote:
the copyright letter also. some minor variations that make a big headache for an exact archiving of caves.
The copyright letter is always CHAR_COPYRIGHT.
It's up to the graphic set to cover different variations.
you've got it backwards. the point is what to do with the code #241 when converting older emerald mine caves to the BDCFF format. for some caves, it should be replaced with a BDCFF object 'copyright'. for other caves it should be replaced with a BDCFF object 'decor'.

if the BDCFF is to be used for archiving caves (which seems like a noble thing to do), it will have to be able to reproduce exactly what the original cave designer meant, unambiguously.

another problem is the number of seconds for playing a level in old caves. the EMC saw this too & solved it by creating a new variable in the new level format. the different times has to do with copy protection (which i found when i tried to use the original non-cracked emerald mine executable). the r'n'd loader tries to fix it with some ad-hoc tests, but i bet it needs human intervention in some cases.
HerzAusGold wrote:To sum it up, if the behaviour is the same for playing we should have only
one "element code"!
Or (if really needed) a element code "ACID_RANDOM_WOBBLY" for a nice pattern.

Please don't blow up the BDCFF file format with "animations" or different "graphic".
depends on what you want to use it for i guess. i always thought of it as an archival thing. a way to store the old caves _exactly_ as they were originally made. a player that loaded a BDCFF cave would be free to treat a bunch of different objects the same if it wanted too. creating a table that maps all eg. ameuba objects to a single ameuba would be trivial in the player but disasterous for the actual level files because you would lose information perhaps forever.

note that my player & converter program in no way tries to address these problems. i keep a copy of both the Emerald_Mine_Club-2.0.0.7z archive, and the converted caves because it's not a 100% compatible conversion. i chose to use things that made the most caves playable and there were tradeoffs. the reason for the conversion instead of just leaving the files alone is that 50000 separate files is a pain to maintain and offers very little in the way of compressing them, which i consider important. it is the difference between 5 minutes and 100meg to copy (uncompressed, small separate files), and 20 seconds and 15meg (zipped, larger converted files).
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

Steffest wrote:Hmmm ... I'm afraid I disagree a bit.
If you let me quote one of the "Founding Fathers" (LOL :lol: ) of BDCFF, Peter Broadribb:
Peter Broadribb wrote:It needs to be able to potentially support all the existing caves in all the existing various implementations of BoulderDash
And my "supporting" I think is meant that a cave comes out just the same as it goes in (in an engine that supports all features of the cave)
That's where the Charset attribute etc. come in handy. I don't think BDCFF is meant to hold the graphics. Though, if there is a need, we should define a method to do just that with no relation to the game physics. It's the way those games were designed in the first place, ie. having a game engine along with game data and one or more graphics sets accompanying them.
dave wrote:another problem is the number of seconds for playing a level
This is in fact the major problem for C64 caves as well. The timing depends much on the C64 internals and the only way to do a 100% accurate timing in a BD clone would be to emulate a C64. My XXX2DAS tool calculated an approximation by taking the delay (hardcoded in BD1/BD2 and customizable in PLCK) and adding further time for all the elements using their average CPU time. This worked well most of the time. Of those 400 converted caves I bundled with the game, there is only one cave where I increased the time.

For staying true to the original PLCK cave data, we have the CaveDelay attribute, which is just a number, and the engine has to calculate some actual delay in a way similar to what my converter does. A more advanced engine could do this during playing the cave, of course.
For more reasonable cave designing, there is the FrameTime attribute, which is just the time each scan interval has.
As I think of it, we actually could allow both specified, and in case both are there, any engine with realtime delay calculation (assuming there will be one some day) can use CaveDelay and any other engine should rely on the precalculated FrameTime.
HerzAusGold
Posts: 362
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold »

Steffest wrote:
I've been playing around with the last Amiga Emerald Mine editor and I think I'm going to stick with all the EM elements that you can use in that editor.
Yep. All available and selectable EM element in editor should be in BDCFF table.

For graphic variations or other quirks,
I agree with LogicDeLuxe to use the "engine" or "charset" (graphicset) or maybe the "gametype" attribute.
Dave wrote:
you've got it backwards. the point is what to do with the code #241 when converting older emerald mine caves to the BDCFF format. for some caves, it should be replaced with a BDCFF object 'copyright'. for other caves it should be replaced with a BDCFF object 'decor'.
The conversion to BDCFF should set the rigtht BDCFF element.
...about the cave time and delay...
It seems very difficult to get a fitting time for RnD.
How is it calculated for a C64 BD level ?
Hm, in RnD there is a calculation for EM levels in?
Sorry about my bad english, seems I need a description in german.
And the answer is ... 42 !
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

HerzAusGold wrote:How is it calculated for a C64 BD level ?
From my XXX2DAS tool:

Code: Select all

  {table for guess a delay value for c64 map}
  {not very exact, since there is a different level delay!}
  transverz: array[0..15] of byte =(
  17, 17, 0, 0, 0, 0, 0, 0, 32, 32, 27, 17, 0, 0, 0, 0);
In PLCK nybble code order:
0 Boulder
1 Diamond
2 Magic Wall
3 Brick Wall
4 Titanium Wall
5 Growing Wall
6 Mrs. Rockford
7 Dirt
8 Firefly
9 Butterfly
A Amoeba
B Slime
C Hidden Exit
D Visible Exit
E Inbox
F Space

Code: Select all

    for y:=0 to 20 do begin
      for x:=0 to 19 do begin
        read(inp,a);
        b:=a div 16;
        c:=a and 15;
...
        dl:=dl+transverz[b]+transverz[c];
...
        end;
      end;
    end;

...

    read(inp,a);
    writeln(out,'delay');
    writeln(out,(0.05+0.012*a+0*dl/10000));
"read(inp,a);" reads that PLCK delay parameter which is between 0 and 19.

The entire calculation is tweaked for PAL caves which are almost all fan caves. Though recently, some NTSC authors appeared.

Edit: I just noticed 0*dl/10000 doesn't makes sense. I have no clue how it got there, but I'm certain that it wasn't always there. So it still needs tweaking. The factor should be something less then 1, I think. I don't remember unfortunately.
HerzAusGold
Posts: 362
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold »

Oh, it depends on how many elements are inthe level.
Reason is that each element needs time in "code" to move, isn't it?

What have the "delay" to do with the leveltime?
And the answer is ... 42 !
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

HerzAusGold wrote:Oh, it depends on how many elements are inthe level.
Reason is that each element needs time in "code" to move, isn't it?
Sort of, especially on a 1 Mhz machine, it matters. On the C64, about 50% goes for emulating a virtual screen, and another 30% for animating the graphics (technically a charset). The tiny rest goes for the actual game physics. For example how much impact some code heavy elements can have, take a look at Dr. Watson's Boulder Dash 4 Cave I (almost filled with Boulders and Diamonds) and Cave O (halfway filled with Fireflies and also a lot of Diamonds). Both are significantly slower then the other caves while having all the same delay.
Not only do they take time for moving, but also for checking if they should move or react with other elements (mostly the case in those examples above), or for moving other elements (slime). Also the explosion sequences take more time for drawing the graphics than for applying the effect table. Other elements like Space, Dirt, Wall, Magicwall and Titanium Wall don't have code at all and therefore make the fastest caves if they fill most of it.
What have the "delay" to do with the leveltime?
Nothing directly. Though both have to be adjusted to fit each other and can be quite troublesome if they don't. Also a problem between PAL and NTSC interchange is that the timer simply counts raster interrupts resulting in a PAL minute has only 50 BD-seconds, thus more time to finish a cave. Also on PAL machines, the Inbox is flashing longer accordingly resulting in an unplayable cave in the worst case (3rd intermission from BD 1).

And we have the Hatchingdelay in BDCFF which is a good thing to keep things in sync when adjusting the delay, or even playing the cave on different clones. However, this value doesn't exist on any C64 engine and has to be calculated by the converter too, unfortunately. Most caves are rather forgiving on this, though.
Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest »

Hey,

OK, I updated the BDCFF proposal again.
It now holds *ALL* elements ever to be found in a Boulderdash or Emerald Mines level.
(I included all elements of the Crazy Dream list, all elements that can be used in the latest verison of the EMC editor, and some remaining ones that are suported in Dave's engine.)

390 elements in total ... quite alot!
So I divided them in "subsets": linking them to the gametype where they where first used, and also linking them to a game engine where they can be used.

So anyone interested in doing a Emerald mines clone could look up what elements are supported so he knows what elements his engine should support if it wants to load BDCFF files.
(Or so that a cavedesigner / leveleditor knows what elements can be used if the level should be playable in a EMCV5 engine etc ...)

Added a [magicball] section the the structure to hold the magicball content.

And added the proper credits :-)

http://www.stef.be/projects/boulderflash/bdcff/

Some thing I still want to do is linking each property (or parameter) to a subset, so that e.g. is clear that "EnemyDirection" property is only meaningfull in Boulderdash engine, not in a EM engine.

I think I will wrap it up after the EM and BD elements are all 100% defined. Adding the remaining Supaplex, RnD and Diamond Caves elements will have to wait a bit :-) (unless someones wants to add them offcourse)



Dave: 1 question: the "grow_ns" and the "grow_ew" that you use in your internal structure. What are they ?

Cheers!
Steffest
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

For your "supporting engine" column, do you mean, the native cave file format supports this? If yes, there are only 16 elements in PLCK as those nibble codes are rather limited. Of course, the engine knows all those elements I have in my FAQ table internally, though only those which have nibble codes can actually be set in a cave during construction. In BDCFF names, they are:
0 BOULDER
1 DIAMOND
2 MAGICWALL
3 WALL
4 STEELWALL
5 HEXPANDINGWALL
6 DUMMY
7 DIRT
8 FIREFLYl
9 BUTTERFLYd
A AMOEBA
B SLIME
C OUTBOX
D HIDDENOUTBOX
E INBOX
F SPACE

Restricting it to those makes sense. For instance, if someone uses your list to base an editor with native PLCK export on it. (My upcoming engine will probably have such a feature.)
I didn't edit this, as I want to know your opinion on this first.

Also I noticed, that there are some elements listed with CrLi which are only there in "The new Dash Dimension" (I usually call it DAS for short), but not on CrLi or any other C64 engine. Those I implemented for avoiding Lord Diego effects effecting the entire cave. Examples are expanding steelwall, vertical expanding walls and eatable steelwall. I plan to support them in my upcomming engine as well. And then, there are a few elements actually not implemented yet at all, but also listed with CrLi. Examples are BOULDERfallingeffect and DIAMONDbouncingeffect. They sure are usefull and I think I saw them in some clone (I don't remember right now), but they don't exist on any C64 engine nor in DAS. They will in my upcoming engine, though. So, if you could add DAS to the engine support list.
Is it okay to leave those elements with none of the listed engines supporting them with no engine selected for now then?
Steffest wrote:Some thing I still want to do is linking each property (or parameter) to a subset, so that e.g. is clear that "EnemyDirection" property is only meaningfull in Boulderdash engine, not in a EM engine.
And while at it, some similar table telling what engine supporting this makes sense as well. For instance, enemy direction is only available in 1stB and CrLi.

And STEELWALLDESTRUCTABLE, does it qualify as Bdex? It is available in BD1 and BD2, and was later replaced with the HIDDENOUTBOX in PLCK. It's not available in 1stB and CrLi either.

And if there are no objections, I want to remove those default map codes for OUTBOXopen and HIDDENOUTBOXopen, as they really aren't meant for map design.
Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest »

Hey LogicDeLuxe!

Great info, as usual.
Yes, I was thinking that those engine-elements were probably a bit off.
I corrected them towards your input.

The DAS engine has been added.
I more or less assumed that all elements on your list where allready in your Crazy Light engine, I didn't really check in detail.

STEELWALLDESTRUCTABLE has been moved to the BD-subset

I removed the default chars for HIDDENOUTBOXopen and the 1 char code for OUTBOXopen.
I left the 2 char code for OUTBOXopen though, because that element is often used in (the design of) Emerald Mine levels, and it is also supported in most EM level editors.

Steffest
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

Sorry. Some little mistake. There actually is support for BOULDERfallingeffect and DIAMONDbouncingeffect in DAS, but no cave ever used them, iIrc.

Besides those 16 PLCK elements, there are a few extensions. This shouldn't be confusing as those elements are either in the Bdex or Bdin category. I flagged those for PLCK support and added a comment.

I also added some missing elements.
Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest »

Wheeeeee!!!

Thanks!

Actually, those different Boulderdash engines seem very complicated to me, hehe ... Emerald Mines is so straighforward :-)

Steffest
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

Is GraphicSet really necessary? It seems to do the same as CharSet, ie. specifying a set of element graphics.
Maybe, we could remove the default="normal" and just let the engine use its default set, whatever it is called. Same with Fontset.

I moved most default values from the description to the defaults column. While at it, I noticed some duplicates. Please remove those duplicates:
BorderProperties
DiamondValue


For TimeValue, I set the default for BD the way C64 BD works. Is it also true for other engines? If not, we would set the defaults engine depended.

For DummyProperties, I suggest diamondcollector, penalty, destructible as more readable alternatives for true and no_diamondcollector, no_penalty, indestructible as readable alternatives for false.

For IntermissionProperties, I suggest scroll, instantlife, rewardlife as more readable alternatives for true and no_scroll, no_instantlife, no_rewardlife as readable alternatives for false.
HerzAusGold
Posts: 362
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold »

Hi,
I can check the list at the weekend,
want to update some RND elements.
LogicDeLuxe wrote:
For DummyProperties, I suggest diamondcollector, penalty, destructible as more readable alternatives for true and no_diamondcollector, no_penalty, indestructible as readable alternatives for false.

For IntermissionProperties, I suggest scroll, instantlife, rewardlife as more readable alternatives for true and no_scroll, no_instantlife, no_rewardlife as readable alternatives for false.
dummyProperties= diamondcollector=false penalty=true destructible=false

imo this is more readable for a parser. isn't it ??

*edit: or..
dummyProperties.diamondcollector=false
dummyProperties.penalty=true
dummyProperties.destructable=false

... so it's more extendable..
Last edited by HerzAusGold on Sat Jan 19, 2008 11:43 pm, edited 1 time in total.
And the answer is ... 42 !
HerzAusGold
Posts: 362
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold »

update and insert some RND elements in proposal.
Add only to "RND engine".
From Id 402 to ...
Last element I add is RND_EXPANDINGWALL
This is selectable in editor (but maybe with same behaviour as EXPANDINGWALL) dont check it.
But to be with BDCFF it's allowed to add it, isn't it?

*edit:
For insert you have to call the update page twice, to set
the 2-byte-code and Rnd-Id .
@Steffest: How can I make a "more proper mass" insert?
And the answer is ... 42 !
HerzAusGold
Posts: 362
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold »

Insert some RnD elements to proposal

..to insert a element, how can I fill up the form automatically
I tried it but it dont work, maybe use the wrong post codes.
Can you give a example for filling up the form with post codes or
"GET" fields.
And the answer is ... 42 !
Post Reply