Page 11 of 14

Posted: Thu Mar 13, 2008 5:46 pm
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. :)

Posted: Thu Mar 13, 2008 9:23 pm
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)

spam

Posted: Sun Mar 30, 2008 5:58 pm
by cirix
the whole element description table is spammed on the bdcff specification site...

Posted: Sun Mar 30, 2008 7:14 pm
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!

Posted: Sun Mar 30, 2008 7:33 pm
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!

Posted: Sun Mar 30, 2008 9:33 pm
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 ...

Posted: Mon Mar 31, 2008 12:24 pm
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?

Posted: Thu Apr 03, 2008 7:02 pm
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.

Posted: Fri Apr 04, 2008 9:33 pm
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.

Posted: Sun Apr 06, 2008 9:15 am
by LogicDeLuxe
Another drawing object is appreciated:
FloodFill=x y element
It applies a 4 direction floodfill algorithm. (no diagonal filling)

Posted: Sat Apr 12, 2008 8:13 am
by HerzAusGold
Can you describe the algo a little bit more exactly.

Posted: Sat Apr 12, 2008 3:38 pm
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

floodfills

Posted: Thu Apr 24, 2008 8:40 pm
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

Posted: Thu Apr 24, 2008 11:03 pm
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.

Posted: Fri Apr 25, 2008 3:50 pm
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...