| « new month, new life | XRhodes camera demo take 2 » |
refactor & optimize day
After a few days' procrastination I managed to move on with the construction (and even my trig studies).
The next step is the unification of rendering and collision detection.
Follow up:
These systems are composed of several elements, and some of them were just too closely coupled and had to be cut free from each other. The collision system used to (and still is, as I haven't yet touched it) operate with shapes, which will be unfortunate as soon as I get to using it with sprites. The reason is that linear transformations used to be carried out on the shapes themselves, which you won't be able to do with resources (them being const).
The Transformation class which the Renderees and Camera are built on is getting delegated for the calculation of linear transformations (LT) (it used to be data-only with values for position, rotation, scaling and the camera was calculating the LT matrices). What's still to be decided is whether the Transformation objects should keep a LT matrix (in addition to the scaling and rotation values) that's recalculated on every LT operation, or should I just provide a method that can export the transformations into a matrix (which is what the class has to do for OpenGL anyway in a bid for optimization) on the spot.
Approach 1 has the merit of not having to calculate the LT matrix every frame, only when it's about to change, but it increases the size of Transformation objects. This is only a memory issue if anything as everything that's bigger than sizeof(float) (except for doubles, which I don't really use let alone pass around) gets passed around by reference, but 16 bytes per object should be fine for now.
Approach 2 has the merit of calculating LT matrices only when it's needed, plus resulting in smaller objects.
I guess I'll only be able to pick the ultimate solution when I refactored collision detection. Although I only got back to checking FPS' today, what I've done seems to have resulted in an increase of FPS values. As how we stand now, with one 640*480 texture, some text (avg. 120 chars / frame) and 8 entities in the camera, on a 2.4GHz iMac, is 1400+FPS, which is not bad (I don't know, there's about a 300 FPS drop when entities are so close they almost cover the whole screen... is this realistic? Then again, is this going to happen in most of the games?).
I'll see how much is going to be left after collision detection starts ticking under the hood. For the weekend, I'm so off (...to Yorkshire. Work related.=P).
