структура boulder dash
структура boulder dash
доброго времени суток, господа. кто знает програмную структуру boulder dash на C64 ? помогите разобраться !
-
stridmann
- Сообщения: 28
- Зарегистрирован: Чт ноя 23, 2006 12:19 pm
- Откуда: Бердянск, Украина
- Контактная информация:
Re: структура boulder dash
А что именно Вас интересует?
Re: структура boulder dash
Да вообще подробное строение программы на консоли C64 . Знаете такую ?? Комодор ежели траслитом :)
И вот ещё что : могу ли я сделать свой БД без конструктора и разичных пакеров, просто на основе какого-либо готового БД перепаковав его, чтобы было натурально F2-старт и т.д. :D
Используется ли сжатие в БД ? Имею в виду как в пакерах и разных утилитах для создания своих БД, после паковки основного блока данных есть спец компрессоры для уменьшения веса файла и создания его автозапуска...
И вот ещё что : могу ли я сделать свой БД без конструктора и разичных пакеров, просто на основе какого-либо готового БД перепаковав его, чтобы было натурально F2-старт и т.д. :D
Используется ли сжатие в БД ? Имею в виду как в пакерах и разных утилитах для создания своих БД, после паковки основного блока данных есть спец компрессоры для уменьшения веса файла и создания его автозапуска...
-
stridmann
- Сообщения: 28
- Зарегистрирован: Чт ноя 23, 2006 12:19 pm
- Откуда: Бердянск, Украина
- Контактная информация:
Re: структура boulder dash
(ответил в письме)
...К сожалению, я слишком давно занимался внутренностями BoulderDash-ей, в том числе на C64 и Z80, поэтому мне не так просто ответить на ваши вопросы. :)
Могу сказать, что на C64 для BD-игр используется порядка десятка различных движков, каждый движок в той или иной степени отличается кодом, структурой данных и т.п. К примеру, BD1 - это движок из Boulder Dash 1, 3 и др., BD2 - улучшенный вариант BD1, к которому добавили новые элементы, BDKit (названия движков условные) - игры, созданные в Boulder Dash Construction Kit, и несколько любительских, созданных фанатами движков.
Некогда в сети существовал сайт Peter-а Broadribb-а, в котором достаточно подробно разбиралась структура данных и алгоритмы самой игры, попробуйте погуглить, может, что-то осталось от него на других ресурсах. Если ничего не получится, я попробую разобрать файловые завалы на своём компьютере и найти что-нибудь.
Но напишите, пожалуйста, зачем вам это надо?
...К сожалению, я слишком давно занимался внутренностями BoulderDash-ей, в том числе на C64 и Z80, поэтому мне не так просто ответить на ваши вопросы. :)
Могу сказать, что на C64 для BD-игр используется порядка десятка различных движков, каждый движок в той или иной степени отличается кодом, структурой данных и т.п. К примеру, BD1 - это движок из Boulder Dash 1, 3 и др., BD2 - улучшенный вариант BD1, к которому добавили новые элементы, BDKit (названия движков условные) - игры, созданные в Boulder Dash Construction Kit, и несколько любительских, созданных фанатами движков.
Некогда в сети существовал сайт Peter-а Broadribb-а, в котором достаточно подробно разбиралась структура данных и алгоритмы самой игры, попробуйте погуглить, может, что-то осталось от него на других ресурсах. Если ничего не получится, я попробую разобрать файловые завалы на своём компьютере и найти что-нибудь.
Но напишите, пожалуйста, зачем вам это надо?
Re: структура boulder dash
Давно мечтал(может глупо звучит, но всё-таки) сделать свой полноценный БД (потому как до сих пор уважаю на досуге поиграть в него :D )как на С64, чтобы Ф2-старт, 5 сложностей и т.п., надеюсь вы меня понимаете, если не понимаете, не сочтите за труд, всё же какую-либо(если в ваших силах) информацию мне подбросить.stridmann писал(а):(ответил в письме)
...К сожалению, я слишком давно занимался внутренностями BoulderDash-ей, в том числе на C64 и Z80, поэтому мне не так просто ответить на ваши вопросы. :)
Могу сказать, что на C64 для BD-игр используется порядка десятка различных движков, каждый движок в той или иной степени отличается кодом, структурой данных и т.п. К примеру, BD1 - это движок из Boulder Dash 1, 3 и др., BD2 - улучшенный вариант BD1, к которому добавили новые элементы, BDKit (названия движков условные) - игры, созданные в Boulder Dash Construction Kit, и несколько любительских, созданных фанатами движков.
Некогда в сети существовал сайт Peter-а Broadribb-а, в котором достаточно подробно разбиралась структура данных и алгоритмы самой игры, попробуйте погуглить, может, что-то осталось от него на других ресурсах. Если ничего не получится, я попробую разобрать файловые завалы на своём компьютере и найти что-нибудь.
Но напишите, пожалуйста, зачем вам это надо?
Вышеупомянутый ресурс попытался найти-нашёл, но мой английский немного лучше "гугловского", к сожалению... :(
Да и на С64 я не программировал совсем: не знаю структуры памяти и т.д., на спектруме хотя бы немного "крякал" в своё время, программировал немного через "Zeus", помните такой ??
Re: структура boulder dash
вот что за файл я нашёл :) кто бы это перевёл бы ??
BDCFF: Peter Broadribb's binary format proposal
Proposal written by: Peter Broadribb
Last modified: about 11 Nov 1995
Supersedes: nothing
Superseded by: Leon Wennekers's binary format proposal (sorry, not online yet)
________________________________________
In this document:
1. BNF-like specification
2. English description
________________________________________
1. BNF-like description
Here's a sort-of-BNF kind-of specification of the file:
BDCFF ::= header cave* gameAttrib ; ie header followed by zero-or-more caves and then gameAttrib
header ::= signature crc
signature ::= <a 6-byte fixed signature>
crc ::= <a 4-byte CRC over the rest of the file>
cave ::= recordSize width height caveData caveAttributes
recordSize ::= <a 4-byte length count of the width,height,caveData,caveAttributes>
width ::= <a 2-byte integer>
height ::= <a 2-byte integer>
caveData ::= (objectType objectAttributes)* ; ie repeated (width*height) times
objectType ::= <two-byte integer>
objectAttributes ::= <two-byte integer>
caveAttributes ::=
(oneByteTag byte one-byte-padding)
| (twoByteTag byte byte)
| (fourByteTag byte byte byte byte)
| (multiByteTagShort shortLength byte* [one-byte-padding]) ; ie padded to even number of bytes
| (multiByteTagLong longLength byte* [one-byte-padding]) ; ie padded to even number of bytes
oneByteTag ::= <two-byte integer in the range $0000-$03FF>
twoByteTag ::= <two-byte integer in the range $0400-$07FF>
fourByteTag ::= <two-byte integer in the range $0800-$0FFF>
multiByteTagShort ::= <two-byte integer in the range $1000-$1FFF>
multiByteTagLong ::= <two-byte integer in the range $2000-$2FFF>
byte ::= <one-byte integer>
one-byte-padding ::= $00
shortLength ::= <two-byte integer>
longLength ::= <four-byte integer>
gameAttrib ::= caveAttributes ; ie same format but describes game attributes instead
________________________________________
2. English description
Now I'll describe what I mean in English. :)
A BDCFF file consists of:
1. fixed length header
2. zero or more caves
3. game attributes
2.1. File header
The file header consists of:
1. a 6-byte signature, used by downloading agents to identify the file type as a BDCFF file, and by other agents to ensure that the file is in fact a BDCFF file rather than something else
2. a 32-bit CRC of the rest of the file (in specified format; sample code will be available to check and generate these CRCs)
2.2. Cave
An entire cave consists of:
1. record length (4 bytes; see description below)
2. cave width (2 bytes; excludes bounding wall)
3. cave height (2 bytes; excludes bounding wall)
4. cave data (layout of the cave; width*height*4 bytes). The cave is described left-to-right, top-to-bottom. Each cave position takes up four bytes:
1. object type (2 bytes)
2. object attributes (2 bytes)
5. cave attributes (variable length). There may be zero or more attributes, and each attribute has the following format (described more fully below):
o attribute tag (2 bytes)
o optional attribute length (whether present or not depends on the tag)
o attribute data
2.2.1. Record length
The cave starts with a 4-byte record length. This is the number of bytes taken up by the rest of the cave description (width, height, data, attributes), used to be able to determine where in the file the next cave begins, so you can quickly skip to the next cave.
2.2.2. Width and height
The cave width and height are 2-byte integers, indicating the size of the cave. I used 2-byte integers rather than 1-byte integers because potentially you might want a cave that is larger than 256 in one dimension. Shrug; why limit yourself? Anyway, the cave width and height exclude the bounding wall, meaning that you can assume that there is some boundary already in existance which will prevent objects from moving out of bounds. You can, of course, include your own boundary (eg of steel wall) in the cave data if you like, either for visual reasons (because you want the boundary to be of steel wall) or because you do actually use the boundary (eg put the exit box in the bounding steel wall).
2.2.3 Cave data
The size of the cave data can be found by multiplying the cave width by the cave height by 4 (because there are 4 bytes per cave position).
The cave is described by a simple "dump" of its contents; no fancy compression algorithms describing the cave in terms of lines, boxes etc. Each position in the cave is described by a 2-byte object type and 2 bytes of object attributes.
2.2.3.1 Object types
The 2-byte object type permits 65536 different object types. Object types would be things like space, diamond, boulder, firefly, the player, steel wall, brick wall, magic wall, zonk, snik snak, bombs, explosion-to-space, explosion-to-diamond, etc. All these object types would be registered and described in the central BDCFF database on the Net, so you could look up the exact specification about what the object looks like, how the object behaves, and what the attributes field means for that object.
2.2.3.2 Object attributes
The attributes field might be used as a number or as a bitfield. It would be used to describe the different states the object can be in. For example, a firefly can be facing in one of four directions; the magic wall can be inactive, active, or expired; a boulder can be falling or stationary, an explosion can be in one of several stages.
2.2.4 Cave attributes
The variable length cave attributes may describe either things that affect the cave as a whole (such as the amount of time available to complete the cave) or things that affect all objects of a specific type (eg slime permeability, magic wall milling time, amoeba growth factors). It would not include things that affect a set of games together, such as the sequence of caves which form a game; these are described in the Game Attributes.
2.2.4.1 Attribute tags
Since some attributes may be present and others absent, and new attributes might be invented in the future, we need to have a variable structure. The way I propose is to have a tagged structure: tag, data, tag, data, tag, data, ...
For example, let's say we had the following tags defined in BDCFF:
• $0000 = slime permeability (one byte)
• $0400 = time available to complete cave, in seconds (two bytes)
• $0401 = magic wall milling time, in seconds (two bytes)
• $0402 = maximum number of amoeba before it turns into boulders (two bytes)
In the file, the tags might appear in any order. For example, if the cave attributes consisted of: $0400 0015 0000 0700, this would be read as:
• $0400 = tag: number of seconds available follows in the next two bytes
• $0015 = 21 seconds available to complete the cave (assumes high-byte, low-byte format)
• $0000 = tag: slime permeability follows in the next byte, followed by padding
• $0700 = slime permeability = 7; followed by $00 as padding
2.2.4.2 Attribute length
The amount of space required to describe an attribute may vary. Some attributes might be able to be described in only one, two, or four bytes of data. Other attributes might take a variable amount of data (say, text describing the author's name, or a comment). It's even possible that an attribute might take more than 64K of data (perhaps if the attribute contained nested attributes inside?).
But because of the extensibility of the BDCFF specification, where new attribute tags might be defined from time to time, it's possible that some implementation of Boulder Dash might come across an attribute tag that it doesn't know about. Say, for example, that it doesn't know what slime is, and therefore the slime permeability attribute is unknown to it. The implementation needs a way of knowing how long the attribute is, so that it can skip on to the next one.
The way I propose to facilitate this is to group the tags into ranges:
• tags in the range $0000 to $03FF always take one byte of data, followed by one byte of padding
• tags in the range $0400 to $07FF always take two bytes of data
• tags in the range $0800 to $0FFF always take four bytes of data
• tags in the range $1000 to $1FFF are followed by a two-byte length count, which specifies how many bytes of data follow
• tags in the range $2000 to $2FFF are followed by a four-byte length count, which specifies how many bytes of data follow
That way, even if an implementation does not know that attribute tag $0000 means slime permeability, it knows that the tag is followed by one byte of data and one byte of padding, and so it can skip forward to examine the next attribute.
All registered attribute tags will be described in detail in the central BDCFF database, so you can update your BoulderDash program to be able to read and use new tags as they might be created.
2.3 Game attributes
Finally, following all the cave descriptions in the file, the file finishes with game attributes. These are in the same format as the cave attributes just described, but instead describe things that affect the entire set of caves as a whole, rather than just one cave. For example, maybe it might describe the sequence in which caves go to form a game, or something. I don't know, but I'm sure I'll find it useful to have a Game Attributes section sometime. :)
Martijn’s Boulder Dash Fan Site
© Peter Broadribb
BDCFF: Peter Broadribb's binary format proposal
Proposal written by: Peter Broadribb
Last modified: about 11 Nov 1995
Supersedes: nothing
Superseded by: Leon Wennekers's binary format proposal (sorry, not online yet)
________________________________________
In this document:
1. BNF-like specification
2. English description
________________________________________
1. BNF-like description
Here's a sort-of-BNF kind-of specification of the file:
BDCFF ::= header cave* gameAttrib ; ie header followed by zero-or-more caves and then gameAttrib
header ::= signature crc
signature ::= <a 6-byte fixed signature>
crc ::= <a 4-byte CRC over the rest of the file>
cave ::= recordSize width height caveData caveAttributes
recordSize ::= <a 4-byte length count of the width,height,caveData,caveAttributes>
width ::= <a 2-byte integer>
height ::= <a 2-byte integer>
caveData ::= (objectType objectAttributes)* ; ie repeated (width*height) times
objectType ::= <two-byte integer>
objectAttributes ::= <two-byte integer>
caveAttributes ::=
(oneByteTag byte one-byte-padding)
| (twoByteTag byte byte)
| (fourByteTag byte byte byte byte)
| (multiByteTagShort shortLength byte* [one-byte-padding]) ; ie padded to even number of bytes
| (multiByteTagLong longLength byte* [one-byte-padding]) ; ie padded to even number of bytes
oneByteTag ::= <two-byte integer in the range $0000-$03FF>
twoByteTag ::= <two-byte integer in the range $0400-$07FF>
fourByteTag ::= <two-byte integer in the range $0800-$0FFF>
multiByteTagShort ::= <two-byte integer in the range $1000-$1FFF>
multiByteTagLong ::= <two-byte integer in the range $2000-$2FFF>
byte ::= <one-byte integer>
one-byte-padding ::= $00
shortLength ::= <two-byte integer>
longLength ::= <four-byte integer>
gameAttrib ::= caveAttributes ; ie same format but describes game attributes instead
________________________________________
2. English description
Now I'll describe what I mean in English. :)
A BDCFF file consists of:
1. fixed length header
2. zero or more caves
3. game attributes
2.1. File header
The file header consists of:
1. a 6-byte signature, used by downloading agents to identify the file type as a BDCFF file, and by other agents to ensure that the file is in fact a BDCFF file rather than something else
2. a 32-bit CRC of the rest of the file (in specified format; sample code will be available to check and generate these CRCs)
2.2. Cave
An entire cave consists of:
1. record length (4 bytes; see description below)
2. cave width (2 bytes; excludes bounding wall)
3. cave height (2 bytes; excludes bounding wall)
4. cave data (layout of the cave; width*height*4 bytes). The cave is described left-to-right, top-to-bottom. Each cave position takes up four bytes:
1. object type (2 bytes)
2. object attributes (2 bytes)
5. cave attributes (variable length). There may be zero or more attributes, and each attribute has the following format (described more fully below):
o attribute tag (2 bytes)
o optional attribute length (whether present or not depends on the tag)
o attribute data
2.2.1. Record length
The cave starts with a 4-byte record length. This is the number of bytes taken up by the rest of the cave description (width, height, data, attributes), used to be able to determine where in the file the next cave begins, so you can quickly skip to the next cave.
2.2.2. Width and height
The cave width and height are 2-byte integers, indicating the size of the cave. I used 2-byte integers rather than 1-byte integers because potentially you might want a cave that is larger than 256 in one dimension. Shrug; why limit yourself? Anyway, the cave width and height exclude the bounding wall, meaning that you can assume that there is some boundary already in existance which will prevent objects from moving out of bounds. You can, of course, include your own boundary (eg of steel wall) in the cave data if you like, either for visual reasons (because you want the boundary to be of steel wall) or because you do actually use the boundary (eg put the exit box in the bounding steel wall).
2.2.3 Cave data
The size of the cave data can be found by multiplying the cave width by the cave height by 4 (because there are 4 bytes per cave position).
The cave is described by a simple "dump" of its contents; no fancy compression algorithms describing the cave in terms of lines, boxes etc. Each position in the cave is described by a 2-byte object type and 2 bytes of object attributes.
2.2.3.1 Object types
The 2-byte object type permits 65536 different object types. Object types would be things like space, diamond, boulder, firefly, the player, steel wall, brick wall, magic wall, zonk, snik snak, bombs, explosion-to-space, explosion-to-diamond, etc. All these object types would be registered and described in the central BDCFF database on the Net, so you could look up the exact specification about what the object looks like, how the object behaves, and what the attributes field means for that object.
2.2.3.2 Object attributes
The attributes field might be used as a number or as a bitfield. It would be used to describe the different states the object can be in. For example, a firefly can be facing in one of four directions; the magic wall can be inactive, active, or expired; a boulder can be falling or stationary, an explosion can be in one of several stages.
2.2.4 Cave attributes
The variable length cave attributes may describe either things that affect the cave as a whole (such as the amount of time available to complete the cave) or things that affect all objects of a specific type (eg slime permeability, magic wall milling time, amoeba growth factors). It would not include things that affect a set of games together, such as the sequence of caves which form a game; these are described in the Game Attributes.
2.2.4.1 Attribute tags
Since some attributes may be present and others absent, and new attributes might be invented in the future, we need to have a variable structure. The way I propose is to have a tagged structure: tag, data, tag, data, tag, data, ...
For example, let's say we had the following tags defined in BDCFF:
• $0000 = slime permeability (one byte)
• $0400 = time available to complete cave, in seconds (two bytes)
• $0401 = magic wall milling time, in seconds (two bytes)
• $0402 = maximum number of amoeba before it turns into boulders (two bytes)
In the file, the tags might appear in any order. For example, if the cave attributes consisted of: $0400 0015 0000 0700, this would be read as:
• $0400 = tag: number of seconds available follows in the next two bytes
• $0015 = 21 seconds available to complete the cave (assumes high-byte, low-byte format)
• $0000 = tag: slime permeability follows in the next byte, followed by padding
• $0700 = slime permeability = 7; followed by $00 as padding
2.2.4.2 Attribute length
The amount of space required to describe an attribute may vary. Some attributes might be able to be described in only one, two, or four bytes of data. Other attributes might take a variable amount of data (say, text describing the author's name, or a comment). It's even possible that an attribute might take more than 64K of data (perhaps if the attribute contained nested attributes inside?).
But because of the extensibility of the BDCFF specification, where new attribute tags might be defined from time to time, it's possible that some implementation of Boulder Dash might come across an attribute tag that it doesn't know about. Say, for example, that it doesn't know what slime is, and therefore the slime permeability attribute is unknown to it. The implementation needs a way of knowing how long the attribute is, so that it can skip on to the next one.
The way I propose to facilitate this is to group the tags into ranges:
• tags in the range $0000 to $03FF always take one byte of data, followed by one byte of padding
• tags in the range $0400 to $07FF always take two bytes of data
• tags in the range $0800 to $0FFF always take four bytes of data
• tags in the range $1000 to $1FFF are followed by a two-byte length count, which specifies how many bytes of data follow
• tags in the range $2000 to $2FFF are followed by a four-byte length count, which specifies how many bytes of data follow
That way, even if an implementation does not know that attribute tag $0000 means slime permeability, it knows that the tag is followed by one byte of data and one byte of padding, and so it can skip forward to examine the next attribute.
All registered attribute tags will be described in detail in the central BDCFF database, so you can update your BoulderDash program to be able to read and use new tags as they might be created.
2.3 Game attributes
Finally, following all the cave descriptions in the file, the file finishes with game attributes. These are in the same format as the cave attributes just described, but instead describe things that affect the entire set of caves as a whole, rather than just one cave. For example, maybe it might describe the sequence in which caves go to form a game, or something. I don't know, but I'm sure I'll find it useful to have a Game Attributes section sometime. :)
Martijn’s Boulder Dash Fan Site
© Peter Broadribb
Re: структура boulder dash
вот ещё:http://www.elmerproductions.com/sp/peterb/ ---это пожалуй поинтересней будет, там описывается всё детально, я так понял, но не владею я аглицким, не владею--ю-у-у!! 
-
stridmann
- Сообщения: 28
- Зарегистрирован: Чт ноя 23, 2006 12:19 pm
- Откуда: Бердянск, Украина
- Контактная информация:
Re: структура boulder dash
Да, по второй ссылке как раз копия того сайта, про который я говорил раньше.
Но как же вы без английского будете со всем этим разбираться? Ума не приложу...
Но как же вы без английского будете со всем этим разбираться? Ума не приложу...
Re: структура boulder dash
Дык это и есть разбор структуры БД ?? Ага... ну может найду из знакомых кого, кто может перевести или сам на основе моего словарного запаса и метода "научного тыка", ведь с разными там "делюкс пакерами" разобрался. А вы значит руки умываете ? Времени нет... понимаю.stridmann писал(а):Да, по второй ссылке как раз копия того сайта, про который я говорил раньше.
Но как же вы без английского будете со всем этим разбираться? Ума не приложу...
Но и за эту информацию-огромная Вам благодарность!!
-
stridmann
- Сообщения: 28
- Зарегистрирован: Чт ноя 23, 2006 12:19 pm
- Откуда: Бердянск, Украина
- Контактная информация:
Re: структура boulder dash
Времени действительно нет, но вот тут вполне исчерпывающая информация по структуре хранения данных BoulderDash:
http://www.elmerproductions.com/sp/pete ... eData.html
Но я, честно говоря, не понимаю, как вы без английского...
http://www.elmerproductions.com/sp/pete ... eData.html
Но я, честно говоря, не понимаю, как вы без английского...
Re: структура boulder dash
а что это за программкаhttp://www.elmerproductions.com/sp/peterb/decodecaves.c(я так понял, что для декомпрессирования или декодирования БД1) и как её запускать ?stridmann писал(а):Времени действительно нет, но вот тут вполне исчерпывающая информация по структуре хранения данных BoulderDash:
http://www.elmerproductions.com/sp/pete ... eData.html
Но я, честно говоря, не понимаю, как вы без английского...
а это база данных всех пещер на БД1 что ли ??http://www.elmerproductions.com/sp/peterb/cavedata.h
ответьте, пожалуйста, если знаете...
И это что же --- если в моём БД есть зарастающая стенка, то эта прога для декодирования мне безполезна ??
как же так ?? и что делать ??
Re: структура boulder dash
кто бы это бы перевёл на русский подробно ?? ---- http://www.gratissaugen.de/erbsen/BD-Inside-FAQ.html наверное и нет таких знатоков, вот нам бы на форум такую подробную информацию, да на русском !!! эээх
Re: структура boulder dash
Да там вроде на очень простом английском написано. Ничего сложного.
Re: структура boulder dash
Дээс... кому как... дык я в техническом "простом английском" не очень