The Weekend SVN Logblog (Oct. 19, 2008)
It was a busy week for my hobby projects. I made some substantial performance improvements to the engine and started a small side project that has been shaking out bugs like crazy. Let's take a look:
------------------------------------------------------------------------
r858 | Administrator | 2008-10-14 00:40:52 -0700 (Tue, 14 Oct 2008) | 1 line
Big particles refactoring, so that particle systems don't allocate and create new vertex buffers every frame. Sadly, locking and copying doesn't seem much faster.
I've been worried about the performance of my engine for a little while now; I was only getting 20-30fps in Release mode, and the rates in Debug were almost unplayable. Profiling suggested that particle systems were to blame, so I looked into it and realized that I had left particles in a very hacky state, intending to come back and clean it up if performance started to degrade. Every frame, for every particle system, I was allocating new vertex arrays and creating new Direct3D vertex buffers from them. I rewrote it to reuse a persistent vertex array (updated each frame) and to lock and modify a dynamic Direct3D vertex buffer for each particle system. As the changelog suggests, it wasn't actually a great performance gain, but it helps a bit and I feel better about the code. I still hate having to deal with dynamic Direct3D objects when resetting the device, though.
------------------------------------------------------------------------
r860 | Administrator | 2008-10-14 22:57:51 -0700 (Tue, 14 Oct 2008) | 1 line
Added some HTTP socket stuff for eventually doing leaderboards, stat tracking, whatever.
Inspired by J. Kyle's leaderboard solution for Arc, I decided to dig into WinSock and get some communication going with my web server. I found it surprisingly easy to establish the connection and send HTTP requests, and before long, I had a sample program sending a POST request to a Python CGI script and getting back a meaningful response. I'll have to revisit some of this when it comes time to actually write the leaderboard code, because I'm not actually parsing the response yet, but for a first pass at something I had no prior experience with, I was very satisfied with the time it took to get something running.
------------------------------------------------------------------------
r862 | Administrator | 2008-10-15 06:14:38 -0700 (Wed, 15 Oct 2008) | 1 line
Added core of a new profile system. None of the UI is started yet, and profiles can't be deleted, but the folder structure and config files are all working as intended.
------------------------------------------------------------------------
r866 | Administrator | 2008-10-15 18:30:50 -0700 (Wed, 15 Oct 2008) | 1 line
Short of finding and fixing bugs, profile system is done.
A profile system is something I've been thinking about for a while now, but I kept debating its usefulness. Basically, it provides a named container for saved games and player options, so that multiple players sharing a computer can have their own personal configurations. The leaderboard concept (coupled with a sick day that gave me hours and hours to work at home) finally provided the catalyst for doing this, because I wanted to have a constant user name available instead of making the player type a name every time he submitted a score. Despite it being a fairly significant chunk of work, I managed to finish the bulk of the profile system in just over twelve hours on Wednesday, with a last few fixes coming in just before midnight.
------------------------------------------------------------------------
r871 | Administrator | 2008-10-16 19:52:25 -0700 (Thu, 16 Oct 2008) | 1 line
Added typed EIDs.
This is a small one, but significant for code readability and type safety. I previously just used unsigned integers (EIDs, or Entity IDs) as handles to game entities. It's a simple abstraction trick: these EIDs are used as keys to look up the Entity pointers in a map, so a deleted object will return NULL and I avoid dangling pointers. In the past, I would simply static_cast the returned Entity* to whatever type I knew the handle was meant to represent, but I was never happy with that solution. Now I have a small TypedEID class, templated on the type of Entity it refers to. This class mostly just wraps the basic EID functionality, but it returns a pointer to the correct type (just static_cast still) and also has a slightly more expensive checked accessor that returns NULL if the actual type of the entity does not match the class template. (This requires run-time type information, but I've previously rolled my own RTTI implementation, so that was free.)
------------------------------------------------------------------------
r881 | Administrator | 2008-10-18 16:45:22 -0700 (Sat, 18 Oct 2008) | 1 line
Some initial work on the Commonplace Compo map.
I've been trying to get involved in the indie games scene a bit more, and to that end, I'm entering the TIGSource Commonplace Book Competition. It's a very casual competition: no entry fees, no prizes--mostly just a deadline so people actually get things done. The theme is H. P. Lovecraft's "commonplace book," a journal in which he jotted down ideas and story fragments that might eventually have been developed into fuller stories. I chose the following quotation to base my game upon:
30 Strange visit to a place at night--moonlight--castle of great magnificence etc. Daylight shews either abandonment or unrecognisable ruins--perhaps of vast antiquity.
Strange Visit, as I'm calling it, will be a small game built on the engine I've already got. Because I don't have any real gameplay systems yet, it will about atmosphere, exploration, and discovery instead of rules of play. Developing a real level has uncovered some latent bugs that were hiding in my engine (especially with regard to sectors and portals), but I've been steadily squashing those as they arise.
I expect that the next few weeks will be consumed almost entirely with content development for Strange Visit. I'll return to programming around Thanksgiving, after the competition deadline, and finally start developing some gameplay systems (weapons, inventory, AI, etc.).
------------------------------------------------------------------------
r858 | Administrator | 2008-10-14 00:40:52 -0700 (Tue, 14 Oct 2008) | 1 line
Big particles refactoring, so that particle systems don't allocate and create new vertex buffers every frame. Sadly, locking and copying doesn't seem much faster.
I've been worried about the performance of my engine for a little while now; I was only getting 20-30fps in Release mode, and the rates in Debug were almost unplayable. Profiling suggested that particle systems were to blame, so I looked into it and realized that I had left particles in a very hacky state, intending to come back and clean it up if performance started to degrade. Every frame, for every particle system, I was allocating new vertex arrays and creating new Direct3D vertex buffers from them. I rewrote it to reuse a persistent vertex array (updated each frame) and to lock and modify a dynamic Direct3D vertex buffer for each particle system. As the changelog suggests, it wasn't actually a great performance gain, but it helps a bit and I feel better about the code. I still hate having to deal with dynamic Direct3D objects when resetting the device, though.
------------------------------------------------------------------------
r860 | Administrator | 2008-10-14 22:57:51 -0700 (Tue, 14 Oct 2008) | 1 line
Added some HTTP socket stuff for eventually doing leaderboards, stat tracking, whatever.
Inspired by J. Kyle's leaderboard solution for Arc, I decided to dig into WinSock and get some communication going with my web server. I found it surprisingly easy to establish the connection and send HTTP requests, and before long, I had a sample program sending a POST request to a Python CGI script and getting back a meaningful response. I'll have to revisit some of this when it comes time to actually write the leaderboard code, because I'm not actually parsing the response yet, but for a first pass at something I had no prior experience with, I was very satisfied with the time it took to get something running.
------------------------------------------------------------------------
r862 | Administrator | 2008-10-15 06:14:38 -0700 (Wed, 15 Oct 2008) | 1 line
Added core of a new profile system. None of the UI is started yet, and profiles can't be deleted, but the folder structure and config files are all working as intended.
------------------------------------------------------------------------
r866 | Administrator | 2008-10-15 18:30:50 -0700 (Wed, 15 Oct 2008) | 1 line
Short of finding and fixing bugs, profile system is done.
A profile system is something I've been thinking about for a while now, but I kept debating its usefulness. Basically, it provides a named container for saved games and player options, so that multiple players sharing a computer can have their own personal configurations. The leaderboard concept (coupled with a sick day that gave me hours and hours to work at home) finally provided the catalyst for doing this, because I wanted to have a constant user name available instead of making the player type a name every time he submitted a score. Despite it being a fairly significant chunk of work, I managed to finish the bulk of the profile system in just over twelve hours on Wednesday, with a last few fixes coming in just before midnight.
------------------------------------------------------------------------
r871 | Administrator | 2008-10-16 19:52:25 -0700 (Thu, 16 Oct 2008) | 1 line
Added typed EIDs.
This is a small one, but significant for code readability and type safety. I previously just used unsigned integers (EIDs, or Entity IDs) as handles to game entities. It's a simple abstraction trick: these EIDs are used as keys to look up the Entity pointers in a map, so a deleted object will return NULL and I avoid dangling pointers. In the past, I would simply static_cast the returned Entity* to whatever type I knew the handle was meant to represent, but I was never happy with that solution. Now I have a small TypedEID class, templated on the type of Entity it refers to. This class mostly just wraps the basic EID functionality, but it returns a pointer to the correct type (just static_cast still) and also has a slightly more expensive checked accessor that returns NULL if the actual type of the entity does not match the class template. (This requires run-time type information, but I've previously rolled my own RTTI implementation, so that was free.)
------------------------------------------------------------------------
r881 | Administrator | 2008-10-18 16:45:22 -0700 (Sat, 18 Oct 2008) | 1 line
Some initial work on the Commonplace Compo map.
I've been trying to get involved in the indie games scene a bit more, and to that end, I'm entering the TIGSource Commonplace Book Competition. It's a very casual competition: no entry fees, no prizes--mostly just a deadline so people actually get things done. The theme is H. P. Lovecraft's "commonplace book," a journal in which he jotted down ideas and story fragments that might eventually have been developed into fuller stories. I chose the following quotation to base my game upon:
30 Strange visit to a place at night--moonlight--castle of great magnificence etc. Daylight shews either abandonment or unrecognisable ruins--perhaps of vast antiquity.
Strange Visit, as I'm calling it, will be a small game built on the engine I've already got. Because I don't have any real gameplay systems yet, it will about atmosphere, exploration, and discovery instead of rules of play. Developing a real level has uncovered some latent bugs that were hiding in my engine (especially with regard to sectors and portals), but I've been steadily squashing those as they arise.
I expect that the next few weeks will be consumed almost entirely with content development for Strange Visit. I'll return to programming around Thanksgiving, after the competition deadline, and finally start developing some gameplay systems (weapons, inventory, AI, etc.).
posted by David at
1:53 PM
0 Comments:
Post a Comment
<< Home