Bryce's Adventures

File Format Brainstorming

Okay, I lied.  There will be no demo level or screenshots just yet.  I’m not ready yet.

Instead I will be sharing my thought process for the design of the file format for the rooms in my adventure engine.  In order to keep compatibility between games and upgraded versions of the engine, it is important that the format is right the first time.

The item in the format will be the bitmap of the room.  This will be loaded at address $1000, and since it need not be relocated, it will allow for more room for the engine and the rest of the file buffer.  The bitmap will probably also include a window of text.  Not only does this save the  ~240 bytes that would otherwise be used for this text, but it also allows the bitmap to be loaded in a continuous manner (again, no relocation necessary).  The downside is that storing the text in a bitmap format takes eight times that RAM it would take to store it in ASCII format.  This will increase loading times substantially, but there is no other method if the screen is to be loaded directly to $1000.

After the bitmap, it makes sense to have the bitmap’s color memory.  This must be relocated because color memory is all the way up at $9400.  Color memory will take 210 bytes uncompressed.  I will definitely implement some form of compression.  Since each color location only takes a nybble of memory, this can easily be cut to 105 bytes.  Further compression may reduce this even more.  While I’m on the topic of color memory, I might as well explain a little bit about how colors should be used properly.

• The bitmap is either all hi-res or all multicolor.  This is to avoid flickering sprites, and sprites must use the same color-mode as the screen.
• The border color (by default) will determine the color of the cursor sprite.  This is more of a suggestion than a rule.  By keeping the cursor sprite the same color as the border all the other colors are open for the screen to be drawn with.  Two of which (auxiliary and background) have twice the number of colors available as the border.  Most importantly, it leaves the versatile color map alone.
• Sprites cannot (or at least should not) enter the menu.  The menu will always be drawn in hi-res mode to allow for 40 columns of text, so it is particularly catastrophic if the sprite that enters it expects multi-color color (as I expect most will).

Okay, so after the color memory, there will be a few arrays of the item and door structures.  This could take as little as two bytes, or a lot more.  The structures will contain data for the sprite that represents them (their appearance), an ID number, and a status byte that must be written somewhere (RAM or file- if a file then it must be loaded to RAM upon entering the room) to show the state of the item or door.  In the case of the item, a zero will mean the item is no longer in the room, nonzero will mean it is still there.  A zero for a door means it is open, while a nonzero number means it is closed.  If RAM gets tight, these bytes can be consolidated and represented by a single bit.

Finally, the BASIC “script” is loaded.  The BASIC pointers will also need to be readjusted since the “script” is not always located at the same place.  Any free room at the end of BASIC can be used for data used by BASIC for things like sprites.

Alright.  That’s it for now.  I’m almost done with the inventory system, so this is next on my agenda.  Maybe by April I’ll have that demo room ready.