kts c7f3ac15d3 added pack_tiles.c, providing pack_tiles, a program that takes a directory as an argument and creates a new file (directory/directory.tsd) from cleaned files 'doors', 'floors', 'npcs', 'walls', 'equips', 'items', and 'players' in that directory. At the moment it can be used on the xibalba directory to create 'xibalba/xibalba.tsd', which can then be tested with test/t2d.c, providing the internal filename referenced is changed. At the moment the Data system does not properly deal with inventories so any inventory/equipment declaration is ignored.		2013-12-21 02:38:08 -08:00
..
Makefile	Implemented Data system fully now (not integrated into ts engine itself yet). In the process added a new Table (hash table) system that matches keys to values. More information pertaining to that in data.h/data.c. Might switch over to a system wherein all Tiles are actually TileData structs (or contain TileData structs). This would increase the processing necessary, as values for properties must be acquired from a string instead of reading from a pre-defined struct, but it would increase the modularity immensely as there is no real limit on the amount of properties a Tile may contain (which will be most important once the interpreter is implemented and used for tile movement, collisions, etc.).	2013-12-20 18:24:06 -08:00
script.c	Added two folders: test/ and xibalba/. Contained within test/ are two test/devel-beds for two systems that will be integrated within ts. The first is script.c, which is the development program for the interpreter system - this interpreter system allows for the setting of variables (both local and global), the creation of new functions, and the definition of default in-game functions such as dice rolling and the like. The second file, t2d.c functions as a basic test utility for Tile Data loading and the like - it interprets a tileset/tile definition file into Data, TileDataSet, and TileData(s) respectively. These structs, as defined in data.c/.h, allow for reference to tiles by TID:ID or simply by name through the use of key=>value pairs. It is from these structs and their accompanying access functions that new Tiles will be created (perhaps later optimized through a basic Tile array that contains semi-populated Tile(s) that can be memcpy'd similar to the current system). Also added the xibalba/ sub-dir that will contain the various data for Xibalba (tile definitions, graphics, map creation, etc.), moving majority of what is in tiles/ into xibalba/.	2013-12-17 17:08:37 -08:00
t2d.c	added pack_tiles.c, providing pack_tiles, a program that takes a directory as an argument and creates a new file (directory/directory.tsd) from cleaned files 'doors', 'floors', 'npcs', 'walls', 'equips', 'items', and 'players' in that directory. At the moment it can be used on the xibalba directory to create 'xibalba/xibalba.tsd', which can then be tested with test/t2d.c, providing the internal filename referenced is changed. At the moment the Data system does not properly deal with inventories so any inventory/equipment declaration is ignored.	2013-12-21 02:38:08 -08:00
table_test.c	Implemented Data system fully now (not integrated into ts engine itself yet). In the process added a new Table (hash table) system that matches keys to values. More information pertaining to that in data.h/data.c. Might switch over to a system wherein all Tiles are actually TileData structs (or contain TileData structs). This would increase the processing necessary, as values for properties must be acquired from a string instead of reading from a pre-defined struct, but it would increase the modularity immensely as there is no real limit on the amount of properties a Tile may contain (which will be most important once the interpreter is implemented and used for tile movement, collisions, etc.).	2013-12-20 18:24:06 -08:00
tiles.txt	Implemented Data system fully now (not integrated into ts engine itself yet). In the process added a new Table (hash table) system that matches keys to values. More information pertaining to that in data.h/data.c. Might switch over to a system wherein all Tiles are actually TileData structs (or contain TileData structs). This would increase the processing necessary, as values for properties must be acquired from a string instead of reading from a pre-defined struct, but it would increase the modularity immensely as there is no real limit on the amount of properties a Tile may contain (which will be most important once the interpreter is implemented and used for tile movement, collisions, etc.).	2013-12-20 18:24:06 -08:00