This weekend I've implemented a few things into Manta-X, changed a few things around and generally made progress.
GUI
The bug in the GUI system was a simple fix, I was doing the pointIn() routines based on an absolute co-ordinate system when my GUI is set up for relative co-ordinates. Simple, really. I still need to figure out a nice way of the GUI passing messages back to the game. I say 'nice' because I'm fond of creating overly complex systems when a simple one would do. I think I'll sketch out a few possible solutions and go with the simplest and most game independent. The text boxes and labels need fixing, as does the clipping of elements within a parent (there isn't any at present).
Collision
I've added basic bounding box collision detection. It works for now, but I'll add a pre-check of bounding sphere as the BB is more expensive than I'd hoped.
GLFW
I've gutted all Windows specific code from Manta-X, opting to use the GLFW framework instead. It's quite nice in some ways, but it does seem slightly slower than my previous Win32 API implemenation.
Game States
I've implemented the notion of Game States to Manta-X. So far, there's only two, the 'Play' state and the 'Edit' State. Switching between them is fairly easy, the IGameState interface class forces my states to have enterState, exitState and executeState methods, meaning that states can clean up things such as the camera and GUI when they are pushed onto or popped off the game state stack.
Profiler
I took the profiler code from the Enginuity base code and planted it pretty much untouched into my base. It's nice to see that the system that hogs the most time is the Renderer, more specifically the rendering of particles. Suffice to say there's some definite tweakage needed there before long.
Fixed time step failure
I tried out the fixed time step code from here, only to totally screw up the game. The problem wasn't down to the fixed time step per se, but the fact that my rendering code cannot interpolate between two render frames, resulting in very jerky motion. To implement a fixed time step, I'll have to figure out a way to do this. But that's one for later methinks.
Space Background
I also spent a good hour or so trying to get a space background texture to work. I knocked one up quickly in my paint program, but fell down when it came to actually implementing the damn thing. I'm not quite sure why it didn't work, but I'm sure to investigate that later. It's not a major thing yet, but I just thought it'd make things look nicer.
I experienced the same sort of failure early in the development of 2D Golem. The solution to the problem involves maintaining 2 sets of state data for an object. For instance, maintaining a LastPosition and a NextPosition. Each update, the current NextPosition becomes the current LastPosition, and a new NextPosition is calculated. Then when rendering, I take the PercentWithinTick value calculated as part of Javier's loop, and apply a linear interpolation formula to LastPosition and NextPosition, to calculate the current position at which to draw the object.
For 2D graphics, there is really no way to interpolate the animation sequences themselves, but for 3D graphics that are animated by interpolation between frames or keyframes anyway, it becomes a simple matter to use PercentWithinTick as a further interpolant to smooth the animation. However, I found that in 2D Golem it doesn't really matter if I can not interpolate the animations; as long as the actual movement is smoothed by interpolation, it still looks good.
I wrote a very small bouncy ball sample program for SDL that demonstrates the interpolation method, as part of a short article I wrote as a sort of supplemental to Javier's original explanation. When the program is running, Space Bar will toggle between interpolated and non-interpolated rendering, to show exactly how the smoothing makes a difference.