Search found 31 matches
- Tue Nov 11, 2008 9:12 am
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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...
- Sat Oct 25, 2008 2:59 pm
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
Re: atari colors
Did I mention random numbers?LogicDeLuxe wrote:Didn't you mention Wikipedia?
I'm not panicking, I'm just tired of this crap.
- Sat Oct 25, 2008 9:39 am
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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...
- Fri Oct 24, 2008 8:10 am
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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...
- Sun Oct 12, 2008 12:12 pm
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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
We cannot get the Boulder Rush code - also, no game loads its .cave files, so no incompatiblity problems should arise.
bye
- Mon Sep 01, 2008 11:54 am
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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,...
- Tue Jun 17, 2008 6:01 am
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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...
- Sun Jun 08, 2008 6:06 pm
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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...
- Wed Apr 30, 2008 9:08 am
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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&...
- Sat Apr 26, 2008 10:21 am
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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...
- Fri Apr 25, 2008 3:50 pm
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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 ...
- Thu Apr 24, 2008 8:40 pm
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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 ...
- Sun Mar 30, 2008 5:58 pm
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
spam
the whole element description table is spammed on the bdcff specification site...
- Sat Mar 01, 2008 1:17 pm
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
*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
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
- Mon Feb 18, 2008 4:50 pm
- Forum: Programmer's Corner
- Topic: Current state of text based levelformats
- Replies: 200
- Views: 402742
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...