Sign in to follow this  
  • entries
    570
  • comments
    2427
  • views
    216034

Untitled

Sign in to follow this  
Mushu

61 views

Okay, stuff is starting to get a little messy in here.

Components are stored in sets, which are divided by class. Since we can have multiple sets loaded, we've got a map of sets, sorted by filename. Okay. So our megalith component-holding structure looks like this -

std::map > >

Now, this is an oversimplification, because each layer of that is wrapped in its own class with nice access functions, to make it easier.

That's just for the generic component tree. What about our handy objects to which we're adding these components to? Well, these are a little simpler - we've got a tree of hardpoints and components they're bound to, but we've also got an index of every hardpoint in the tree, sorted by the hardpoint name.

tree
std::map


I hope you went 'wtf' at tree. Because I sure am whumping my head on the table at the moment, because I wrote my own datastructure. STUPID. STUPID. STUPID. I think this is probably the key source of my problem, because I never wrote methods to iterate through it. Well, not really. Its a mess.

Okay, now lets look back at the first megalith. Now... how are we supposed to iterate that? Well, the obvious answer is to say "Fuck it this is stupid lets think of a better way to do it", but noooo I'm too stupid to figure out that solution. What we're looking at is a triple-for loop for searching, yes! A TRIPLE FOR LOOP. Now, I'm not anti-loops or anything, but this just seems ridiculous.

Sigh. At this point, the stuff is pretty worked into the code, so it would be more work than its worth to uproot it and plant something better. Thankfully, none of this code will be used in the actual game portion, its just for the GUI crap which is fuckless performance intensive.

Premature pessimisation GO!!!

(haha, I love how a google search for "premature pessimisation" returns me as one of the top results...)
Sign in to follow this  


4 Comments


Recommended Comments

I suspect you know this already...

it would be quite nice to add some typedefs so your container doesn't look so intimidating...

typedef std::set<Component> ComponentSet;
typedef std::map<std::string, ComponentSet> ComponentMap;

std::map<std::string,std::map<std::string,std::set<Component> > > becomes std::map<std::string,ComponentMap>

Or something like that :D

With containers I like to do a few typedefs so

std::map<std::string,object *>

will have

typedef std::map<std::string,object *> ObjectMap;
typedef ObjectMap::iterator ObjectMapIterator;

Share this comment


Link to comment
Indeed, everything is already typedef'ed. The problem with that is it hides the sheer complexity of everything. I untypedef'ed everything in the post to expose the convoluted mess that it is.

And right now, I'm left wondering (given a Component*) how to extract the texture information, given just the filename of the texture. Why the fuck isn't there a texture handle in the Component class? Seriously. What the fuck.

Share this comment


Link to comment
Haha, I might have to call you out on that, since my writing skills are teh suck.

I don't really want to start "hiring" people to help out yet though, at least not before I have something to prove to myself this isn't just vapourware. I'd hate to have you guys spend time producing assets for a game that isn't guarenteed to finish :[

At the same time, I'd love to have someone helping out with the writing. Give me a week or two more so I can gauge how things are progressing a little better; hopefully by then I'll have something better to work with.

:D

Share this comment


Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now