Green - Day 2
2013-03-16
Today I started molding Ogre and OIS into my proposed architecture. As always the graphic and input systems are slightly interwoven. This is the way that operating system handles input, over it's windows. The only recourse would be to implement a "window" or OS abstraction system, but that is not feasible, because any OS abstraction is done in the OGRE and OIS libraries.
What I don't get with the design of OGRE and OIS how the library is packaged. OIS for example is mostly useless on it's own. You need to create a window in the OS specific way to get input abstraction; but once I created the window, the input handling is almost nothing. On the other hand OGRE creates a window in an OS independent way, but does (almost) not implement any input handling. In addition the window creation deeply integrated into the library.
This is why I like the SDL / OpenGL divide. SDL provides the OS abstraction and OpenGL the rendering facility. Yes, comparing OpenGL and Ogre is comparing apples and oranges, but this divide makes total sense. You can use OpenGL without SDL and SDL without OpenGL, this is sensible packaging.
OgreBullet
2013-03-14
I am looking into using OGRE and Bullet for my little project and while I was browsing through the OGRE Wiki, I stumbled over OgreBullet. So my reaction, was "interesting". I knew that anything of this matter would not work into my proposed architecture, since it mixes two systems I want to separate. Nevertheless I looked into it.
And it is what I thought it was. It is what you get when someone says "Let us add physics to out small graphics demo!" and then heads to code something up without further though.
But this naive approach is common in hobby game development circles. It stems from the fact that the first thing you get from a game is it's graphics. As a result developers start on the graphics first and then start weaving other elements, such as sound, AI and physics into the graphic code. Unfortunately it takes allot of unlearning to realise that the proper way go is to think about and build the model code first and then wrap the presentation layers around it.
Fun fact, if you look into the OGRE wiki, you will find similar gems, like OgreAL, OgreSocks and OgreMP. What good does a graphic library do with a Berkley socket layer? And no, it is not multi system rendering, which would be arguably cool. I get extensions that meaningfully extend OGRE like Hikari, OgreSpeedTree, Berkelium or Particle Universe plugin, but the mere existence of these odd libraries is insane.
Green - Day 1
2013-03-12
Today I worked through half of the basic tutorial track of OGRE. Yes OGRE still has odd architechtural decisions built in. What rubbs me the wrong way is that on the one hand they try to work in the problem domain and hide implementation details, which is very good inded, but on the other hand in many places you are forced to make decisions about implementation details. I don't mind implementation details and working in the solution domain, but it is either problem domain or solution domain not a little bit of both.
Part of getting ready for the turorials, you need to go though the setting up process. Even though I know how to get Visual Studio to build and link against third party libraries, that level of hand holding felt good. At least the tutorial writers know what they do. The only odd bit is that they want you to copy the executable to the OGRE bin directory. This may be a nice convivinece for tutorials sake, but it ought to go the other way around, copy the dependencies into the project. I worked with the compromise that I just changed the working directory to the OGRE directory.
Project Green
2013-03-11
I will state this publicly here, because things I state publicly, I have a tendency to see though to the end. Since I am rather plagued by the not invented here symptom, I will force, yes force myself to use third party libraries. And finally, I will document my progress here in my little nifty web journal.
Assignment:
Write a board game simulation, similar to Desperate Gods, using mostly third party libraries.
I decided to look into the mature collection of open source libraries:
(Isn't it odd how they always come up together.)
For starters I will develop for Windows (32bit) with Visual Studio 2010 and you can see the code over at the green github repository.
GLSL Skybox
2013-03-07
Anybody can load six textures and render a cube to create a skybox. How about rendering a skybox with exactly one quad? I tried just that in an example to my ice library. And it looks awesome!
But since few juicy bits are hidden in the library I will untangle them and explain them. The process is quite simple, but I have not seen many tutorials on the subject. The best I found was the tutorial by Keith Lantz but he still uses a cube to render the cubemap.
Lara Croft Trailer
2013-03-01
I must admit that I never was a big fan of lara croft, nevertheless this trailer is great in so many ways.
First this trailer is well directed, it is gripping, moving and intriging. But this is not so suprising, since the art of reating movie and game trailers should be well understood by now.
Second the trailer uses large ammounts of gameplay footage, even thoug it is rather cinematic in nature. You must give it to them, few cinematic game trailers are actual gameplay nowadays. The only gameplay you get to see are guided demo sequences, that verge on borderline boring.
Third the narators of the trailer, that are suposed to be players, are all adults of varies ages, race and sex. What I really like about it is that whoever made the trailer gets his target demografic, games are played by a number of adults. This makes especially sense since if a fan played Tomb Raider in 1996, they must be into thier 30s by now.
Experimenting with GYP
2013-02-07
I am working again on a game project, think solid only better. My development targets are first and foremost Windows, then GNU/Linux and finally Mac OS X. Building portable code is relatively easy, if you stand on the shoulders of giants like libSDL or libuv. In all my code I have only one #ifdef for the location where savegames and the configuration is stored; all else is abstracted by libSDL and libuv.
Keeping the build system portable is a different story. I have been an avid proponent of GCC and its Windows offspring MinGW. I still think they are the superior tool chain. But when third party libraries are involved, it becomes more and more a resource drag. The problem is simple, for Windows you will always get the MSC ("Visual Studio") builds or MSBuild definitions, but seldom one compatible for MinGW. Technically all you need is a Makefile, as you would use for GNU/Linux, but with all the sources and preprocessor flags set for windows and that is rare.
As a result I have started using Visual Studio again. Somehow it makes sense to use the "native" tool chain to build something, than to monkey one from a different platform. Now this creates a new problem, I start to have multiple build definitions to maintain. But why can't I generate the native build definitions from a master build definition? And there comes GYP to the rescue. (No, I am not even going to think about touching CMake.)
The Most Important Feature of DSCM
2013-01-15
Distributed Source Code Management (DSCM), such as git or mercurial have changed how software development projects are structured. But there is one feature that really changed the game for free software.
It is not that contributing changes are really easy. With distributed source code management patches are a thing of the past, you merge changes into your workspace, like it was a branch. This makes it fully clear from which revision the change comes and it significantly reduces the chance of conflicts. But that is not it.
It is not that every developer has a full repository. If you want to contribute to a project your get your own repository, just for you. You can try things out, revert and alter as you like. Having full source control management features at your disposal is important, especially if you only want to contribute small piece of your alterations. But that is not it.
It is not that users can easily stay in sync with the repository. It depends on your needs, but some users prefer a stable build and need to be at the bleeding edge of development. Instead of grabbing a tar ball and copying the files, the user can create a tracking repository. Now with minimal effort he can track the latest changes or any stable branch. Even going from stable version to stable version with local modifications is assisted through the tool. But that is not it.
In my opinion the most valuable feature of distributed source code management is that anyone can fork a project. There is much useful software out there, unfortunately many of it is not actively maintained. Before, you had to export the repository, if you had read access and import it into a new repository. This can be a long process and can potentially loose history. With a distributed source code management you just create a clone and are ready to continue. Even when development restarts on by the original authors merging the changes together are fairly simple, since the history was never corrupted.
Comments? Comments! Comments?
2012-11-18
I am torn on the subject of comments. At first I had comments on posts, simply because that is what everybody did. But in the early days of my journal I did not see the point, since all comments I got where spam. When I switched to Jekyll and used Disqus for comments, the spam went away; the volume of ham (good comments) kept the same, almost none. At which point I removed the comments completely.
The State of SourceForge
2012-11-15
Where would the free software movement be without SourceForge? SourceForge is part of the foundation stone of the free software movement, it importance rivals the Free Software Foundation (FSF). Where FSF provided ideology SourceForge provided infrastructure. (Did anybody actually use Savannah?)
But in recent years SourceForge has lost in relevance, because of how rigid it operates and many projects moved to github. Likewise the FSF lost on relevance, people do not care that much about ideology, they want to get a job done and free software / open source one tool of many. Github is great, because they do not care if your project is properly covered by a OSI approved license and you can create a project on a whim, even private projects.
I stopped using SourceForge when I let my projects wither and die almost a decade ago. But I still have an account there and receive their monthly newsletter. I seldom really read the newsletter, but on a whim I read the last one. The top 20 active projects stuck me as odd.
Newer Posts Older Posts