I’ve put a bit more thought into the design of the core objects and the interaction between them. This process led to a couple of refactorings and several refinements. I’m happier now with the current state of the core, though I may still need to revisit the Renderer. I did add OpenGL context association to the class, so that when a Renderer is activated via its begin() method it can determine if its associated context is current. This is necessary because each renderer instance maintains its own state. It doesn’t do any sort of context management, as that’s not the Renderer’s domain. What I’m not settled on completely yet is the Renderer’s interface. I think I’m headed in the right direction, but I just need to use it enough to fine tune it.
I’ve implemented the interface for the resource system. Each resource type gets its own loader registry. The first loader registry I implemented is for Image objects. I also implemented a loader for bitmaps via SDL to test it out. I think the interface works well. Right now it can search one or more configurable paths for resources. Each resource type can get its own set of paths. It’s also generic enough that it can be extended to transparently load from zip archives or other sources.
Something I didn’t expect was to spend a big amount of time on the game loop. There are several different ways to implement game loops, some better than others. Considering that the core of the library will eventually need to support more than simple 2D games, I wanted something that was going to be robust. Closely involved with this is timing. Should the engine maintain a global ’simulation time’ or should I leave that up to the game? Ultimately, I decided on the approach described by Glenn Fielder on his blog. The GameContainer maintains the current simulation time and the amount by which to advance it on each update tick. Game logic, executed during update ticks, is decoupled from rendering. The time step is configurable, based on the FPS of the update ticks. So users can run the game logic at 30, 60, or however many FPS they want while the rendering goes as fast as it can. I’ve still got a bit more work on the GameContainer interface to support an event-based paradigm, which would be needed when creating an editor with the Win32 API, for example.
I had been using a simple little app to test each feature as I developed it, but I wanted to see everything working together at once. So, I threw together a simple Pong game. Two things I took away from that are that I like the core interface so far and that I’m not too sure about the game loop. There was some sporadic stuttering going on with the movement of the ball and paddles when using interpolation, though it was mostly smooth. I don’t know yet if that is related to the game loop implementation or to the SDLGameContainer’s time() implementation (which calls SDL_GetTicks). I’m going to play around with it and see if I can tweak it. It might be related to the time step value I chose. I’ll also try alternative game loop implementations and see if they make a difference.
Technorati Tags: Devlog, D Programming Language, game programming, Smoothie, Pong, 2D game engine
Post a Comment