-/*!@file
- \brief Intermediate Representation (IR) between Directory Structure and Engine Grammar
- \details The IR serves as a storage structure that is populated during the
- parsing of the input directory structure. After parsing is complete,
- the IR will be condensed (removed of excess allocated space) and then
- output as the Engine Grammar. In this file we describe the semantic actions
- that are called at each step, and the memory buffers that they populate.
- See parser.y for the description on how the input grammar is constructed,
- and where/when semantic actions are called.
- TODO: or just write it here.
- \author Jordan Lavatai
- \date Aug 2016
- ----------------------------------------------------------------------------*/
-
-
-#include <stdint.h>
-
-#define BUF_SIZE 256
-#define MAX_SETS 256
-#define MAX_ELES 256
-#define MAX_QUADS 256
-#define MAX_MODELS 256
-#define MAX_POSTS 256
-#define MAX_CLASS_DEPTH 256
-#define MAX_CLASSES 256
-#define MAX_FRAMES 256
-#define PTRS_IN_PAGE 1024
-
-/* General: All information from the directory structure is stored in */
-/* five buffers that comprise the IR: cdat_buf, odat_buf, vdat_buf, ref_buf */
-/* and link_buf. Each buf corresponds to the data structure that it stores. */
-/* The storage techique for all bufs (except cdat) is the same. Each bufs member first */
-/* populates its struct and then allocates the space for the next member */
-/* and increments the buf index. This means that we have to allocate the */
-/* very first member of each buf at ir_init(), so that we don't segfault */
-/* as the first member attempts to access memory that its previous member */
-/* didn't allocate (because it doesnt exist). We access the buf members */
-/* through standard array indexing but conceal the tediousness of array */
-/* indexing with macros. E.g. without macros, acessing an elements name */
-/* member would look like (split up to not go over line char limit): */
-/* (*cdat_stackp)->set_list[(*cdat_stackp)->num_sets] */
-/* .ele_list[(*cdat_stackp)->set_list[(*cdat_stackp->num_sets)].num_ele].name */
-
-/* For cdats in cdat_buf, we allocate the memory for a cdat once a cdat
- is recognized in the grammar. Cdat_buf is different from the other bufs
- because cdats have a root cdat that all cdats are a subclass of. This root
- cdat can have a set_list like other cdats. */
-
-/* Elements: Ele stands for element and has two representations in the IR. */
-/* In the cdat_buf eles store their name, cdat_idx (their classes index in */
-/* the cdat_buf) and the ref_id (refer to ref ). In the odat_buf, eles store */
-/* their object data (odat). At output time, the ref_id is dereferenced to */
-/* determine the elements odat which is the data that the engine expects */
-extern struct cdat** cdat_stackp;
-/* from an element. */
-
-
-/* All bufs are of pointers to their respective structs. When a buf is full */
-/* (number of data structs pointers >= max number of data struct pointers), */
-/* we need to allocate a more pointers for that buf. Allocate these */
-/* pointers a page at a time (1024 = Page bytes (4096)/bytes per pointer(4)) */
-
-struct ele {
- char name[32];
- uint64_t ref_id;
- int cdat_idx;
-};
-
-/* Sets: The set is similar to the ele, but it contains a list of its */
-/* elements. The set is populated at parse time AFTER the elements are */
-/* populated, due to the nature of bottom up parsing. */
-
-struct set {
- char name[32];
- uint64_t ref_id;
- int cdat_idx;
- int num_ele;
- struct ele ele_list[MAX_ELES];
-};
-
-/* Cdats: A cdat is a class data structure. Cdats serve as the central */
-/* data types of the IR. At output, the cdat_buf is iterated through and */
-/* each is written to the output file. For each cdat, sets and element */
-/* ref_ids must be dereferenced to determine the odat information. Cdats */
-/* contain pointers to their subclasses so that the relationship between */
-/* classes can be determined, but the subclasses are not represented inside */
-/* of the cdat itself but rather in the subsequent cdats in cdat_buf. We */
-/* can determine the number of subclasses (the last index into cdat_buf */
-/* that represents a subclass of some arbitrary cdat) each cdat has by */
-/* incrementing num_classes during parse time. */
-/* TODO: Should classes point to their parent class? */
-
-struct cdat {
- char name[32];
- int idx;
- int num_classes;
- int num_sets;
- struct cdat* class_list[MAX_CLASSES];
- struct set set_list[MAX_SETS];
-};
-
-/* There are an unknown amount of cdats at compile time, so we maintain */
-/* a cdat_buf of cdat pointers that can be expanded as needed. */
-
-/* The cdat_stack is a stack pointers to cdat pointers, the top of which is
- the cdat that is currently being parsed. Whenever a new cdat is recognized
- by the grammar (CLOPEN), a cdat is pushed onto the cdat_stack, and we refer
- to this cdat through the macro CURR_CDAT. By keeping a cdat_stack, we have
- access to the current cdat so that the elements and sets can populate themselves
- in the cdat accordingly. */
-
-
-/* Refs: Each set/ele has a reference to its object data (odat) through a ref_id.
- Ref_ids are unsigned 64 byte integers that map to the hex values RGBA. During
- the construction of the directory structure, users can choose a RGBA value for
- each object that any other object can refer to via links (see link). If a user
- does not choose an RGBA value, then the object is given one from the system space.
- We maintain a doubly linked list of refs in the ref_buf at parse time so that
- links can be resolved after the parsing of the directory structure is complete.
- For every 16th ref, we create a post so that we can reduce on the search time for
- a random access. */
-
-struct ref {
- int type;
- struct ref* nextref;
- struct ref* lastref;
- struct odat* odatp;
- uint64_t ref_id; //0xFFFFFF->digit
-};
-
-
-/* Like the cdat_buf, ref_buf stores pointers to refs and can
- increase in size */
-
-/* posts for ref_buf */
-
-/* Links: At parse time, a set/ele can include a link in their
- grammar representation instead of the actual data and this signifies
- to the APC that that set/ele wishes to use the data of another
- set/ele, either its video data (vdat) or object data (odat). The link
- itself contains the type of link it is, the ref_id OR name, and
- which set/ele created the link. During parse time, links can be made
- to o/vdats that have yet to be parsed. In order to accomodate for this,
- we resolve all links AFTER parse time by iterating through the link_buf,
- finding the ref_id that was stored for some object (if the ref_id exists),
- and creating a relative pointer from the original object to the data that
- was linked */
-
-/* Svlinks stand for short vlink, which is a link to a vdat
- TODO: diff btwn vlink*/
-
-struct svlink {
- uint64_t ref_id;
-};
-
-/* A vlink is what it sounds like, a link to a vdat
- TODO: model link? */
-struct vlink {
- uint64_t ref_id;
- char anim_name[32];
-};
-
-/* Olinks are links to odats */
-struct olink {
- uint64_t ref_id;
-};
-
-union link_t {
- struct olink olink;
- struct vlink vlink;
- struct svlink svlink;
-};
-
-struct link {
- int type; //1 = olink, 2 = vlink, 3 = svlink
- union link_t link_t;
- int cdat_idx;
- int set_idx;
- int ele_idx;
-};
-
-/* link_buf contains all the links that
- we encountered during parse time that need
- to be resolved to an offset at output time.
- This does not include quad refs, because
- those are already known to need to be resolved */
-
-
-/* Odats: Odats consist of the object data necessary for
- each object. Odats are sometimes referred to as archetypes
- at compile-time, in order to distinguish the difference from
- a runtime object and a compile-time object.
- TODO: Need more info about objects at runtime, to described
- the reasoning behind odat structure at compile-time*/
-
-/* Each set has a quad_list or a list of quads. The quad_list
- is the ? */
-struct quad {
- int x, y, z;
- uint64_t ref_id; //rgba
-};
-
-struct root {
- int x, y, z;
-};
-
-struct odat {
- char name[32];
- int vdat_id;
- int cdat_idx;
- int hitbox;
- struct root root;
- struct ref* refp; /* pointer to it's ref on ref_list */
- void* quad_filep;
-};
-
-struct odat* curr_set_odatp; //when a set has elements, insert_set() can no longer
- //refer to its odat via curr_odat, so save the set odat.
-
-/* A framesheet is a grouping of animation frames in
- a single direction (N,W,S,E) */
-struct framesheet {
- int width;
- int height;
- int num_frames;
- void* frames[MAX_FRAMES];
-};
-
-/* A model is a collection of framesheets for every
- direction (N,W,S,E,NW,NE,SW,SE)*/
-/* NAMED spritesheet */
-struct model {
- char name[32];
- struct framesheet spritesheet[8]; //one for each
-};
-
-/* Vdat: Vdats are the video data of each object. They can not be
- created as a stand alone object (because they consist solely
- of animation information and not the skeleton on which the
- animation manipulates). Vdats have a list of models for every
- animation that the vdats odat can do for that vdat*/
-struct vdat {
- struct odat* creator; //pointer to odat that made this vdat
- int num_models;
- struct model model_list[MAX_MODELS];
-};
-
-/* Called after the cdat open operator has been recognized in grammar. Allocates
- the space for a cdat on the cdat_buf, pushes that pointer onto
- the cdat_stack */
-void
-push_cdat(char*);
-
-/* Called after a cdat end operator has been recognized in grammar. Sets
- top stack cdat ** to null and decrements stack pointer */
-void
-pop_cdat(void);
-
-/* Called after an odat has been populated. Allocates memory for
- the next odat. */
-
-void
-insert_set_label(char*, uint64_t);
-
-/* Populate the sets representation in CURR_CDAT with a ref_id and insert a link
- into the link_buf that will resolve the ref_id to an actual odat after parse time. */
-void
-insert_set_olink(uint64_t);
-
-/* Put the vlink in the link_buf to be processed after parsetime */
-void
-insert_set_vlink(uint64_t, char*);
-
-/* Put svlink in the link_buf to be processed after parsetime */
-void
-insert_set_svlink(uint64_t);
-
-/* Called for every set reduction except for sets with olinks. Populates the
- set data structures in the CDAT and in the ODAT. Uses the name and ref_id
- from insert_set_label. Also inserts a ref into the ref_buf with the CURR_ODAT
- pointer so that we can also resolve the odat from its ref_id. */
-void
-insert_set(void);
-
-/* Insertion of eles is practically equivalent to how sets are inserted because both
- share the same data type (ODAT). Like sets, eles have links, labels
- and odats. Eles have the added notion of a parent set, and so must be inserted
- into said parent set, but this is the only place they truly differ from sets. */
-
-void
-insert_set_vdatid(void);
-
-void
-insert_ele_label(char*, uint64_t);
-
-/* Insert an ele olink into the CURR_ODAT */
-void
-insert_ele_olink(uint64_t);
-
-/* Insert a ele vlink into CURR_ODAT*/
-void
-insert_ele_vlink(uint64_t, char*);
-
-/* Inserts an ele short vlink into CURR_ODAT*/
-void
-insert_ele_svlink(uint64_t);
-
-/* inserts ele into CURR_CLASS and CURR_ODAT */
-void
-insert_ele(void);
-
-void
-insert_ele_vdatid(void);
-
-/* Inserts the hitbox into the CURR_ODAT */
-void
-insert_hitbox(int);
-
-/* Inserts the root into the CURR_ODAT */
-void
-insert_root(int, int, int);
-
-/* Inserts a quad into the CURR_ODAT */
-void
-insert_quad(void*);
-
-void
-insert_model(void);
-
-void
-insert_framesheet(char, char*, uint64_t, int, int, int);
-
-void
-insert_frame_pointer(char, void*);
-
-void
-alloc_vdat(void);
+/*!@file\r
+ \brief Intermediate Representation (IR) between Directory Structure and Engine Grammar\r
+ \details The IR serves as a storage structure that is populated during the\r
+ parsing of the input directory structure. After parsing is complete,\r
+ the IR will be condensed (removed of excess allocated space) and then\r
+ output as the Engine Grammar. In this file we describe the semantic actions\r
+ that are called at each step, and the memory buffers that they populate.\r
+ See parser.y for the description on how the input grammar is constructed,\r
+ and where/when semantic actions are called.\r
+ TODO: or just write it here.\r
+ \author Jordan Lavatai\r
+ \date Aug 2016\r
+ ----------------------------------------------------------------------------*/\r
+\r
+\r
+#include <stdint.h>\r
+#include <unitypes.h>\r
+#include <limits.h>\r
+\r
+#define BUF_SIZE 256\r
+#define MAX_SETS 256\r
+#define MAX_ELES 256\r
+#define MAX_QUADS 256\r
+#define MAX_MODELS 256\r
+#define MAX_MODEL_LEN 256\r
+#define MAX_MAPS 8\r
+#define MAX_POSTS 256\r
+#define MAX_CLASS_DEPTH 256\r
+#define MAX_CLASSES 256\r
+#define MAX_FRAMES 256\r
+#define PTRS_IN_PAGE 1024\r
+#define MAX_CHUNKS 256\r
+#define PAGES_PER_CHUNK 16\r
+\r
+/* Sets: elements. The set is populated at parse time AFTER the\r
+ elements are populated, due to the nature of bottom up parsing. */\r
+\r
+struct set {\r
+ uint8_t name[32];\r
+ int ref_id;\r
+ int cdat_idx;\r
+};\r
+\r
+/* Cdats: A cdat is a class data structure. Cdats serve as the central */\r
+/* data types of the IR. For each cdat, sets and element */\r
+/* ref_ids must be dereferenced to determine the odat information. Cdats */\r
+/* contain pointers to their subclasses so that the relationship between */\r
+/* classes can be determined, but the subclasses are not represented inside */\r
+/* of the cdat itself but rather in subsequent cdats in cdat_buf. We */\r
+/* can determine the number of subclasses (the last index into cdat_buf */\r
+/* that represents a subclass of some arbitrary cdat) each cdat has by */\r
+/* incrementing num_classes during parse time. */\r
+/* TODO: Should classes point to their parent class? */\r
+\r
+struct cdat {\r
+ uint8_t name[32];\r
+ int idx;\r
+ int num_classes;\r
+ int num_sets;\r
+ struct cdat* class_list[MAX_CLASSES];\r
+ struct set set_list[MAX_SETS];\r
+};\r
+\r
+/* The cdat_stack is a stack pointers to cdat pointers, the top of which is\r
+ the cdat that is currently being parsed. Whenever a new cdat is recognized\r
+ by the grammar (CLOPEN), a cdat is pushed onto the cdat_stack, and we refer\r
+ to this cdat through the macro CURR_CDAT. By keeping a cdat_stack, we have\r
+ access to the current cdat so that the elements and sets can populate themselves\r
+ in the cdat accordingly. */\r
+\r
+\r
+/* Refs: Each set/ele has a reference to its object data (odat) through a ref_id.\r
+ Ref_ids are unsigned 64 byte integers that map to the hex values RGBA. During\r
+ the construction of the directory structure, users can choose a RGBA value for\r
+ each object that any other object can refer to via links (see link). If a user\r
+ does not choose an RGBA value, then the object is given one from the system space.\r
+ We maintain a doubly linked list of refs in the ref_buf at parse time so that\r
+ links can be resolved after the parsing of the directory structure is complete.\r
+ For every 16th ref, we create a post so that we can reduce on the search time for\r
+ a random access. */\r
+\r
+struct ref {\r
+ int type;\r
+ struct ref* nextref;\r
+ struct ref* lastref;\r
+ struct odat* odatp;\r
+ int ref_id; //0xFFFFFF->digit\r
+};\r
+\r
+\r
+/* Links: At parse time, a set/ele can include a link in their\r
+ grammar representation instead of the actual data and this signifies\r
+ to the APC that that set/ele wishes to use the data of another\r
+ set/ele, either its video data (vdat) or object data (odat). The link\r
+ itself contains the type of link it is, the ref_id OR name, and\r
+ which set/ele created the link. During parse time, links can be made\r
+ to o/vdats that have yet to be parsed. In order to accomodate for this,\r
+ we resolve all links AFTER parse time by iterating through the link_buf,\r
+ finding the ref_id that was stored for some object (if the ref_id exists),\r
+ and creating a relative pointer from the original object to the data that\r
+ was linked */\r
+\r
+/* Svlinks stand for short vlink, which is a link to a vdat. svlinks\r
+ differ from vlinks because they do not have a name */\r
+\r
+struct svlink {\r
+ int ref_id;\r
+};\r
+\r
+/* A vlink is what it sounds like, a link to a vdat */\r
+struct vlink {\r
+ int ref_id;\r
+ uint8_t anim_name[32];\r
+};\r
+\r
+union link_t {\r
+ struct vlink vlink;\r
+ struct svlink svlink;\r
+};\r
+\r
+/* From: src odat ()To: dest odat (ref_id)*/\r
+struct link {\r
+ int type; //1 = olink, 2 = vlink, 3 = svlink\r
+ union link_t link_t;\r
+ struct cdat* classp;\r
+ struct odat* odatp;\r
+ int set_idx;\r
+ int ele_idx;\r
+};\r
+\r
+struct root {\r
+ int x, y, z;\r
+};\r
+\r
+struct quad {\r
+ int x;\r
+ int y;\r
+ int z;\r
+ int ref_id;\r
+};\r
+\r
+/* maps: maps store the different map data for each archetype. */\r
+struct map {\r
+ uint8_t name[NAME_MAX];//TODO:Rename\r
+ uint8_t filepath[PATH_MAX];//TODO: Rename\r
+ int height;\r
+ int width;\r
+ };\r
+\r
+/* Odats: Odats consist of the object data necessary for\r
+ each object. Odats are sometimes referred to as archetypes\r
+ at compile-time, in order to distinguish the difference from\r
+ a runtime object and a compile-time object.\r
+ TODO: Need more info about objects at runtime, to described\r
+ the reasoning behind odat structure at compile-time*/\r
+struct odat {\r
+ uint8_t name[32];\r
+ struct vdat* vdatp;\r
+ int vdat_id; //\r
+ int cdat_idx;\r
+ int hitbox;\r
+ int ref_id;\r
+ struct odat* parent_odatp; // odat == set ? null : set ref_id\r
+ struct root root;\r
+ struct ref* refp; /* pointer to it's ref on ref_list */\r
+ struct map map;\r
+ //int mli; //map list index\r
+};\r
+\r
+struct odat* curr_set_odatp; //when a set has elements, insert_set() can no longer\r
+ //refer to its odat via curr_odat, so save the set odat. \r
+\r
+/* A framesheet is a grouping of animation frames in\r
+ a single direction (N,W,S,E) */\r
+struct framesheet {\r
+ int width;\r
+ int height;\r
+ int num_frames;\r
+ void* frames[MAX_FRAMES];\r
+};\r
+\r
+/* A model is a collection of framesheets for every\r
+ direction (N,W,S,E,NW,NE,SW,SE)*/\r
+/* NAMED spritesheet */\r
+struct model {\r
+ uint8_t name[MAX_MODEL_LEN];\r
+ uint8_t filepath[PATH_MAX];\r
+ struct framesheet spritesheet[8]; //one for each\r
+};\r
+\r
+/* Vdat: Vdats are the video data of each object. They can not be\r
+ created as a stand alone object (because they consist solely\r
+ of animation information and not the map which the\r
+ animation manipulates). Vdats have a list of models for every\r
+ animation that the vdats odat can do for that vdat*/\r
+struct vdat {\r
+ struct odat* creator; //pointer to odat that made this vdat\r
+ int num_models;\r
+ uint8_t filename[NAME_MAX/sizeof(ucs4_t)];\r
+ int height;\r
+ int width;\r
+ uint8_t filepath[PATH_MAX/sizeof(ucs4_t)];\r
+ struct model model_list[MAX_MODELS];\r
+};\r
+\r
+/* Called after the cdat open operator has been recognized in grammar. Allocates\r
+ the space for a cdat on the cdat_buf, pushes that pointer onto\r
+ the cdat_stack */\r
+void\r
+push_cdat(uint8_t*);\r
+\r
+/* Called after a cdat end operator has been recognized in grammar. Sets\r
+ top stack cdat ** to null and decrements stack pointer */\r
+void\r
+pop_cdat(void);\r
+\r
+/* Called after an odat has been populated. Allocates memory for\r
+ the next odat. */\r
+\r
+void\r
+insert_set_label(uint8_t*, int);\r
+\r
+/* Populate the sets representation in CURR_CDAT with a ref_id and insert a link\r
+ into the link_buf that will resolve the ref_id to an actual odat after parse time. */\r
+void\r
+insert_set_olink(int);\r
+\r
+/* Put the vlink in the link_buf to be processed after parsetime */\r
+void\r
+insert_set_vlink(int, uint8_t*);\r
+\r
+/* Put svlink in the link_buf to be processed after parsetime */\r
+void\r
+insert_set_svlink(int);\r
+\r
+/* Called for every set reduction except for sets with olinks. Populates the\r
+ set data structures in the CDAT and in the ODAT. Uses the name and ref_id\r
+ from insert_set_label. Also inserts a ref into the ref_buf with the CURR_ODAT\r
+ pointer so that we can also resolve the odat from its ref_id. */\r
+void\r
+insert_set(void);\r
+\r
+/* Insertion of eles is practically equivalent to how sets are inserted because both\r
+ share the same data type (ODAT). Like sets, eles have links, labels\r
+ and odats. Eles have the added notion of a parent set, and so must be inserted\r
+ into said parent set, but this is the only place they truly differ from sets. */\r
+\r
+void\r
+insert_set_vdatid(void);\r
+\r
+void\r
+insert_ele_label(uint8_t*, int);\r
+\r
+/* Insert an ele olink into the CURR_ODAT */\r
+void\r
+insert_ele_olink(int);\r
+\r
+/* Insert a ele vlink into CURR_ODAT*/\r
+void\r
+insert_ele_vlink(int, uint8_t*);\r
+\r
+/* Inserts an ele short vlink into CURR_ODAT*/\r
+void\r
+insert_ele_svlink(int);\r
+\r
+/* inserts ele into CURR_CLASS and CURR_ODAT */\r
+void\r
+insert_ele(void);\r
+\r
+void\r
+insert_ele_vdatid(void);\r
+\r
+void\r
+insert_vdat(uint8_t*, int, int, uint8_t*);\r
+/* Inserts the hitbox into the CURR_ODAT */\r
+void\r
+insert_hitbox(int);\r
+\r
+/* Inserts the root into the CURR_ODAT */\r
+void\r
+insert_root(int, int, int);\r
+\r
+/* Inserts a quad into the CURR_ODAT */\r
+void\r
+insert_quad(int, int, int, int);\r
+\r
+void\r
+insert_map(uint8_t*, int, int, uint8_t*);\r
+\r
+void\r
+insert_model(void);\r
+\r
+void\r
+insert_framesheet(uint8_t, uint8_t*, int, int, int, int);\r
+\r
+void\r
+insert_frame_pointer(uint8_t, void*);\r
+\r
+\r
projects / henge / webcc.git / blobdiff