You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+7-15Lines changed: 7 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -55,18 +55,9 @@ to have a palette offset to choose which "row" of 16 colors from
55
55
the 256-color palette will be used.
56
56
57
57
The elements of the game consist of three independent layers:
58
-
* 320x200 Bitmap backgound, placed 8 pixels from the top of the screen, then end 32 pixels from the bottom. The entire bitmap
59
-
will comprise of only 16 colors, taken from a palette offset.
60
-
* 40x30 map of 8x8 tiles. Each tile can have 16 colors, but also
61
-
its own palette offset. The tiles provide a menu at the top of the
62
-
screen, text display and controls at the bottom. Tiles may also
63
-
act as static overlays on top of the background. Up to 720 unique
64
-
tiles can be defined.
65
-
* 128 individual 16x16 sprites, including a dynamic mouse cursor.
66
-
Each sprite can have 16 colors, from its own palette offset. Up to 512 unique sprite frames can be defined. All sprites except for the mouse cursor are confined to the bitmap area, and support collision
67
-
with other sprites and tiles. The mouse cursor is context-sensitive,
68
-
changing its frame based on its position and game state to indicate
69
-
the type of action that will happen when the mouse button is clicked.
58
+
* 320x200 Bitmap backgound, placed 8 pixels from the top of the screen, then end 32 pixels from the bottom. The entire bitmap will comprise of only 16 colors, taken from a palette offset.
59
+
* 40x30 map of 8x8 tiles. Each tile can have 16 colors, but also its own palette offset. The tiles provide a menu at the top of the screen, text display and controls at the bottom. Tiles may also act as static overlays on top of the background. Up to 704 unique tiles can be defined.
60
+
* 128 individual 16x16 sprites, including a dynamic mouse cursor. Each sprite can have 16 colors, from its own palette offset. Up to 499 unique sprite frames can be defined. All sprites except for the mouse cursor are confined to the bitmap area, and support collision with other sprites and tiles. The mouse cursor is context-sensitive, changing its frame based on its position and game state to indicate the type of action that will happen when the mouse button is clicked.
70
61
71
62
## Memory Map
72
63
Main RAM ($0801-$9EFF): XCI engine code, top-level game data (starting at $6000)
@@ -90,8 +81,9 @@ zone is loaded to banked RAM from the file system. Up to 256
90
81
different zones can be defined.
91
82
92
83
VRAM:
93
-
* Bank 0: Bitmap ($0000-$95FF), Tile Map ($9600-$A5FF), Tiles ($A600-$FFFF)
94
-
* Bank 1: Sprites ($0000-$FFFF)
84
+
* Bank 0: Bitmap ($0000-$95FF), Tile Map ($9600-$A5FF),
85
+
Unused ($A600-$A7FF), Tiles ($A800-$FFFF)
86
+
* Bank 1: Sprites ($0000-$F9BF), VERA registers ($F9C0-$FFFF)
95
87
96
88
## Data Format
97
89
All game data (except for background bitmaps and music files) are described in text files, starting with a main file. This file defines the top-level game data, providing references to all other source files. Its filename is the only command-line input to the software development kit (SDK) executable (**xci.exe**). It is simply a set of key-value pairs. There are certain mandatory keys that are required for the game to be successfully built. Unrecognized keys are ignored by the build utility, as are comments, which begin with a hash (```#```) symbol. Keys have no spaces and are not case-sensitive, but values may be case-sensitive and consist of all text after the first whitespace after the key up to the end of the line or the start of a comment. A value can contain a hash character by escaping it with a backslash (i.e. ```\#```). And if a value contains a backslash character, that can be escaped with a double backslash (```\\```).
@@ -128,7 +120,7 @@ $ /path/to/xci.exe mygame.xci
128
120
If it finishes without errors, the game is built! Let's assume that zone 0 has 2 levels, zone 1 has 3 levels, and zone 2 a full 10 levels. The following binaries will be generated:
129
121
130
122
***MAIN.BIN** - This is the compiled version of **mygame.xci**. This will be loaded into base RAM by the XCI program (**XCI.PRG**) at run time. This and all binaries generated by the build utility (in addition to **XCI.PRG**) need to be loaded into the X16 file system to run the game. It will contain information from **mygame.xci** and other files specified by the main file keys.
131
-
***PAL.BIN** - This is the initial palette for the game, as specified by the filename after the **palette** key (**mygame_pal.hex**) and other configuration data. It will be loaded by the XCI program into VRAM (F:1000) prior to displaying the title screen. Note that the palette beyond index 15 will be modified as different parts of the game are loaded.
123
+
***PAL.BIN** - This is the initial palette for the game, as specified by the filename after the **palette** key (**mygame_pal.hex**) and other configuration data. It will be loaded by the XCI program into VRAM (1:FA00) prior to displaying the title screen. Note that the palette beyond index 15 will be modified as different parts of the game are loaded.
132
124
***TILES.BIN** - This is the binary version of **mygame_tiles.hex**, which contains the tile set for the game, as specified by the **tiles_hex** key. It will be loaded by the XCI program into VRAM (0:A600) prior to displaying the title screen.
133
125
***SPRITES.BIN** - This is the binary version of **mygame_sprites.hex**, which contains the sprite frames for the game, as specified by the **sprites_hex** key. It will be loaded by the XCI program into VRAM (1:0000) prior to displaying the title screen.
134
126
***TTL.BM.BIN** - This is the background bitmap for the title screen, specified by the contents of **mygame_start.xci**, which will be explained later. It will be loaded into VRAM (0:0000) once the palette, tiles and sprites are all loaded. Unlike the background bitmaps of the game levels, this bitmap can take up the full screen (320x240). This will remain in VRAM and on screen until the player starts a new game or loads a saved game. It is never stored in base or banked RAM.
0 commit comments