Current state of text based levelformats

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

Moderators: Flumminator, Zomis

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

Post by LogicDeLuxe »

Steffest wrote:Whats that about "Version=0.5" is this the version of the proposal ?
It's higher than Tim Stridman's 0.32 and as we need a version number as an info to destinguish for the Size attribute, we need a higher version number. Also we decided to use a floating point number for easy implementation. 0.5 is higher than 0.32 while 0.15 is not. And cdpc1.0beta1 is not a number. I just used it on my site before we decided to use a floating point number.
In case you wonder, Tim Stridman wanted to adopt my suggestion from my site to integrate in his version 0.4, which is also dated by now.
The explanation is in the InitialBorder's description.
Steffest wrote:
Steffest should add a "cave objects" tab to his data base, so we would have a complete base for BDCFF definitions.
Indeed! That's something for next week.
The objects tab, yes .. that's something for next week.
Sounds familiar. :)
Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest »

Hehe, you got me there.
The written word, I hate it :-) It so final!

My intentions are very well, but my time very limited (like everyone else, offcourse)
cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

spam

Post by cirix »

the whole element description table is spammed on the bdcff specification site...
cirix
Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest »

Arg - Stupid!
I cleaned it up and removed the write-privileges to the database.

Updates are no longer possible now - untill I've setup a small captcha system.
(Which will be at least 2 weeks as I'm on holiday)

Stupid Spammers!
User avatar
Holger
Site Admin
Posts: 4073
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger »

> the whole element description table is spammed on the bdcff specification site...

Spammers everywhere...! *argh*

> Updates are no longer possible now - untill I've setup a small captcha system.

If you like, you can use the KittenAuth code (PHP) also used for this forum (which can be downloaded also from my site) -- although it does not prevent manual spamming (as can be seen on this forum), it does a very good job against automated spam bots which can circumvent usual captcha systems by using OCR algorithms.

To stay on-topic, please follow-up about spam in this thread:
viewtopic.php?t=1613
Thanks!
Steffest
Posts: 57
Joined: Thu Dec 06, 2007 9:27 pm
Location: Belgium
Contact:

Post by Steffest »

Ah, thanks holger
I'll look into it
Interesting thread ! about the spamming.

Hmm - manual spamming? That's very hard too counter.

The BDCFF proposal can be locked down to the people with an interest in updating it (maybe with a password)
But protecting a general forum against human manual spammers ... though!

Very weird indeed - Who on earth would spend their time spamming a forum - just for a few clicks ?
If they would spend an equal amount of time building a decent website, that would be far more effective for their purposes ...
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

A video standard attribute might be a useful addition to the BDCFF. Something like this:
VideoStandard=PAL|NTSC

The thing is, that C64 BD (and possibly other clones on C64, Amiga, Atari and similar systems you usually connect to a TV set.) are made for NTSC systems and rely in counting raster interrupts which occur 60 times per second, ie. in every video field. A PAL system does only 50 raster interrupts per second, which results in slower timers. 50 Boulder Dash seconds are one minute in real time.
The decision for a default value is a bit tough, though. While BD was made for NTSC, and the time matches real time there, about 99% of all the fanmade Boulder Dash games are done on PAL machines.

Using NTSC as the default has the advantage of staying in real time, which is usually assumed in any clone, especially when it wasn't designed on a TV standard based computer.

Using PAL as the default on the other hand has the advantage of keeping the intended timing in fanmade games for all those existing BDCFF files.
What do you think?
HerzAusGold
Posts: 362
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold »

Is there no implicit value for this available?
e.g Framerate?

For documentation this should be set to the value the author intended.

A clone should have values to adjust timers by a multipikator.
A cycle exact clone is very difficult, and new levels should be designed without needed cycle exact timing for movement.
And the answer is ... 42 !
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

HerzAusGold wrote:Is there no implicit value for this available?
e.g Framerate?
No and Yes.

If Frametime is set, this implies a constant speed in real time. Such a cave is not designed on a C64 Boulder Dash engine. This attribute is meant for newly developed caves/engines.

If Cavedelay is set, it is what the C64 engine used, ie. no constant speed but depending on the elements in the cave, as elements need different amount of CPU time. In this case, there is no multiplier implied. So we need another attribute for this.

Frametime can be specified along with Cavedelay, so BDCFF capable engines which don't support Cavedelay can fall back to a reasonable value which should reflect the average speed.
For documentation this should be set to the value the author intended.
Which is 1.2 for any game designed on a PAL machine, if specified as a multiplier .
A clone should have values to adjust timers by a multipikator.
A cycle exact clone is very difficult, and new levels should be designed without needed cycle exact timing for movement.
Exactly.

This multiplier only makes sense for a game which was made on a TV system based machine. Any newly developed game should be realtime, to avoid confusion, I think.

So the new attribute might look like this then:
TimingFactor=multiplier
multiplier would be 1.2 for PAL games and 1.0 for NTSC games, except for CrLi which is always 1.2.

The question what to use as a default value still remains.
1.2 would reflect 99% of the fanmade games while 1.0 is real time.
Since restricting this to caves using Cavedelay is reasonable, using a default value of 1.2 wouldn't interfere with newly developed cave, which should stay in realtime. Ie. whenever the engine uses Frametime timing, there is no multiplier applied.

Of course, correcting the framerate for this difference alone would not solve the problem as this affects all timers, eg. Magicwall time, Amoeba slow growing, Hatching delay (4 seconds in C64 timing) and Enemy direction change.
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

Another drawing object is appreciated:
FloodFill=x y element
It applies a 4 direction floodfill algorithm. (no diagonal filling)
HerzAusGold
Posts: 362
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold »

Can you describe the algo a little bit more exactly.
And the answer is ... 42 !
User avatar
LogicDeLuxe
Posts: 83
Joined: Sun Jun 04, 2006 9:23 pm
Contact:

Post by LogicDeLuxe »

It is just like this 4 directions fill: http://en.wikipedia.org/wiki/Floodfill
In those terms:
node=x, y
target-color=the element which is found at x, y before the fill started.
replacement-color=element
cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

floodfills

Post by cirix »

hi

in gdash, i have implemented two different floodfills. i think both have meaning, and can have a use.

the two types are fill-to-border and replace fill.
a fill to border object will "overwrite" anything, and will search for an element at which it stops.
a replace fill works the way you described; searches for an element, to change it to another; and it stops at any other element (which is not the one to look for).

a fill-to-border example is:

i set up a cave with some random stones. then i drew a closed, irregular shape with brick wall, and filled the interior with space.

Code: Select all

WWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
Wr.....rr...................rW
W......r........r............W
Wr.......r........w..........W
W.r.......ww.....w w.........W
Wr.......w  w...w  w.........W
W......ww    w..w   w........W
W.....w      w.w     wr......W
W...rw        w      w..r....W
W..rw                 w.r....W
W....w      w        w..r.r..W
W.....ww   w.w       w.......W
W...r.r.w w...w     w........W
W........w....rw   w......r..W
W...r.r........w  w.....r..r.W
W........r......w w.....r....W
W...............rw.......r...W
W...r.....r..................W
W................r...........W
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWW

replace fill example:
randomly distributed stones, then a rectangle is drawn with brick wall. then the dirt is replaced with space inside; ie. a replace fill is started inside the box. the replace fill looks for dirt, so it does not replace stones, and also it stops at the brick wall:

Code: Select all

WWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
Wr.....rr.......r...........rW
W......r........r.r..........W
Wr.......r...................W
W.r..............r...........W
Wr.......wwwwwwwwwwwww.......W
Wr.......w r         w....r..W
W........w           wr..r...W
W...r....w r rr      w..r....W
W..r.....w           w.rr....W
W...r...rw       r   w..r.r..W
Wr..r....w      r    w.......W
W...r.r..w       r   w.......W
W........w    r  r   wr...r..W
Wr..r.r..wwwwwwwwwwwww..r..r.W
W........r.....r........r....W
W...............r........r...W
W...r.....r........r.........W
W................r..r........W
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
note that the rocks inside the box are of course still randomly set up!

for both, the wikipedia algorithm can be used. one thing to note is that replace fill should put a point of the element to be looked for at its origin before the filling, only then start the filling itself. imagine the cave above; the random element setup might accidentally place a rock at the origin of the fill, and otherwise in such a case the filling would fail.


in bdcff i use:
FloodFillBorder=origin_x origin_y border_element fill_element
and
FloodFillReplace=origin_x origin_y element_to_replace fill_element



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

Post by LogicDeLuxe »

Those sure are useful, but we should stay with common terms, I think.
Let's use them as called in the Wikipedia:
FloodFillReplace would be FloodFill
and FloodFillBorder would be BoundaryFill
I also would recommend a different order so we would have:
FloodFill=origin_x origin_y fill_element [element_to_replace]
BoundaryFill=origin_x origin_y fill_element boundary_element

element_to_replace would be optional in FloodFill. As you said, it has its meaning in combination with random elements. But if left out, the algorithm should take the element found at the origin coordinates for it (which is the way flood fills usually work in paint softwares as well)
Also it isn't very intuitive to force a user to chose an element_to_replace, I think. The possibility to do so should be there, though.
cirix
Posts: 31
Joined: Sat Feb 02, 2008 8:38 am

Post by cirix »

But if left out, the algorithm should take the element found at the origin coordinates for it (which is the way flood fills usually work in paint softwares as well)
yes, but this is meaningless for random elements, as different random seeds might place different elements there. the MAIN purpose of objects is to create parts of the cave which are similar on each levels... like the brick walls in good old bd1 cave a.

so making element_to_replace optional is pointless. anyway, some bdcff files would save a few characters with that... once ago we said that bdcff files are not about size but clarity. and here we are...
cirix
Post Reply