In my developer life I developed many little applications and libraries to see, how to deal with API’s, special programming techniques or new languages. My reason to stop my experimental work before getting something useful was everytime the same thing: my movitation was gone or another experimental code was more interesting than the current experiment or feature. The same thing happened happened to me in the ZFXCE. I tried out a new technique, but before finishing this ( because I get no benefit of it ) I started something new. So in the redesign phase I deleted a lot of deprecated and not working code.
But some experiments were finished successfully: the experiments, which implementations have solveld a real issue. So how can I use this to have more success in my bigger projects like the ZFXCE. In the ZFX-Community-Engine we have one major issue: we don’t have any customers and no projects, which needs new fatures.
So what can I do to improce this? It’s quite simple: develop a testgame / testproject parallel to the engine-development. Hopefully this will increase the functionality of future developments.
In the ZFXCE we moved from subversion to git. So a lot of you may be ask why we did this. The reasons are simple: using a decentral versioncontrol like GIT you don’t have a single point of failue. And using GIT the merge of branches back to the mainbranch is much more easier than using subversion. If you already made some experimences with that you know what I mean.
And git is much faster than subversion. Currently I am using GIT under windows with the GIT package and with tortoise-git to make thinks easier and it works fine for me.
Of course we had to learn new things. But in my opinion learning somethink new isn’t so bad at all.
If you have to deal with .NET stuff and you want to generate a doxygen docu because the code is only a separate component of a bigger project, you have to convert the xml tags into doxygen-compliant tags. And if you are looking for you can find a lot of similar issues like integrating python docu into a doxygen format. Fortunately some clever guys already solute this issues. Take a look to the following URL:
Doxygen extentions
It is possible to extend the doxygen parser. Or you can use a preprocessor to convert your tags into doxygen.
After a half year of discussing, many many debug sessions and redesigns of the basic ZFXCE obj loader from my side we have finished our development activities on the first version of ASSIMP. And so we were able to release the first beta version. At this Moment we are able to load a lot of different file formats like MD2, MD3, X, 3DS, Obj and many many more. The loaded data could be postprocessed with a configurable setting of postprocessing steps for retriangulate the meshes or recomputate the normal vectors for instance. We are also supporting a basic datastructure validator to make shure, that the loaders are working correctly.
If you want to see what we have done just open the project page on sourceforge: ASSIMP project Page.You can build it using windows and GNU-linux. We are using the BSD-licence. So feel free to take a look onto our work and adapt it to your frameworks.
A very nice gimmick is the ASSIMP-viewer, which Aramis has developed on its own to make it much more easier to see, thats something went wrong in the loaded data structure. Currently it just works using windows because it is using D3D9.
I detected some useful debugging stuff by debugging windows applications. I debugged some memory issues and searched for some useful tools which may be helpful. I detected the site http://www.dumpanalysis.org/blog/index.php/crash-dump-analysis-patterns/.
The author of this site is using a tool called WinDbg.exe, which is a very useful and powerful application to dig deeper into the fundamental mechanism of your applications and the windows kernel in common. After the setup of WinDbg with the right symbol pathes you can learn a lot over the bugs in your code. And the crash-dump-analysis-pattern are a very useful help to find the critical mistace I made.
I have started to debug the octree-implementation of the ZFXCE. Currently I am working on the testcase. If you want to take a look onto the implementations, follow the link:
http://zfxce.svn.sourceforge.net/viewvc/zfxce/trunk/ZFXC-Engine/include/Geometry/ceTOcTree.h?view=markup
Best regards
Kimmi
After a long period of time I was able to add a new entry in my developer blog. In the last months I worked on a prototype for an octree. Expected in the next weeks I will keep him work. And the ZFX-community-engine has a new scenenode: a lightscenenode. You can use this node to place dynamic light sources into your scene. At this moment we supporting only point and ambient light. But in the future I will upgrade the light implementation by a directional light source.
And I have fixed a lot of bugs and compiler warnings. I am trying to decouble the several modules of the different system-components in the ZFXCE. The future will show me, if its works.
To enshure a correct functionality I have added a lot of new testsuites, too.
Salacryl has added his Serialize module to load differnt file formats like images, meshes, models, level etc. .At this moment the module supports no features, its only a reprasentation for the underlying design. At this moment we have started with the implementations.
I have fixed a problem of the linux model loader. If the material description use different path separators than the os specific one, the loading process to get a valid texture iinstance failed. This hsould be fixed.
I have started to solve some performance problems in the obj-loader.
I have add the test suite to our scons build. Now it will create an application names testingd, which starts all hard coded tests. It is also possible to start the ZFXCE in a debugger (only tested under linux Debian etch).
Best regards
Kimmi