Search found 31 matches

by cirix
Tue Nov 11, 2008 9:12 am
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

Why not simply: 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 loadin...
by cirix
Sat Oct 25, 2008 2:59 pm
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

Re: atari colors

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

I'm not panicking, I'm just tired of this crap.
by cirix
Sat Oct 25, 2008 9:39 am
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

Re: atari colors

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_ wri...
by cirix
Fri Oct 24, 2008 8:10 am
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

atari colors

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...
by cirix
Sun Oct 12, 2008 12:12 pm
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

line

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
by cirix
Mon Sep 01, 2008 11:54 am
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

flag used by gdash

hi gdash is now capable of using milliseconds-based, bd1, plck and crdr7-like scheduling. (these are all different). for this, i use the CaveScheduling tag, which can have the following values: ms, bd1, plck and crdr7. ms is default if frametime tag is seen. plck is default if cavedelay tag is seen,...
by cirix
Tue Jun 17, 2008 6:01 am
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

Good point. Since PLCK is the most used engine, I would suggest to make that the default engine for BDCFF as of version 1.5 and make any other engine required to be set explicitly. For previous versions, you have to assume BD1 when objects are used and BD2 when the raster object or add object is us...
by cirix
Sun Jun 08, 2008 6:06 pm
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

gdash bdcff

hi and answers to gdash-20080605 bdcff-related issues in this topic. currently, i'm not really sticking to the bdcff specification which is discussed here. this format is not currently specified correctly. also many properties defined by the current spec is awkward and pointless. at this time, my bd...
by cirix
Wed Apr 30, 2008 9:08 am
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

engine tag

if you think about machine readability, the first thing to delete is the "engine" tag. it complicates reading, as it is the first to read (and then set internal variables), only then should other variables be read. otherwise other variables would be overwritten by reading "engine=bd1&...
by cirix
Sat Apr 26, 2008 10:21 am
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

bdcff

LogicDeLuxe: if you would ACTUALLY be writing a program to read and write this format, you would see these problems i'm talking about. but i think this is not the case, and it is very hard this way. some parts of the format impose unnecessary complications, while they seem to be nice. one simple exa...
by cirix
Fri Apr 25, 2008 3:50 pm
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

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 ...
by cirix
Thu Apr 24, 2008 8:40 pm
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

floodfills

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 ...
by cirix
Sun Mar 30, 2008 5:58 pm
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

spam

the whole element description table is spammed on the bdcff specification site...
by cirix
Sat Mar 01, 2008 1:17 pm
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

*effect

hi,

i think explosioneffect and diamondbirtheffect make sense. i already use them in the new version of my program. explosion6 and diamondbirth6 does not really have a meaning on their own.

bye
by cirix
Mon Feb 18, 2008 4:50 pm
Forum: Programmer's Corner
Topic: Current state of text based levelformats
Replies: 200
Views: 371774

Though this is not related to random placements. We have to distinguish between BD1/BD2 and PLCK (and later) here. In BD1/BD2, intermissions are hardcoded in the cave order, thus there really is no special check to be done. In PLCK or later, we don't have random placements, because the caves are ma...