So I’ve been working on my graphics assignment. It’s a pretty straightforward thing — progressive meshes — but I decided that my old basecode is fairly dusty. Moreso since the old basecode was designed entirely to do 2D stuff. I used it last year for the Chaotic Audio Visual Synthesis (part II) project in the beginner’s graphics course, and it was a bit of a hassle for the second half, where the visualizer was in 3D.

Weird issues with maintaining OpenGL state and shit when switching back and forth between projections and stuff.

Anyway. So I’m writing a bunch of new basecode from scratch. I know this is one of those things which you’re not supposed to do, but I tend to do it anyway. I’m actually reusing quite a bit of the old code (copypasta’ing it over), but I dunno. Feels more like a complete overhaul.

For instance. In both versions of the code, I have a hard-on for the Observer pattern for handling input. In the old version, I used a traditional “implement this interface then gimmeh a pointer to an instance”, but that turns out to be kind of bloated and unuseful. So instead of holding a list of pointers, I’m holding a list of boost::function’s. Which is awesome and great, because I can masturbate boost::bind to reduce code bloat a bit with some generalized functions. Probably a tad bit more overhead, but wtf it’s just input code, nothing performance-critical.

Also, it’ll make it really fucking easy to add Python bindings to the GUI events later on.

The next thing I wanted to do was implement some kind of FVF-ish vertex structures, where you tell the compiler (statically) what kind of vertex you wanted to use, then it uses it and the rendering code understands what you want and renders it accordingly.

So the first step was to find some way to define the vertex shit, and it was fairly straightforward:

typedef tarp::gfx::Vertex<
	boost::mpl::vector<
		tarp::gfx::vert_attribs::Position< int >,
		tarp::gfx::vert_attribs::Normal< double >,
		tarp::gfx::vert_attribs::TexCoords< double >
	>
> VertexType;

Basically, I have a set of pre-made vertex attributes, and with the dark magic of boost::mpl I can dynamically build a class hierarchy from that typelist -

template < class Attributes = boost::mpl::vector< vert_attribs::Position > >
struct Vertex :
	boost::mpl::inherit_linearly< Attributes,
		boost::mpl::inherit< boost::mpl::_1, boost::mpl::_2 > >::type
{};

Hot shit, right?

Well, there’s a slight issue here – boost::inherit kind of inflates the class hierarchy a bit with boost::mpl::empty_base’s, which are simply struct {}’s. Unfortunately, MSVC8 isn’t optimizing this into an empty object (ie, sizeof( boost::mpl::empty_base ) == 1). Which means I get an extra byte for each instance inherit throws at me. Which is like 8 extra bytes for a 3-attribute vertex declaration.

Kind of annoying, but I think I’ll manage to deal with it. I wanna tinker some more to make sure it isn’t just a weird packing issue, but I dunno.

Sepples.

EDIT:

Bleh, it isn’t a problem of boost::mpl::empty_base’s being thrown into my hierarchy, but rather, the hierarchy itself which is causing all the bloat. And it’s a significant amount of bloat too; for two attributes the overhead is doubled, for more the overhead is progressively less than double but still apparent. (looks like the size overhead is an additional 12B/attribute)…

I wrote my own quick hierarchy generation thing to test that out -

template <
	class T1 = boost::mpl::empty_base,
	class T2 = boost::mpl::empty_base,
	class T3 = boost::mpl::empty_base
>
struct SlimVertex : T1, T2, T3 {};

template <
	class T1,
	class T2
>
struct SlimVertex< T1, T2, boost::mpl::empty_base > : T1, T2 {};

template <
	class T1
>
struct SlimVertex< T1, boost::mpl::empty_base, boost::mpl::empty_base > : T1 {};

And it generates the exact same results as the version which uses boost::mpl. Which is a bit of a nightmare really. And it does it in release mode too – so I don’t think there are any optimization options which I can tinker with to fix it.

There’s probably a perfectly valid reason why it does this, but such an explanation would probably be beyond my ability to comprehand. I wonder if gcc bloats ‘em up good too eh.

No comments