Current state of text based levelformats

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

Moderators: Zomis, Flumminator

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

Post by LogicDeLuxe » Thu Sep 18, 2008 11:54 am

A suggestion on the Add object, which currently is defined as

Code: Select all

Add=incx incy element1 element2 [backwards]

This was used only in BD2.
if backwards is specified, the algorithm works from bottom up.
Since backwards is not used by any engine, it is safe to make this change. I'd like to add a third element, a replace element. Though, since this should be optional, of course, it would make it difficult for parsers to still look for the backwards keyword, which also is optional. Therefore, I suggest another object Addbackwards, to address this issue.
The new specs would look like this:

Code: Select all

Add=incx incy search_element add_element [replace_element]
If replace_element is specified, only draw over that element.
incx and incy may be negative numbers.

Addbackwards=incx incy search_element add_element [replace_element]
This is like the regular Add, but works from bottom up.
If replace_element is specified, only draw over that element.
incx and incy may be negative numbers.

Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest » Fri Sep 19, 2008 7:29 pm

LogicDeLuxe wrote:What's the matter with that data base? I get only "The page cannot be found".
Whoops, sorry about that, moved everything to another server and forgot to update some stuff.

http://www.emeraldmines.net/BDCFF/ is back up.

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

Post by LogicDeLuxe » Fri Sep 26, 2008 6:52 am

Some parameters should be extended to optionally have one number for each level. For instance, you then can just write

Code: Select all

AmoebaTime=60 50 40 30 20
instead of

Code: Select all

[Level=1]
AmoebaTime=60
[/Level]
[Level=2]
AmoebaTime=50
[/Level]
[Level=3]
AmoebaTime=40
[/Level]
[Level=4]
AmoebaTime=30
[/Level]
[Level=5]
AmoebaTime=20
[/Level]
This should be optional, of course, for compatibility reasons.
This could be used for:
AmoebaThreshold
AmoebaTime
BonusTime
HatchingDelay
MagicWallTime
PenaltyTime

With SlimePermeabilityC64, this would not work with the current specs, since it can take an optional seed parameter. If this is really desired, we could change that seed parameter to SlimePermeabilityC64.seed instead.


And we have a new attribute: HatchingTime, which gives the time in seconds instead of frames.

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

Post by LogicDeLuxe » Sat Oct 11, 2008 6:39 pm

We need to specify the way the line algorithm should work exactly. (Same goes for maze generation and random placements, though I concentrate on lines in this post now)

This is no issue for any C64 caves, as they only can go into one of 8 directions. However, there are clones capable of using lines with any start and end coordinates, and problems occur on coordinates which has odd distances, ie. not possible to draw a thin line in a symmetrical pattern. To prevent this in BDCFF enabled engines, we should state an exact algorithm for line drawing.

Bresenham's line plotting algorithm is pretty much standard, but unfortunately, most implementations are optimized to a degree, and all do it somewhat differently, because of this.

Boulder Rush:

Code: Select all

Line	2,4 6,6 WALL
Line	6,9 2,7 WALL
Line	8,4 10,8 WALL
Line	14,8 12,4 WALL
Image

GDash:

Code: Select all

Line=2 4 6 6 WALL
Line=6 9 2 7 WALL
Line=8 4 10 8 WALL
Line=14 8 12 4 WALL
Image

And with the code from C64 Codebase, which I implemented in my XDC engine (which is very early work in progress).
Test cave from assembler source file:

Code: Select all

        .byte Line, WALL, 2, 4, 6, 6 
        .byte Line, WALL, 6, 9, 2, 7
        .byte Line, WALL, 8, 4, 10, 8
        .byte Line, WALL, 14, 8, 12, 4
Image

You see, all got the exact same coordinates, and every one behaves differently, which in the worst case could make a ported cave impossible to play.

I would say that Boulder Rush was first and we could base the BDCFF specs on that, but unfortunately, it has no source code availabe. Any suggestions?

cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

line

Post by cirix » Sun Oct 12, 2008 12:12 pm

I simply used the Bresenham line algorithm from wikipedia.
We cannot get the Boulder Rush code - also, no game loads its .cave files, so no incompatiblity problems should arise.

bye
cirix

cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

atari colors

Post by cirix » Fri Oct 24, 2008 8:10 am

as gdash now supports atari palettes, i'm considering writing the atari colors differently to bdcff files.
a color specification would look like:
- a c64 color (Black), or
- an atari color (Atari1E), or
- rgb value, 12FFEE or #12FFEE.

so those also would not have to be translated to rgb. what do you think?

LogicDeLuxe: have you decided what you do about the line algorithms problem?
cirix

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

Re: atari colors

Post by LogicDeLuxe » Sat Oct 25, 2008 9:15 am

cirix wrote:as gdash now supports atari palettes, i'm considering writing the atari colors differently to bdcff files.
a color specification would look like:
- a c64 color (Black), or
- an atari color (Atari1E), or
- rgb value, 12FFEE or #12FFEE.

so those also would not have to be translated to rgb. what do you think?
Fine with me. I can use it that way.
LogicDeLuxe: have you decided what you do about the line algorithms problem?
About the BDCFF part, I'm not sure. It is certainly easier to point at some general Wikipedia stuff then restricting it to 6502 code. On the other hand, 6502 code is basically what we have with the default predictable random number generator, although it was ported to C and Pascal.

What XDC concerns, drawing the way GDash does is no problem, as it is merely a matter of the direction which could be decided by the converter. But this still doesn't solve the BDCFF issue.
But since there are no caves using those uncommon gradients yet, it is of low priority, I think.

cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

Re: atari colors

Post by cirix » Sat Oct 25, 2008 9:39 am

LogicDeLuxe wrote:About the BDCFF part, I'm not sure. It is certainly easier to point at some general Wikipedia stuff then restricting it to 6502 code. On the other hand, 6502 code is basically what we have with the default predictable random number generator, although it was ported to C and Pascal.
I _have_not_ written anything about predictable random generators. please show me what i have written about predictable random generators! then i will understand why you are so narrow writing "It is certainly easier to point at some general Wikipedia stuff then restricting it to 6502 code."
i only asked about lines.
also, show me a bdcff file which used lines like that. of course boulder rush does not count, as it is not bdcff. i can easily port the c64 codebase line routine. but i will not give the name "line" for that object, as then i will create incompatibility with bdcff caves gdash already created; and currently i already have users which use those lines. if i changed that, the forum would be immediately flooded with "why are lines different? my caves don't work" posts.
cirix

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

Re: atari colors

Post by LogicDeLuxe » Sat Oct 25, 2008 11:52 am

cirix wrote:
LogicDeLuxe wrote:About the BDCFF part, I'm not sure. It is certainly easier to point at some general Wikipedia stuff then restricting it to 6502 code. On the other hand, 6502 code is basically what we have with the default predictable random number generator, although it was ported to C and Pascal.
I _have_not_ written anything about predictable random generators. please show me what i have written about predictable random generators!
As you are compatible to C64 and Atari which is 6502 code, you only choice is to use a C port in a C program, isn't it? I thought you were aware of that one: The predictable random number generator (for cave data) from Peter Broadribb who already did this.
then i will understand why you are so narrow writing "It is certainly easier to point at some general Wikipedia stuff then restricting it to 6502 code."
i only asked about lines.
Didn't you mention Wikipedia?
cirix wrote:I simply used the Bresenham line algorithm from wikipedia.
also, show me a bdcff file which used lines like that.
Why do you think, I wrote this:
LogicDeLuxe wrote:But since there are no caves using those uncommon gradients yet, it is of low priority, I think.
i can easily port the c64 codebase line routine. but i will not give the name "line" for that object, as then i will create incompatibility with bdcff caves gdash already created
I don't think that we need another drawing object here, as C64 lines are fully convertible to Bresenham coordinates, and since they are always symmetrical, the aforementioned issue doesn't even occur on those. So don't panic. Just keep in mind, that this detail is still missing from BDCFF which prevents new caves which do use unsymmetrical lines from being reliable reproducible by different engines.


About SlimeProperties, should MutantStones and Bladders costumizable with it as well? If so, we should add those elements to the defaults of this.

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

Post by LogicDeLuxe » Sat Oct 25, 2008 12:23 pm

My BDCFF document is updated: http://www.gratissaugen.de/erbsen/bdcff.html
It distinguishes between BDCFF native defaults and those of the various C64 engines where applicable now.
Also added:
- some more defaults
- DIRT2 are added.
- Multilevel option for several attributes.
- Atari colors.
- Link to predictable random number algorithm.
- Color for what's currently implemented in the XDC alpha.

Still somewhat imprecise:
- maze descriptions
- line description

cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

Re: atari colors

Post by cirix » Sat Oct 25, 2008 2:59 pm

LogicDeLuxe wrote:Didn't you mention Wikipedia?
Did I mention random numbers?

I'm not panicking, I'm just tired of this crap.
cirix

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

Re: atari colors

Post by LogicDeLuxe » Sat Oct 25, 2008 3:50 pm

cirix wrote:Did I mention random numbers?

I'm not panicking, I'm just tired of this crap.
Now you've lost me. I don't get what you are trying to say.

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

Post by LogicDeLuxe » Mon Nov 10, 2008 1:47 pm

Is anyone relying on a default Frametime=200 ms?
If not, we could change it to 180 160 140 120 120 as this is what most Atari and C64 engines used on PAL machines, given the machine could handle it (which might not be the case on some CPU demanding caves).

Also I added some things which is used by XDC:
- SLIME2 which behaves exactly like SLIME, except it uses the amoeba graphics.
- C64DTV## for color names, which are much like Atari##, but are used for native C64 DTV colors, which have slightly different hue.
- [LimitedColors] sections allowing hybrid cave files, ie. allowing extended features while still keeping the plain C64 in mind. This is already supported in XDC.
For example, Boulder Dash 2 cave B can have both Atari and C64 appearance like this (note those two [LimitedColors] sections):

Code: Select all

[cave]
Name=B. Silos
Colors=Atari00 Atari00 Atari36 Atari76 Atari7c Atarid4 Atarid4
[LimitedColors]
Colors=Green Purple White
[/LimitedColors]
DiamondsRequired=75 80 85 90 95
DiamondValue=3 10
CaveTime=200 190 180 170 160
RandSeed=100 137 140 251 51
RandomFill=BOULDER 254 AMOEBA 127
AmoebaTime=25
Amoeba2Time=25

[objects]
Line=1 15 30 15 STEELWALL
FillRect=1 16 38 20 SPACE
FillRect=1 0 7 15 STEELWALL
FillRect=11 0 17 15 STEELWALL
FillRect=21 0 27 15 STEELWALL
FillRect=31 0 38 15 STEELWALL
Raster=9 14 3 1 10 1 BOULDER
Raster=9 15 3 1 10 1 DIRT
Line=1 1 38 1 BOULDER
Line=1 2 38 2 DIRT
Line=1 3 38 3 DIRT
Rectangle=2 1 3 15 SPACE
Rectangle=36 1 37 15 SPACE
Point=3 16 INBOX
Point=38 16 OUTBOX
[LimitedColors]
Add=0 0 AMOEBA AMOEBA2
Add=0 0 DIRT DIRT2
[/LimitedColors]
[/objects]
[/cave]
Image
Image

cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

Post by cirix » Tue Nov 11, 2008 9:12 am

Why not simply:

Code: Select all

Colors=Atari00 Atari00 Atari36 Atari76 Atari7c Atarid4 Atarid4
LimitedColors=Green Purple White
Nevertheless, I'm not working on the bdcff anymore. The reasons are explained in the previous posts. The above thing is just there to prove the point. Have fun. And try to implement loading and saving that correctly at the same time, without hours of programming. :)
bye
cirix

User avatar
RAP
Posts: 286
Joined: Sat Jun 19, 2004 6:44 pm

Post by RAP » Fri Jan 08, 2010 2:19 am

I'm sorry, but after reading all of this very interesting discussion (I know the fact that this is a complicated topic regarding the discussion of your group efforts on level data), and I would actually like it to continue. We had two deadly hits on the forum, one that took quite a short while, and the other that took almost everyone out for over 4 months. DX

I mean really, I even saw you guys from http://www.boulder-dash.nl/. cirix, LogicDeLuxe, and maybe other guys.

And also possibly other people originating from Rocks'n'Diamonds -- at least respond once in a while, if you are busy of course.

@Steffest: You have your own freaking website! A twitter account, and a YouTube account! XP http://blog.stef.be/
It's too bad I can't translate your language from your videos (but not the text) -- I would really in interested in hearing how you talk to your people. I guess you have a lot of other very interesting things going on around your world. x3

Post Reply