On Week 36
skyjake:
I was a bit under the weather last week, which unsurprisingly meant there was little progress. I also felt I needed something fresh to work on as the debugging can get a bit tiresome, so I started looking into getting rid of SDL_net and concluded that the best way forward would be to revise the project's build system to use qmake instead of CMake. Unlike the current build setup, qmake will allow us to use the same project files on all platforms, simplifying life for packaging and distribution. This is also a good opportunity to improve support for 64-bit builds. I've decided to switch to native 64-bit builds for daily development on my iMac, which should benefit the Linux 64-bit build, too.
Once the new qmake project files are done, I should be able to add a Snow Leopard builder into the automated build system. Thus far I've been using the 10.4 SDK for compiling one binary for all Mac OS X versions (>= 10.4) with universal PowerPC + 32-bit Intel binaries. Having a separate build for 10.6+ will allow ditching PowerPC and supporting native 64-bit binaries in the release.
When it comes to building on Windows, currently Qt works best with VS2008. Support for VS2010 will likely arrive at a later point, but for the time being I'm going to be using VS2008 (VC++ 9.0) for building the project with qmake.
In my qmake work branch, I've already replaced SDL_net with an empty dummy implementation. After everything can be built properly on all platforms, I will implement the low-level networking routines using Qt. Once complete, we will finally have a full-featured low-level networking interface that allows the engine to be more intelligent when it comes to deciding how much data to send and when.
My plan is to continue on the qmake transition and if possible, check out some multiplayer issues.
danij:
The refactoring work continued this week in branch ringzero. DFILE has now been whittled down to nothing more than a data buffer and a stream interface and all open files are now represented by their AbstractFile derived specializations even for the purposes of F_Access queries.
The next step for this is to replace the stream interface, perhaps leveraging an adapted version of skyjake's new Reader class. However before this work can begin I intend to address the lack of a public file handle/object reference in our API. To this end I extracted the file list functionality implemented by the file system module, wrapped it up in a FileList object and made a few design changes to effect the use of the nodes in said lists as our new public file handle object.
Like skyjake I must confess that the sometimes seemingly never ending refactoring and debugging is starting to take its toll. Whilst significant progress continues to be made and the gap between master and ringzero branches is steadily narrowing - it does tend to wear one down somewhat.
I think what I personally need is a brief diversion into completely unrelated territory. Over the next few days I'll be putting some thought into where this little detour might take me. Any suggestions?
Otherwise the plan for the coming week remains largely unchanged - continue addressing regressions and improving the robustness of the new functionality in branch ringzero.
I was a bit under the weather last week, which unsurprisingly meant there was little progress. I also felt I needed something fresh to work on as the debugging can get a bit tiresome, so I started looking into getting rid of SDL_net and concluded that the best way forward would be to revise the project's build system to use qmake instead of CMake. Unlike the current build setup, qmake will allow us to use the same project files on all platforms, simplifying life for packaging and distribution. This is also a good opportunity to improve support for 64-bit builds. I've decided to switch to native 64-bit builds for daily development on my iMac, which should benefit the Linux 64-bit build, too.
Once the new qmake project files are done, I should be able to add a Snow Leopard builder into the automated build system. Thus far I've been using the 10.4 SDK for compiling one binary for all Mac OS X versions (>= 10.4) with universal PowerPC + 32-bit Intel binaries. Having a separate build for 10.6+ will allow ditching PowerPC and supporting native 64-bit binaries in the release.
When it comes to building on Windows, currently Qt works best with VS2008. Support for VS2010 will likely arrive at a later point, but for the time being I'm going to be using VS2008 (VC++ 9.0) for building the project with qmake.
In my qmake work branch, I've already replaced SDL_net with an empty dummy implementation. After everything can be built properly on all platforms, I will implement the low-level networking routines using Qt. Once complete, we will finally have a full-featured low-level networking interface that allows the engine to be more intelligent when it comes to deciding how much data to send and when.
My plan is to continue on the qmake transition and if possible, check out some multiplayer issues.
danij:
The refactoring work continued this week in branch ringzero. DFILE has now been whittled down to nothing more than a data buffer and a stream interface and all open files are now represented by their AbstractFile derived specializations even for the purposes of F_Access queries.
The next step for this is to replace the stream interface, perhaps leveraging an adapted version of skyjake's new Reader class. However before this work can begin I intend to address the lack of a public file handle/object reference in our API. To this end I extracted the file list functionality implemented by the file system module, wrapped it up in a FileList object and made a few design changes to effect the use of the nodes in said lists as our new public file handle object.
Like skyjake I must confess that the sometimes seemingly never ending refactoring and debugging is starting to take its toll. Whilst significant progress continues to be made and the gap between master and ringzero branches is steadily narrowing - it does tend to wear one down somewhat.
I think what I personally need is a brief diversion into completely unrelated territory. Over the next few days I'll be putting some thought into where this little detour might take me. Any suggestions?
Otherwise the plan for the coming week remains largely unchanged - continue addressing regressions and improving the robustness of the new functionality in branch ringzero.
Comments
Though the 'other' side of my brain has indeed suffered of late I grant you. Heh. I already do try to keep fit and regularly work out. I'm not the archetypical white n' pasty, socially-inept coder who doesn't see sunlight for days on end