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:

Re: acid

Post by LogicDeLuxe » Sun Feb 17, 2008 10:10 am

cirix wrote:i would rather specify an element to which acid converts, it is more generic.
i would even
acid.spreadratio=xxx
acid.convertsto=yyy
and the like. nopuff is the most inconsistent possible.

bye
Well, for the sake of consistency, we might consider don't touching the attributes at all and just define a new element: ACIDeffect
This particular behavior could be set with:
Effect=ACIDeffect ACID
Default behavior would be Effect=ACIDeffect EXPLOSION3

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

pushing boulder prob

Post by cirix » Sun Feb 17, 2008 10:36 am

the current spec states that pushing boulder probability should be 0.25 and 1.0. shouldn't this be 0.125 and 1.0?
cirix

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

slime permeability

Post by cirix » Sun Feb 17, 2008 12:04 pm

the two different values for slime permeability are also inconsistent.

the current bdcff has:
if you want unpredictable slime, you write SlimePermeability=0.05.
if you want predictable, you write SlimePermeability=3.

but you MUST write one of them, or it won't be trivial if predictable or unpredictable slime is to be used. common sense would dictate that any value can be missing from the file, if it is to be set to some default, but this is not true for this case, as any explicit value also sets type.

this one also applies to cavedelay and frametime. if we have some default, we should state how many the default is, and WHICH the default one is.
suggestions: SlimeProperties.predictable=<bool> (defaults to true), or stating that missing and SlimePermeability[C64] flag means a predictable slime with perm=0.

hereby i also suggest removing the engine flag, as any property of the engine can be specified explicitly, and this way it just makes confusion.
gametype of course makes sense!

the definition of enemydirection should state if time is frames or seconds.
type should use boolean values instead.
cirix

HerzAusGold
Posts: 325
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold » Sun Feb 17, 2008 4:53 pm

If an autor wants random placements there, he can still do this with the RandomFill cave object.
- The random placement of existing C64 caves is always compatible as the engine always proceeds all 40 colums.
- The defaults of 40 22 0 0 19 11 are compatible to PLCK caves. Though if the map is smaller than this size, all parts (presuming the usual conditions) beyond the map will/should be filled with Initialborder.
Question:
For the random fill object -
How big is the area by default?
Normal cave and intermission.

Because random fill should not write to any field outside the cave "borders". (Some Bdcff files are object based)
And the answer is ... 42 !

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

Re: slime permeability

Post by LogicDeLuxe » Sun Feb 17, 2008 7:47 pm

cirix wrote:if you want unpredictable slime, you write SlimePermeability=0.05.
if you want predictable, you write SlimePermeability=3.
No, you won't. You write SlimePermeabilityC64=3, whereas 3 is a byte variable which has the bit pattern the C64 engines use.
Both can coexist, as both should be processed by a BDCFF compliant engine. Using both at the same time is a bit silly, though.
but you MUST write one of them, or it won't be trivial if predictable or unpredictable slime is to be used. common sense would dictate that any value can be missing from the file, if it is to be set to some default, but this is not true for this case, as any explicit value also sets type.
Yes, it is, since both default to no delay at all (which is very predictable, of course), ie. SlimePermeability=1.0 and SlimePermeabilityC64=0
this one also applies to cavedelay and frametime. if we have some default, we should state how many the default is, and WHICH the default one is.
200 ms is default for Frametime. I know, having Frametime and cavedelay is somewhat redundant, but one is an exact timing, while the other merely represents a byte from the PLCK. Cavedelay has no default since Frametime already has a default value. Cavedelay is more complex to implement, as it depends on the time the code take for all the different elements. If both are given, the engine should use Cavedelay if it supports emulating C64 timing, and Frametime if it doesn't.
hereby i also suggest removing the engine flag, as any property of the engine can be specified explicitly, and this way it just makes confusion.
Not a good idea. As it is for readability, and also a simple way to set defaults to a certain engine. You are free to set all attributes explicitly anyways.
the definition of enemydirection should state if time is frames or seconds.
type should use boolean values instead.
It is in seconds, since 1stB synchronized all timers to the cave time.

So we might revise EnemyDirection to:
EnemyDirectionProperties.time time
EnemyDirectionProperties.startbackwards true|false
EnemyDirectionProperties.changeathatching true|false
time is given in seconds. If time=0, no auto direction changes occur. (default time=0)
startbackwards does just that. (default=false)
changeathatching is only affective if time>0. (true for 1stB, false for CrLi)
The timer does not start before the hatching.

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

Post by LogicDeLuxe » Sun Feb 17, 2008 8:14 pm

HerzAusGold wrote:Question:
For the random fill object -
How big is the area by default?
Normal cave and intermission.
It has no defaults, just like Line, FillRect etc. have no defaults. Random is always proceed over the entire width, including the invisible region. In contrary to the random attribute, also the top and the bottom border lines are proceed. Though, I think, we could extend the RandomFill object to something like this:
RandomFill=seed x1 y1 x2 y2 element probability [element2 probability2 [element3 probability3 [element4 probability4]]] [element5]

And for the few Intermissions with random elements outside the visible part, we might define a NULL element which is not drawn, so we could set InitialFill=NULL, and adding the border explicitly with Rectangle=0 0 39 21 STEELWALL

HerzAusGold
Posts: 325
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold » Sun Feb 17, 2008 9:41 pm

Hm, in a exiting converter the random fill directive fills only the intermission area (20*12) if there is an intermission.

In an other converter:
After reading the original CAV file a intermission check is done, which checks if the area "behind" the visible area is filled with steelwall - if there is - it is a intermission - and the maximum visible area is set to this "borders".

So should this not be done with this algorithm?

I think the reason for this "check" is that for this converter all files are .CAV and all files comes from C64 and the converter want to detect if there is an intermission.
Is there an other valid bit for intermission in C64 files?
The converter checks a bit in the file but the check is always done also.
And the answer is ... 42 !

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

Post by LogicDeLuxe » Sun Feb 17, 2008 11:11 pm

HerzAusGold wrote:Hm, in a exiting converter the random fill directive fills only the intermission area (20*12) if there is an intermission.
There is a difference, if it only uses the random generator for this area, or if it applies it for all 40 columns (hardcoded C64 size) and merely overdraws the invisible part with STEELWALL afterwards. Only the latter one would produce C64 compatible results. Sure, the drawing routine might do both in one pass, but it has to fetch all 40 numbers per row in any case in order to get the right numbers.
In an other converter:
After reading the original CAV file a intermission check is done, which checks if the area "behind" the visible area is filled with steelwall - if there is - it is a intermission - and the maximum visible area is set to this "borders".
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 map based there, thus this particular problem doesn't exist there. Checking for intermission is simply reading a byte in the parameters list.
I think the reason for this "check" is that for this converter all files are .CAV and all files comes from C64 and the converter want to detect if there is an intermission.
Again, .CAV files only exist for PLCK games. Beside this, we usually convert entire games, not single cave files. And no, there are also .INT files. Those are the same internally, and the only difference is, that the Intermission flag is set. Also keep in mind that the file extensions could be misnamed, since there are Caverippers which don't check for intermission but simply assume every 5th cave an intermission and naming them accordingly. That in mind, checking for Intermissions in .CAV, .INT files is in fact the best thing to do.
Is there an other valid bit for intermission in C64 files?
Yes, for PLCK and later. No for BD1 and BD2 as it is hardcoded in the cave order. See Dash-FAQ for details on this.

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

Post by cirix » Mon Feb 18, 2008 4:50 pm

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 map based there, thus this particular problem doesn't exist there. Checking for intermission is simply reading a byte in the parameters list.
Unfortunately, this will not help us in bdcff files, as caves are in play order in them. I already thought about something like and autodetection, which checks if there are elements outside the visible area in intermissions, and tries to do a guess.

Another idea: we might use the version tag in the bdcff file to handle this? I mean, the Tim Stridmann bdcff files have no version tag, and have 20x12 intermissions, with no explicit drawrect. We can say, that for bdcff >= version x.y, specifying size= is obligatory, or something like that.
cirix

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

Post by LogicDeLuxe » Mon Feb 18, 2008 7:03 pm

cirix wrote:Unfortunately, this will not help us in bdcff files, as caves are in play order in them. I already thought about something like and autodetection, which checks if there are elements outside the visible area in intermissions, and tries to do a guess.

Another idea: we might use the version tag in the bdcff file to handle this? I mean, the Tim Stridmann bdcff files have no version tag, and have 20x12 intermissions, with no explicit drawrect. We can say, that for bdcff >= version x.y, specifying size= is obligatory, or something like that.
Those are good ideas. I'd say, let's do the best of both.

For files with version <=0.32 or no version specified, let's check for placements outside 20x12. If there are none, draw the small border for the visible part. If there are, we can assume that the correct boundaries are present in the object list. Implementing this as a workaround for inconsistency in existing BDCFF files is probably the best we can do about it.
For versions >0.32, lets stay to the default size of 40 22 0 0 19 11 for intermissions, but don't imply the small border, as those should be part of the object list or map. It's the behavior of all C64 engines, thus having it as default behavior makes sense.
If you agree, I will change the definition for the Initialborder area, to simply draw on the real boundaries and only there.

What we certainly don't want is just assuming the size of 20 12 for Intermissions as this would mess with the random placements (like Gdash currently does).

Now, let's choose a new version number. Maybe, we should change the version string to something more simple in the data base's "structure"-tab like Version=0.5 instead of Version=cdpc1.0beta1
We should require the Version attribute to be a float number in order to do simple checks for it. If we have a maintained data base, we wouldn't need branched versions anyways.

HerzAusGold
Posts: 325
Joined: Sun Sep 25, 2005 4:41 pm
Location: Germany

Post by HerzAusGold » Wed Feb 20, 2008 9:32 pm

The proposal should have this higher version number, too. ;)
And the answer is ... 42 !

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

Post by LogicDeLuxe » Thu Feb 21, 2008 1:22 pm

We might rename EXPLOSION6 and DIAMONDBIRTH6 to EXPLOSIONeffect and DIAMONDBIRTHeffect to be consistent with the other effect Elements.
Still there is a slight difference: While EXPLOSION6 is a real element which can be set (you might think of it as SPACEd), DIAMONDBIRTH6 is only in the code and really is nothing more than DIAMONDd (unless it is changed with the Effect attribute).
What do you think? DIAMONDBIRTHeffect makes sense throughout, but do we want EXPLOSIONeffect or SPACEd? Or maybe both, ie. the default for EXPLOSIONeffect would be SPACEd then. SPACEd is there to prevent objects from moving into the explosion range within the same frame the explosion ends.

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

*effect

Post by cirix » Sat Mar 01, 2008 1:17 pm

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
cirix

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

Post by LogicDeLuxe » Thu Mar 13, 2008 1:28 pm

Added Elements: ACIDeffect, SPACEd
Added Attribute: Version
Updated Elements: EXPLOSION5, EXPLOSIONeffect, DIAMONDBIRTHeffect
Updated Attributes: EnemyDirectionProperties

For the "Structure"-tab:
Please update
[Level=n]...[/Level]
and in your header as well as in the example code
Version=0.5

We really still need an "Objects"-tab, containing the updated
RandomFill=seed x1 y1 x2 y2 element probability [element2 probability2 [element3 probability3 [element4 probability4]]] [element5]

Also you should remove those spam entries and add some protection against those.

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

Post by Steffest » Thu Mar 13, 2008 1:42 pm

Hmm,

Stupid that with any open system like this, sooner or later its poluted with spam ...
Spam is gone.
[Level=n]...[/Level] is updated

Whats that about "Version=0.5" is this the version of the proposal ?

The objects tab, yes .. that's something for next week.
(And also a littke spam protection, just minimal, I really want to keep this as open as possible)

cheers!
Steffest

Post Reply