I'm reading
this C tutorial and am making progress. Things are starting to sink in now, and I can see myself coding Zeus for Mac OS X in the very near future, like starting tonight and tomorrow. Or I might take a break tomorrow after my slew of 2 months of all-nighters and messed up sleep schedules! After C, it's Objective-C, then Xcode, then OpenGL... all of these would add to my previous studies, but with the revelation that function declarations are the same thing as function prototypes, I feel like some missing puzzle pieces that bogged my mind are coming together, and I'm remembering how the way Xcode deals with the information you type in is actually convenient (whereas before I was confused why it did what it did, as my mind was sort of overloaded with information).
I was primarily confused with functions because I had mis-remembered what I learned in high school from studying C++. I had remembered that the functions were as such:
Code: Select all
function_name (variable_returned_by_this_function)
Instead, it is:
Code: Select all
function_return_datatype function_name (variable_passed_to_this_function)
Some things are probably messed up in my head right now, because I am like a dead man walking (or just sitting) in terms of fatigue.
eidt - it's conna fiel wierld going to sleep at night again.
And this means that I'm seeing why you guys were saying what you were saying about things like defining tag types as structs. Makes so much sense now, except I'll have to get more information before it makes enough sense to know exactly how to start. By the way, you can consider this post my commentary as I go along reading that C tutorial. I'll just edit this post.
I'm thinking that Sparky's Plugins are basically the starting point for structs for each tag type, where the values (including my "experimental" values) would be variables within the tag's struct, such as, off the top of my head:
Code: Select all
typedef H1FT_scen
{
dependency [which would be another type definition] ref_mod2 [or maybe just 'mod2'];
...
struct [another type definition] predefined_resources [or whatever the heck it's called, unused anyway];
...
string usage [this one isn't actually in this tag type, maybe, I forgot];
}
So for datatypes like
struct and
dependency and
loneID and, and, and... I would need to define structs for each of these.
Then, I would define structs for each tag type, using Sparky's Plugins as a reference.
I'm thinking structs are objects...
I don't know how defining
structs as structs will work, though.
I'm renaming this post to
"Sparky's C / Objective-C / Cocoa / OpenGL Monologue".
- Done with that; saving these for later:
http://theocacao.com/document.page/231
http://theocacao.com/document.page/234
http://cocoadevcentral.com/d/learn_objectivec/
and in general, the rest of the relevant tutorials at
http://cocoadevcentral.com/
--
Starting the code by beginning with defining datatypes used in the tag metadata. I determined that, based upon my previous Plugin Writer's Guide notes, that the only datatypes that would need to be defined are:
the beginnings of [b][color=#BFFF00]datatypes.h[/color][/b] wrote:Code: Select all
// bitmasks
typedef struct {
}bitmask8;
typedef struct {
}bitmask16;
typedef struct {
}bitmask32;
// colors
typedef struct {
}colorbyte;
typedef struct {
}colorRGB;
typedef struct {
}colorARGB;
// references
typedef struct {
}dependency;
typedef struct {
}index;
typedef struct {
}loneID;
// struct (reflexive chunks) -- might not need this type, use 'struct' instead?
typedef struct {
}reflexive;
I would include that
datatypes.h header file at the top of each header file that parses a tag, like scen.h for parsing scen tags. Once the tag parsing files are done, I would include each halo tag parsing file in yet another header file, which would be used as a singular reference for all the Halo1-related map file actions. These files would be bundled into a Framework, and updated versions of the Framework would add support for different versions of map files, such as Halo 2, Halo 3, etc.
So right now, I'm working on a framework for parsing Blam! engine data files related to Halo games. I have not been able to figure out what a "library" is, but I'd say that it's actually a Halo file parser library that I'm trying to figure out how to do now, which would be bundled in a framework along with some documentation for how to use it with a program like Zeus afterwards.
Either you are groping for answers, or you are asking God and listening to Jesus.
FINALLY... lol. I gave up two previous attempts already over a period of a couple years.
