Template programming & modelling ‘sprites’

Does that term ring a bell? No?

Just in case it didn't, it's a programming method that allows you to write functionality that can handle different types of objects. A template function that returns the biggest object of the two you send it only has to be written once, even if you use it throughout your code with different types. The trick is, the compiler generates an appropriate function for every different type you call the function with.

This means you don't have to rewrite your function for every new type it needs to support. If you're familiar with web-design, it's kind of like using .css files to store your websites style information in.

Coggie prototype model

Besides creating a template quad-tree that can be used both by the renderer and the collision system, I've also made a quick model of the coggie enemy. It's meant to be sort of cute-looking, with a charming in-game behaviour: coggies go stand on their hands and rotate their wheels against another as a sort of greeting, and they occasionally operate cog wheels found throughout the level as well. :)

I'm investigating screen-capturing animated models like this one. It's faster and easier to animate than a hand-drawing approach, but probably still requires manual polishing afterwards. Interesting…

Advertisements
Template programming & modelling ‘sprites’

Purge thy downloads!

I just cleaned out my downloads folder. Usually, I'm a bit afraid to throw things away – you might just have some use for it, later – but I figured that if I'm not using it now, I'm probably not using it later anyway. Any tools I would need later can simply be downloaded again and it's likely I'll find even better tools in the process…

Anyway, the cleansing freed up well over 2 GB on HD space. Which gives me a total of 20% free disk space. And really, I can't imagine how all the things on my computer take up over 60 GB… I guess my old levels and art and such do have some impact, as well as 'forgotten' files and games…

SpaceMonger screenshotIt's time to dig up the nice little tool called SpaceMonger. Displays the selected drive as a collection of boxes (folders), sized according to their size on the HD. So, I'm going to check my C drive now. Are you with me?

// Just used it, and while it takes some time to analyse a HD, it already saved me 10 more GB. Now that's what I call purging. :)

Purge thy downloads!

How collision detection surprized me…

That's right, I didn't think about collision detection enough when I tried to implement the level loader code. The level file format specifications are ready and I've already written code to load it, but the question is: where to store this loaded data?

I need to split up the sprite lists. Inserting new sprites while ordering them on their Z value (so they are rendered in good order) is nice, but not when the list contains 10.000+ items… Besides creating a second list that contains the static sprites, I think it's also a good idea to use a quad-tree instead for faster rendering. And that's what got me thinking: how about the collision stuff? Do I want to put that in the game logic code? How would entities use the collision system – do they need to know things beforehand, or afterwards, or consistently… and so on?

For now, I've decided to create a new 'module' for the collision handling, that behaves much like the rendering module: entities can register an instance, update it, and request collision checks. A quad-tree for the static items, and a list for the dynamic items sounds like a fair solution, too.
With this approach, the entity system doesn't get cluttered with collision-specific code, and non-physical entities do not clutter the collision system. I hope…

And that all because of quad-trees… :)

How collision detection surprized me…