Current state of text based levelformats

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

Moderators: Zomis, Flumminator

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

Post by HerzAusGold » Thu Jan 03, 2008 8:54 pm

Maybe with some small changes?
like "key_red" maybe is more relevant then "key_1" ?
(Allthough it also would make sense that a key_1 is needed to open door_1 and that the color doesn't really matter much.)
Yes, this renaming makes more readable. Ok.
Hmm, this process seems to scream for a wiki page, so that anyone could edit the BDCFF proposal ... anyone knows how Martijn is progressing to setup his boulderwiki?
I see you make the proposal editable.
This is very usefull!
The ID part of the list doesn't matter indeed ... that's just an internal number. (it's removed now)
You should add the internal id - for discussion.
eg. someone what to rename "ACID" after the rename noone find the entry anymore.
So we can say, eg. I want to rename 211 to "JUMPER"
Yes, next to the objectcodes there should be some additional sections,
like yamcontent, scores for all collectable objects, times for robotwheels, timegates etc ....
Also a highscore table for each cave (dependant on the engine)
Seems there is a lot of work...
there are over 10000 possible ASCII combinations with 2 chars ...
Ah, of course, only thought to 0xFF.
The Engine attribute is a very good idea, maybe also a section to put confirmed compatible engines.
(Like Engine is BD1 , confirmed compatible engines EM1, RnD, DX ...)

I'll change the names in the BDCFF list as much as possible to RnD names.
Maybe I'll put it behind a small CMS so anyone could edit the page.
In the new release of rndTest ("rndTest325-tc7" uploaded to zomis filearchiv)
there is a configurable BDCFF support included. (File "bdcff.conf")
So you can try your proposal with RND ! (and BD4 too).
Most levels of DX-BoulderDash01 are not playable, because the effects
are not emulated (yet) and Rnd have no real "BD engine" you know.

If you add the RND-ID in your proposal table directly, I can download
and convert it on runtime.
And it's make things so easy to edit! So please add the RNDID to your
table.
LogicDeLuxe wrote:
And explosions in Boulder Dash are a sequence of several elements. Thus EXPLOSION1 etc. is defined. I don't know how explosions work in EM. If it's a complete different thing, maybe they should be called EM_EXPLOSION as well.
Hm, explosion is a runtime element in RND.
Actually dont know what behaviour it have if you set as normal element.

Hi LogicDeluxe, can you send me your mail-address, because I have
some questions about the "effects" - and this is easier in german.

Cheers
HerzAusGold
And the answer is ... 42 !

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

Post by Steffest » Thu Jan 03, 2008 9:44 pm

Hey!
HerzAusGold wrote: You should add the internal id - for discussion.
Done!
HerzAusGold wrote: In the new release of rndTest ("rndTest325-tc7" uploaded to zomis filearchiv) there is a configurable BDCFF support included. (File "bdcff.conf")
Cool !!!!
Seems to be very flexible!
HerzAusGold wrote: Hm, explosion is a runtime element in RND.
If memory serves me well, there are some EM caves that use the explosion object in designtime.
E.g. it can be used to delay a falling boulder for 1 frame.
But that would be an execption offcourse ...
LogicDeLuxe wrote:
As for naming conflicts, there are some more elements in some Boulder Dash engines on the C64:
BOMB
ACID
I wasn't even aware that Bombs and Acid existed in some C64 Boulderdash engines!

But as I think abount that, in my opinion, maybe its a better approach to define the behaviour of "shared" items as a property instead of defining different objects. (just like the border property)
Like when the target engine is "BD1" boulders should be BD-boulders, diamonds should be BD-diamonds, Amoeba should be BD-style amoeba, explosions should be BD style explosions ....

switching the target engine to "EMC6" would result in boulders becoming EM style boulders etc ...

Offcourse this would be troublesome if several kinds of boulders are combined in 1 and the same level, but does this ever occur?
Internally an engine like RnD still would see them as different objects, but maybe in the levelfile they could be respresented by the same objectcode, with a property what kind of internal object is meant.
(e.g. in Supaplex, bombs can be stacked on top of each other and have a slower chainexplosion then in EM)
(I just thought of this, but I think this would simplify lots of things in fact ...)
HerzAusGold wrote: So please add the RNDID to your table.
the RND-ID is allready in the table as the image link (I noticed you've put all the images in the http://www.artsoft.org/I folder with the ID as filename: handy!)
But I'll include it as number too (In fact I'll add some viewing options so that other internal engine codes, like EMC can be included too)

Steffest
Last edited by Steffest on Fri Jan 04, 2008 12:24 am, edited 2 times in total.

User avatar
Holger
Site Admin
Posts: 3245
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Post by Holger » Fri Jan 04, 2008 12:05 am

> like "key_red" maybe is more relevant then "key_1" ?
> (Allthough it also would make sense that a key_1 is needed to open door_1
> and that the color doesn't really matter much.)

Small remark here: I changed naming from "key_red" to "key_1" etc. in the past because "red" is just a property of the currently used graphics set that may change (and does for different EMC level sets). So using numbers instead of properties like colours seemed to be more abstracted and flexible for element names to me. But probably this doesn't matter that much...

dave
Posts: 77
Joined: Mon Aug 13, 2007 2:06 am
Contact:

Post by dave » Fri Jan 04, 2008 3:29 am

Steffest wrote:If memory serves me well, there are some EM caves that use the explosion object in designtime.
E.g. it can be used to delay a falling boulder for 1 frame.
But that would be an execption offcourse ...
there are some emerald mine codes that delay, but it is unfortunate they made it into No One & Ruppelware's editor. the codes are used when the player collects an emerald or diamond or dynamite. in my engine i map them all to the 'emerald collect' code (which now has it's own code to make some caves work *sigh*)

explosion codes in caves is definately a bug & isnt in N&R's editor. iirc they end up as an infinite loop in the old kingsoft game. either way they
wont be supported.
Steffest wrote: But I'll include it as number too (In fact I'll add some viewing options so that other internal engine codes, like EMC can be included too)
internal codes dont belong in the file format.

in my engine, game/emerald.h there is a big enum with codes that start with C eg. Cblank Cstone etc. which will become the only supported objects loaded from a file (when i get around to developing a proper file format :). the codes further down the file are the internal ones, starting with X&Y&Z. these are not able to be specified in the files for good reasons ie. they change as i tweak the engine, and some rely on complicated interactions within the data structures inside the game.

the binary EMC cave format exposed some internal codes which i resisted adding to my engine for a long time. some are still not supported, but the C* codes in emerald.h captures most of them. there is some comments in my code which covers differences (but not all differences).

also the RND editor doesnt appear to have some of the EMC objects (off the top of my head the force rolling emeralds, diamonds, stones, nuts, bombs, springs which can go force their way over steel wall). the No One & Ruppelware's editor is probably a good reference for all the emerald mine objects (no doubt some people still used their hex editor on the caves, but the editor is very nice & covers every object imaginable).

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

Post by LogicDeLuxe » Fri Jan 04, 2008 9:08 am

Steffest wrote:I wasn't even aware that Bombs and Acid existed in some C64 Boulderdash engines!
Take a look at my demo game for newbies: http://www.gratissaugen.de/erbsen/tutor.zip
Most aspects of C64 BD should be covered there.
Btw. all elements in my BDCFF extension for Crazy Dream PC proposal exist in some C64 BD.
But as I think abount that, in my opinion, maybe its a better approach to define the behaviour of "shared" items as a property instead of defining different objects. (just like the border property)
Like when the target engine is "BD1" boulders should be BD-boulders, diamonds should be BD-diamonds, Amoeba should be BD-style amoeba, explosions should be BD style explosions ....
While the properties-attributes make sense in some cases like Diamonds and Boulders (ie. they can't really coexist due to different engines), it makes sense to have both versions for other elements like acid and bombs, since they behave quite differently (see demo game above).

Even RND's BD style elements aren't really true BD due to the lack of a BD engine. They are more like new RND elements behaving as close as possible to BD within the limits of the engine. Of course, those "imitation elements" can coexists with the EM elements in one cave very well and should be supported that way.
To sum it up, we have the EM elements EM_BOULDER and EM_DIAMOND which don't need a properties attribute. And we have the BD elements BOULDER and DIAMOND with behavior depending on the engine attribut, ie. behave exactly like in BD when a BD engine is specified, and behave the way they do in RND when the RND or a similar engine is specified.

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

Post by Steffest » Fri Jan 04, 2008 11:20 am

Take a look at my demo game for newbies: http://www.gratissaugen.de/erbsen/tutor.zip
:-) Mutant stones? Bladders? Sounds scary!
I have never heard of them until today. (I though they where new additions to your Crazy Dream 9)
Btw. all elements in my BDCFF extension for Crazy Dream PC proposal exist in some C64 BD.
Did you allready defined default Object Codes for them?
Of course, those "imitation elements" can coexists with the EM elements in one cave very well and should be supported that way.
Hmm ... yes, but the BD style "imitations" elements in any clone are usually added to make imported boulderdash levels playable in the engine, not to have e.g. BD_Boulders and EM_boulders in the same level. (Or C64 ACID and EM_ACID in the same level)
I just want to avoid a situation where there are 10 different kind of Boulders defined, and 10 different kinds of bombs.
After all, wasn't it a goal of BDCFF to be readable (and comprehensible) by human eyes?

Mabe it's an idea to have a "BASIC" list of objects (i.e. all the objects in the first original version of Boulderdash - Emerald Mines and maybe Supaplex)
and then an "EXTENDED" list (i.e. all the objects that came after that)
and then maybe a "SPECIAL" list. (i.e. special objects and conditions dor levels that require some engine specific trick to be playable)

if 95% of all levels out there can be placed in the Basic and Extended lists, then the BDCFF would be very usefull allready.
It would be the C in the name: focussing on the elements that are Common in these types of games, still leaving room for defining objects that are engine-specific.
internal codes dont belong in the file format.
True, but they are handy for refference.
I moved them to a seperate selection, stating clearly they are not part of the File format (same with the Id's)
explosion codes in caves is definately a bug
OK, I removed them

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

Post by LogicDeLuxe » Fri Jan 04, 2008 1:32 pm

Steffest wrote::-) Mutant stones? Bladders? Sounds scary!
I have never heard of them until today. (I though they where new additions to your Crazy Dream 9)
Actually, the only new addition to Crazy Dream 9 are those random generated mazes. Mutant Stones and Bladders date back to Prof. Knibbles 1stB engine.
Btw. all elements in my BDCFF extension for Crazy Dream PC proposal exist in some C64 BD.
Did you allready defined default Object Codes for them?
Do you mean Default Map Codes? No, I did not. It's only those listed in my proposal. Since a map editor easily may define them as needed, it didn't seem necessary.
Hmm ... yes, but the BD style "imitations" elements in any clone are usually added to make imported boulderdash levels playable in the engine, not to have e.g. BD_Boulders and EM_boulders in the same level. (Or C64 ACID and EM_ACID in the same level)
I know the purpose. Though that goal is never 100% as long as the engine works differently. I did not check every RND cave in existence, but I think, it's very likely that some use both in the same cave, as this is a valid RND feature.
I just want to avoid a situation where there are 10 different kind of Boulders defined, and 10 different kinds of bombs.
That's up to the cave author. It's certainly better than existing caves not convertible to BDCFF due to restrictions.
After all, wasn't it a goal of BDCFF to be readable (and comprehensible) by human eyes?
Somewhat related, maybe I should allow equations for some arguments where those "true" and "false" arguments don't tell anything.

For example:
DummyProperties collect_diamonds=false penalty=false destroyable=true
As far as I know, DummyProperties and IntermissionProperties aren't used by any tools yet. So that won't be a compatibility issue.
Mabe it's an idea to have a "BASIC" list of objects (i.e. all the objects in the first original version of Boulderdash - Emerald Mines and maybe Supaplex)
and then an "EXTENDED" list (i.e. all the objects that came after that)
and then maybe a "SPECIAL" list. (i.e. special objects and conditions dor levels that require some engine specific trick to be playable)
It's basically implemented that way already, as far as the Map Codes concerns:

Code: Select all

[mapcodes]
; extended codes for map-coded caves, may be absent.
Length=1        ; The length (1 or 2 characters) of the map-codes. Default value = 1
; For example,
.=DIRT
W=STEELWALL
; ...etc. If Length = 2 then ..=DIRT, Ws=STEELWALL, etc.
[/mapcodes] 
And for the element names. The engine only uses what it supports and ignores all the others. In case it encounters an unknown element name, it should print a warning message, of course.
explosion codes in caves is definately a bug
OK, I removed them
I don't know the RND internals, but if they in fact initiate an useless loop, it probably can be considered a bug. But in BD it is very legitimate to use them in BD1, BD2, 1stB and CrLi. In PLCK, it's not possible as only one nibble per element tightly limits the possible to place elements.

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

Post by Steffest » Fri Jan 04, 2008 3:59 pm

That's up to the cave author. It's certainly better than existing caves not convertible to BDCFF due to restrictions.
Good point!

The thing with the "BASIC" objects and the "EXTENDED" objects is mainly to have an indication how "common" an object is.

On the one hand the format should be able to hold all kinds of levels, resulting in a long list of object names, on the other hand, a developer creating an engine should not have to create 10 different kind of rocks just because a levelformat defines them all.

If there was basic set of objects to implement, he would know that if he would implement 20 Basic BD elements, that 90% of all BD levels would be playable,
and if he would add 25 more EM objects, then 90% of all EM levels would be playable. (Which would be allready more levels then anyone could probably play in a lifetime - definitly "good enough" for most developers)

Things like Explosions being uses in map-designs would be an anomality, therefore not really a priority to implement.

That's why I used the "SourceEngine" indication in the table, so a developer, and a cave creator, would know what elements are common in what engine.

That way you would have some kind of hierarchy of the objects so that an engine could target what level of compatibility it wants to reach.

Anyway ...
I updated http://www3.stef.be/projects/boulderflash/bdcff/ again with structures for the Yam content, notes, and several scores and times for the EM objects.

Cheers
Steffest

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

Post by HerzAusGold » Fri Jan 04, 2008 5:53 pm

Steffest wrote:
If memory serves me well, there are some EM caves that use the explosion object in designtime.
E.g. it can be used to delay a falling boulder for 1 frame.
But that would be an execption offcourse ...
For the delay the elements have a delayed property, like "BOULDERfd"
Which stands for Boulder Falling Delayed.
An explosion should not used for a frame delay.
Explosions are a special object, a yamyam can explode and create different things.
Don't know what is the best if they exists as object in other levels they should be in the BDCFF list.
On the other side they are more "effect" specific, so they should be a attribute, so even a butterfly can explode to stones.
To avoid confusion we should not include explosions at the moment.

Steffenst wrote:
But as I think abount that, in my opinion, maybe its a better approach to define the behaviour of "shared" items as a property instead of defining different objects. (just like the border property)
Like when the target engine is "BD1" boulders should be BD-boulders, diamonds should be BD-diamonds, Amoeba should be BD-style amoeba, explosions should be BD style explosions ....

switching the target engine to "EMC6" would result in boulders becoming EM style boulders etc ...

Offcourse this would be troublesome if several kinds of boulders are combined in 1 and the same level, but does this ever occur?
Internally an engine like RnD still would see them as different objects, but maybe in the levelfile they could be respresented by the same objectcode, with a property what kind of internal object is meant.
(e.g. in Supaplex, bombs can be stacked on top of each other and have a slower chainexplosion then in EM)
(I just thought of this, but I think this would simplify lots of things in fact ...)
Here I go with LogicDeLuxe. It should be allowed to use different types of bombs, emeralds in a level.
On the other side I go with Steffest. The default behaviour of the BD elements (and only this) should be depends on the engine. Cause of this I want the engine attribute.
Hm. Difficult. The best is to use it as is!! They should be different types of elements, like LogicDeLuxe say!
If a author want to force some element - a different section like the map code section should exists, so not only "Ws=Wall" should be possible, Even "DIAMOND=EM_DIAMOND" should be
possible. (like done in my bdcff.conf file).

Holger wrote:
Small remark here: I changed naming from "key_red" to "key_1" etc. in the past because "red" is just a property of the currently used graphics set that may change (and does for different EMC level sets).
So using numbers instead of properties like colours seemed to be more abstracted and flexible for element names to me. But probably this doesn't matter that much...
No problem that both can coexists. But "key_red" is more readable, even if a grafic set make it a invisible door.
Dave wrote something about EMC and it behaviour in his and original engine...
The process of the proposal was first intended to cover EM elements. Steffest add than some Supaplex elements and other.
Now we are at RND and any possible elements.
May be we are too fast and it should be more discussed what BDCFF should cover...
But I think if we included all the elements this is the end and we have very flexible way to define elements in BDCFF.
LogicDeLuxe wrote:
To sum it up, we have the EM elements EM_BOULDER and EM_DIAMOND which don't need a properties attribute.
And we have the BD elements BOULDER and DIAMOND with behavior depending on the engine attribut,
ie. behave exactly like in BD when a BD engine is specified,
and behave the way they do in RND when the RND or a similar engine is specified.
Hm, at the moment only RND can cover this?
The only way to solve it for all games (progs) is that unknown elements should be ignored or mapped to a existing element.
And if a prog exists which cover all elements, than it should take it as is. (RND is close to be it).
Hm, you mean if eninge=BD is defined - all "treasure" should mapped to BD_DIAMOND?
*edit: But what if engine=EMC?

Mutant stones? Bladders? Sounds scary!
I have never heard of them until today. (I though they where new additions to your Crazy Dream 9)
Never saw such elements.


Btw. all elements in my BDCFF extension for Crazy Dream PC proposal exist in some C64 BD.
In C64 BD ? - This is crazy.

Somewhat related, maybe I should allow equations for some arguments where those "true" and "false" arguments don't tell anything.

For example:
DummyProperties collect_diamonds=false penalty=false destroyable=true
Yes this is usefull!
explosion codes in caves is definately a bug

I don't know the RND internals, but if they in fact initiate an useless loop, it probably can be considered a bug.
But in BD it is very legitimate to use them in BD1, BD2, 1stB and CrLi.
In PLCK, it's not possible as only one nibble per element tightly limits the possible to place elements.
Hm. Dave mention only that this leads to a loop in KingSoftPlayer.
Don't know the behaviour in RND.

BDCFF should be a common file format. So if we are ready here there should be only one BDCFF file format exists.
If needed add the "EXPLOSION" again (or a related effect) - Exact way should be discussed later (when BDCFF gets finished).


Cheers
HerzAusGold
And the answer is ... 42 !

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

Post by LogicDeLuxe » Fri Jan 04, 2008 7:14 pm

Steffest wrote:On the one hand the format should be able to hold all kinds of levels, resulting in a long list of object names, on the other hand, a developer creating an engine should not have to create 10 different kind of rocks just because a levelformat defines them all.
An engine supporting all maps of any engine is virtually impossible, so any engine will support only a subset of the BDCFF definitions by nature. The main idea about BDCFF was interchangeability, so when porting a cave to another engine, it has to be reconstructed in places not compatible.
Another good reason for BDCFF are tools, so there can be universal cave editors, and other tools.
If there was basic set of objects to implement, he would know that if he would implement 20 Basic BD elements, that 90% of all BD levels would be playable,
and if he would add 25 more EM objects, then 90% of all EM levels would be playable.
Which is a decission of the engine and tool authors. Btw. in supporting BD1 and PLCK only, you already support about 90% of C64 BD, as the majority of games use those engines. PLCK only knows 16 elements in its native file format and BD1 rarely uses other elements than PLCK. Thus only those two engines and 16 elements enable playing a lot of C64 BD already. In fact "The new Dash Dimension" has only slightly more features that this, many of my proposal isn't implemented there. I am hoping to do most or all of it with "Crazy Light PC".
Things like Explosions being uses in map-designs would be an anomality, therefore not really a priority to implement.
It certainly is a curiosity and really not a priority for a map editor to have them. Though since caves with them do exist, a BD engine should support them at least.
That's why I used the "SourceEngine" indication in the table, so a developer, and a cave creator, would know what elements are common in what engine.
I plan to have an C64 export feature, so my cave editor will have a restriction feature which only permits elements and settings the selected engine supports.
Anyway ...
I updated http://www3.stef.be/projects/boulderflash/bdcff/ again with structures for the Yam content, notes, and several scores and times for the EM objects.
If you're really interested that much on internal codes, you can find the BD codes in my Dash-FAQ.

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

Post by LogicDeLuxe » Fri Jan 04, 2008 7:28 pm

HerzAusGold wrote:For the delay the elements have a delayed property, like "BOULDERfd"
Which stands for Boulder Falling Delayed.
An explosion should not used for a frame delay.
I disagree when it comes to a BD engine. The delayed objects really aren't ment to be placed in a map. In fact, this can have unpredictable results in some engine versions. The delayed elements are there for the Lord Diego effects, which should have delayed elements as the second parameter. Otherwise, elements might move at light speed, which is certainly not what the cave author expects.
Hm, you mean if eninge=BD is defined - all "treasure" should mapped to BD_DIAMOND?
*edit: But what if engine=EMC?
It's up to the engine, you normally don't even think about engine=bd1 or something like it, when you are about having tons of EM elements in it. I'm sure, you always will find a way to mess with an engine by building some obscure caves. The priority should be existing caves of all those different engines.

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

Post by Steffest » Fri Jan 04, 2008 9:33 pm

If you're really interested that much on internal codes, you can find the BD codes in my Dash-FAQ.
Hehe :-) you keep deeplinking to really interesting information that somehow I can't seem to find from the frontpage of your site.
Thanks!
I tend to add the internal codes as well because I use that same database to keep my import and export routines of my level editor in pace. (like this)
The delayed objects really aren't ment to be placed in a map
So maybe we should have a separate subset of element-names in BDCFF that aren't meant to be placed in a map, but serve another purpose.
The explosion thing could find a spot in this subset.
you normally don't even think about engine=bd1 or something like it, when you are about having tons of EM elements in it
True, but I think that is a property that could be set by the level-editor program. If you use only BD elements in a level, it would make sense that the leveleditor would put something like
gametype=BD
engine=BD1
or something, so that an engine knows if it will be (probably) able to play the level without having to scan the entire file.
This would also come in handy if you have a grahicset that only supports e.g. BD elements, so that the engine knows whitch levels could be played with that graphicset.
(offcourse, like every property, this would be optional)

LogicDeluxe: a question: What's the difference between "Charset" and "Fontset" in your proposal?
Would that be the same thing like a Graphicset?
Like in some Amiga EM games, you can choose between a ECS and a AGA graphicset? (or some caves with a christmas theme, that use a christmas spriteset)

Steffest

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

Post by LogicDeLuxe » Sat Jan 05, 2008 11:21 am

Steffest wrote:So maybe we should have a separate subset of element-names in BDCFF that aren't meant to be placed in a map, but serve another purpose.
The explosion thing could find a spot in this subset.
For the documentations, it perfectly makes sense to have two tables here. For the format itself and the engine, it is all the same, though, and should stay that way for compatibility. And of course, we shouldn't define any map codes for those special elements. Ie. there might be a common elements table with default mapcodes and a special elements table without mapcodes.
This would also come in handy if you have a grahicset that only supports e.g. BD elements, so that the engine knows whitch levels could be played with that graphicset.
(offcourse, like every property, this would be optional)
Though, as a graphics set is a cosmetic thing, and any engine should come with default graphics, using the defaults whenever there is no replacement in a custom graphics set makes sense.
LogicDeluxe: a question: What's the difference between "Charset" and "Fontset" in your proposal?
Would that be the same thing like a Graphicset?
This attribute dates back to Tim Stridmann's proposal. The Charset includes all the game graphics and the fontset is for the texts. On C64 and Atari, both work the same technically, thus those names.

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

Post by HerzAusGold » Sat Jan 05, 2008 6:57 pm

Hi,
because they exists in RnD, some properties are usefull:
GraphicSet=
MusicSet=
SoundSet=

eg. GraphicSet=BD2K3
if not given default is used.
And the answer is ... 42 !

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

Post by Steffest » Sat Jan 05, 2008 7:37 pm

OK,
Added those.
One might argue that a Graphicset is the same thing as a Charset, but Charset sounds so 8-bit :-)

BTW: The property table and elements table are editable, so if you feel like it you could add new elements or edit existing ones.

Probably I should add some "sections' to the property table, to order/group them.
They are ordered alphabetically now which is not the most logical way.

Steffest

Post Reply