X-Git-Url: https://www.kengrimes.com/gitweb/?p=henge%2Fwebcc.git;a=blobdiff_plain;f=src%2Fapc%2Fir.h;h=53b1d65c075399a176df24b0156e8c94d0b5489b;hp=0292e01bedad24b6762cb9dcd79c610e0214641a;hb=c5aa6d0763078cf697ecb8c2b561a2cc521dfbd6;hpb=e5054c6c4d93c47e798ee59d73e232e436a00855

diff --git a/src/apc/ir.h b/src/apc/ir.h
index 0292e01..53b1d65 100644
--- a/src/apc/ir.h
+++ b/src/apc/ir.h
@@ -28,34 +28,8 @@
 #define MAX_CHUNKS 256
 #define PAGES_PER_CHUNK 16
 
-/*  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.                                */
-
-/*  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))   */
-
-/*  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.                    */
+/*  Sets: 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];
@@ -64,12 +38,11 @@ struct set {
 };
 
 /*  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       */
+/*  data types of the IR. 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     */
+/*  of the cdat itself but rather in 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.                               */
@@ -84,9 +57,6 @@ struct cdat {
   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
@@ -114,11 +84,6 @@ struct ref {
 };
 
 
-/* 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
@@ -131,15 +96,14 @@ struct ref {
    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*/
+/* Svlinks stand for short vlink, which is a link to a vdat. svlinks
+   differ from vlinks because they do not have a name */
 
 struct svlink {
   uint64_t ref_id;
 };
 
-/* A vlink is what it sounds like, a link to a vdat
- TODO: model link? */
+/* A vlink is what it sounds like, a link to a vdat */
 struct vlink {
   uint64_t ref_id;
   char anim_name[32];
@@ -156,20 +120,15 @@ union link_t {
   struct svlink svlink;
 };
 
+/* From: Some odat ()To: Another odat (ref_id)*/
 struct link {
   int type; //1 = olink, 2 = vlink, 3 = svlink
   union link_t link_t;
-  int cdat_idx;
+  struct cdat* classp;
   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
@@ -178,14 +137,14 @@ struct link {
    TODO: Need more info about objects at runtime, to described
          the reasoning behind odat structure at compile-time*/
 
-
 struct root {
   int x, y, z;
 };
 
 struct odat {
   char name[32];
-  int vdat_id;
+  struct vdat* vdatp;
+  int vdat_id; //
   int cdat_idx;
   int hitbox;
   uint64_t ref_id;