Author Archives: Raut
trueSpace has been put down!
Well, what can you say? The once great modeler trueSpace has been killed. Some may remember it as being acquired by Microsoft, and then in what seemed to be too good to be true, was offered as a freeware not long ago. Not entirely unexpected I must say. There was nothing much being done so to say, but TS did have a sizable community who is now understandably disappointed. My first experience with TS was a long time ago, when I was taking baby steps towards learning 3D and 3D modeling. I confess I am not a 3D artist, but I work with 3D tool-chains a lot and I had to switched over to Blender rather quickly since TS back then wasn’t free. When the application was released as a freeware, I did try my hand at some of the tutorials that accompanied the installation and was pretty successful at doing things, mostly because my experience with Blender could be carried over to trueSpace in some way. True it’s interface is a bit wired, but that’s something that could have been worked on. It may not have had all the bells and whistles of the truly top modelers, but it wasn’t all that bad. It’s unfortunate that it got terminated the way it did.
There is something to think about here. Had trueSpace been open source, it would have been forked and the project would have continued to live via enthusiasts and developers, maybe even via contributions from existing developers. The unfortunate thing is — it isn’t and therefore it’s fate is sealed. It’s really sad to see such a product go down and the anguish of the community members that have helped the product grow, is justifiable. Believe me, it’s not easy to see software that you have worked with for years go down like that. 3D software, especially 3D modelers take a considerable amount of time to learn, and it takes even more time to become truly productive with them. My guess it there are going to be a lot of 3D artists that would really pissed off right now.
Now that I think back, it’s a good thing we decided to use Blender as our primary content creation tool. Not that we were going to use TS in the first place. However, had we used some closed source software like TS, we would have burned down with it if it would ever had gone TS’ way. Most of the content pipelines would have been lost, a lot of code would have to be re-engineered for another application. This has been precisely my argument from the very beginning. However popular an application may be, it could very well end up being put down to protect corporate bottom-lines of large corporations. With closed source applications, one can never discount such occurrences.
Then again, could we see a resurrection of TS in some way? I sure hope so. Maybe there will be a release of it in a new incarnation — a integrated game creation tool for XBox/PC? — OR — Are we going to see a new tool to rival Sketchup from existing codebase? Maybe there will be a community buyout? Or is Microsoft going to release TS as OSS? That would be interesting indeed! No, I am not keeping my fingers crossed.
A new OS with a new desktop.
After having used Ubuntu for about 2 and a half years now, I got kinda bored and decided it was time to try out something new. Not that this has anything to do with Ubuntu — it’s just that every 2 years or so I get this itch that has to be scratched. It usually leads to a complete overhaul of one or more OSes on my machine. In a way it’s good — it gets rid of a lot of crud that accumulates on my hard-drivers over time. However, it also means I have to put in hours of work to get the new OS up to speed. Fortunately these days the Internet connections are pretty good and most OSes come with one click installers for commonly used software. There was a time not too long ago when every utility had to be downloaded, compiled and then installed. It would take days before you could get an OS up and running the way you wanted. I am glad that isn’t the case today.
I wanted to try something different. The Linux world has a lot of distros and though each one has it’s own special flavour (and many of them are really good) , it’s still Linux. There is a world of *NIX and *NIX-like systems that haven’t been too successful on the desktop — up until now (don’t know what the future holds). However, there are some sincere efforts being made to get these OSes on the desktop as well. One of them is PC-BSD, a FreeBSD based distro that has been customized for the desktop user. I decided to give it a shot given that it has had some good reviews.
The installation of the OS is painless — a standard graphical installation that will be too familiar to most users. Be careful though, the partition naming is a bit different from Linux! I had some anxious moments there, but as soon as that was sorted out, the rest of the procedure is pretty straightforward. The installation bundles some of the most commonly used software. Firefox, OpenOffice, Pidgen are all there. The desktop is based on KDE 4, which I must say, is my first experience with KDE 4. All installed applications worked pretty well and on the whole PC-BSD is usable system. Connecting to the Internet was pretty easy, maybe because I already knew how to setup a PPPoE connection under my former Linux system. Nevertheless, the basic OS was up and running within about 45 mins. The great thing about this distro is, most of my movies and videos work straight out-of-the-box, which thus far no distro has been able to achieve. Even with Ubuntu I have always had to download codecs for most proprietary formats (like wmv). That’s a strong plus for this distro. There is a click and install system called PBI for most commonly used software and it is similar to apt based system under Debian distributions. Most other software can be downloaded via FreeBSD ports and works pretty well. The system has an auto-update feature that updates the system components regularly and with ease.
The only real problem I had was not with the OS itself, but with KDE 4. KDE 4 is a bit on the sluggish side and that’s putting it mildly. Maybe it was just my case since I used a PC with only 1 GB Ram, I don’t know, but the same system flies under a default Ubuntu distribution. Another thing worth mentioning is the size of the install. The system took about 7Gb of disk-space for just a handful of software. Even the PBI updates seem to be on the heavier side than their Linux counterparts. Looks like most software packages are either statically linked or the system bundle separate copies of shared libraries for every software. Disk-space however, is cheap and you could live with larger installs given that nothing gets broken because of a missing shared library — overwritten by another install, or removed by an uninstall of some other unrelated software.
On the whole PC-BSD is a commendable effort. I have been using the system for about a month now and the only real thing that bugs me is the sluggishness of KDE 4 (which I am sure will get sorted out as KDE 4 matures). FreeBSD is a good OS and a desktop distros based on it was a long time coming. I hope PC-BSD and other FreeBSD distros gain more popularity as time passes.
Nostalgia
Last night I was clearing the hard-dive to free up much needed space and I happen to run across an old zip file and in it was my older experimental engine — something I was working on long before I began work on the O2 Game engine. Well you can’t really call it an engine — it’s what you call; a bunch of experimental code hacked, stretched, hammered and stitched together to produce something that can be displayed on the screen 😀 . A more appropriate name would be a prototype or a demo. I was looking at the code and couldn’t help but wonder how I could comprehend anything inside those bunch of lines back then. To my surprise, the code still complied pretty easily on the new VC 8.0 Express. The app runs at 500+ FPS on the HD 4850 at 1280×1024, back then (, if I remember correctly) it ran at 40-50 FPS on a Riva TnT at 640×480.
Quake 3 Level – missing textures and shaders appear white.
Another Quake 3 Level in the prototype engine.
Cool ain’t it. Well sorta, but lets take that with a pinch of salt. First, those levels that you see are some really cool Quake 3 Levels that I had downloaded off the internet. They are not created by me. I had written up a Quake 3 Level loader for the demo and albeit incomplete, was pretty good at loading most Quake levels. The lighting was obviously Quake 3’s internal Lightmaps. The collision system was rudimentary and navigation (running around in the level) was a huge problem. There were times when the collision system would completely fail and one would fall through the floor into the dark abyss below. MD3 animation was crap, so there were no players in the level, though I remember I was working on a skeletal animation library later on, but I guess I never integrated it with this piece of code. Oh well!
Baby steps I would say. Obviously I learnt a lot from hacking around that piece of code. But could I have created a game with that? The answer is — No I would not have. With all that was achieved, you wouldn’t be able to pull together anthing more than a short cool looking demo — period! The code is too haphazardly written and has no structure and I would only term it as research and learning material. Even then it’s a bit nostalgic to see some of your old code run 🙂 , and man it still does look cool at higher resolutions!
Please post your comments in English.
Over the years I have had some comments in languages other than English. Unfortunately I have had to delete them since, a) I could not understand them. b) I don’t have language packs for languages other than English installed on my machine. So anything posted in other languages appears as garbage.
Sorry if your comment was deleted. Try and post it in English, and I will be more than happy to reply.
Thanks.
The world of 2D.
Well as I have said in my earlier post I am currently working on some tech related to 2D gaming. Actually, working against the clock to finish the current project, which on all accounts is somewhat of a diversion from my main goal. However it has also given me time to retrospect and understand how things are in the world of 2D gaming (when compared to 3D). No, it doesn’t mean I am giving up on 3D, actually most of the tech I am using is from the O2 Game Engine, custom fitted to the 2D technology I am working on. Basically 2D is 3D with a fixed Z. People generally move from 2D to 3D but I seemed to have moved the other way around. The whole experience is kinda funny, because I can now truly appreciate how things with 2D really are.
Building quality 2D games is a lot easier than building quality 3D games. Actually creating 2D games is an order of magnitude easier than 3D, or so I have heard 😀 . Having said that, the foundations of both technologies are extremely similar. Most of the tech I have designed for 2D is almost a reflection of the O2 Engine. True, it is not as complicated as the 3D engine, but majority of the higher level design is similar to what was already put into the main 3D engine. I had initially decided to use the 3D engine as is, but the O2 engine is just far too complex for 2D. There were too many things that didn’t feel right for simple 2D. So it made sense to use an already existing third party 2D engine and parts of the O2 game engine to build the higher level framework that was missing. Simplicity was the deciding factor, since the primary focus of the tech is quick 2D game development and prototyping.
The second and most compelling reason was time. The project has be finished quickly in a matter of weeks so majority of the focus has been on using and integrating already existing tools and libraries. The project on the whole is simple, but it has a complex UI and involves integration of a lot of libraries with a lot of functionality exposed via the UI, making the game builder UI the major challenge (more than the engine and the tech).
The project is still very much under development. I will post some screens and more details as soon as we hit alpha stages.
New Project.
I was a bit hush hush about my current activities, but I guess it’s OK to talk about it now that the project has been put on track. I am not revealing too many details as yet, but I can tell you what it is going to be. Well it’s actually a smaller project considering the my previous one (Doofus Longears – The game), lot easier in complexity and pretty small in size. Yes, it is related to games and gaming and involves a game, but it’s not a 3D project — it is 2D. Well it is 3D under the hood since it is based on Direct3D but it rarely uses the third dimension so it’s not 3D per say. The entire project involves creation of a game, which I must say is pretty trivial, but more than that it involves the creation of a generic game builder software, the work for which is already under way. The name of the entire thing is still under wraps, but you should see it come out in later entries.
The engine is an already written, accomplished 2D engine — no I am not writing the engine this time. The major job is to create an elaborate game builder (GUI), a designer, a scripting engine (Lua in this case) on top of the engine and integration of the engine and the scripting system into the game builder and designer. The game will be built on top of the scripting engine and should be pretty simple to make once the game builder and the scripting systems are in place and properly integrated. The game builder is designed to be generic enough to make any kind of 2D game (arcade, adventure, platformer, puzzle,…)
So — Yes, I am taking a holiday from our engine for a while, I hope only for a little while. I have been up to some interesting R&D which I hope I can integrated into the O2 Engine soon. It’s been a long time since I worked on a 2D game, almost 7 years now since I wrote a 2D pacman clone. The game had 3 levels and crappy graphics, makes me laugh looking at it now. But hey — that’s how you learn.
As it stands today, a fair amount of progress has been made on the GUI side of things. A lot still remains to be done with integration, but 2D games are lot simpler than 3D ones so I hope and can tide over this project pretty soon. More details about the project and the game builder will be out in due course. I will post some screens of game builder when the game engine is integrated and there is at least a semblance of a game running inside it.
Credit Crisis.
My initial years in software development were spent writing software for trading, stock markets, cash markets, futures, derivatives trading — mostly for trading houses, brokers and in general for the finance industry. You could say that I have at least some knowledge of how financial markets work. In the same breath I can assure you I am no expert in the workings of the finance industry, but I am not totally clueless as to what’s going on either. However, many of my colleagues and friends from software development backgrounds are clueless of the exact nature of the current credit crisis that has, what some have equated to being a “financial tsunami” to have hit the world.
If you are one of those who doesn’t have a clue of what’s going on and why people are hysterical, or wonder why a housing crisis in the US is going to make you living 10,000 miles away homeless, this is probably the best explanation I have yet to come across.
I would sincerely suggest you take a look at it.
Time away
I have been away from blogging for a while now (I know, I’m sorry) and I really feel that I have neglected the blog for the past couple of months, but on the whole it’s been a slow January and a rather boring February. I have also been taking breaks from my daily routine, not too many, but on the whole I have been rather sluggish for the pas t 2 months. I guess it’s an unfortunate consequence of being stuck to a chair for 6 odd months and being generally devoid of and other life 😀 ! I had decided to go somewhere and relax for sometime, but I haven’t yet found any time to do that. Thus far it’s been only small weekends of relaxation. Unfortunately I haven’t been able to take the “big vacation” I had been planning for (yet), but I guess I will get around to it one of these days.
Besides all that there have been some projects I had been holding out till I had released the game and I finally got around to having a go at them. However the major chunk of my time is currently being spent on R&D, and that’s probably something I love doing. Trying out crazy stuff, hacking around code in the most insane ways possible, trying out crazy stuff with shaders, pulling and pushing DirectX, NVIDIA, ATI samples. Yeah! All that kind of stuff one likes to do 😀 . It’s really fun to see how far your card will go (in my case the HD 4850) and I can tell you the 4850 has a lot of punch if you know how to tweak it.
Well, this entry is a no brainier, but then again I haven’t been doing a lot of brain activity recently 😀 , so this entry probably reflects that 😉 . Don’t worry I will be back to myself in no time…
Going data-driven.
As you probably already know, the first Doofus game was released a few weeks back, and though I haven’t fully shaken off the lethargic hangover that accompanied the game release; I am slowly coercing myself to get back to daily chores. After every project one must look back and take a note of hits and misses of the project development cycle (Causal Analysis). That’s what I have been doing for the past few days, and though there have been lots of those (hits and misses), one of the important lesson I have learned from the whole experience of making the game is the importance of data-driven programming.
Most of the tedious and time consuming activities during development turned out to be simple manipulation and ordering of code. Placing scene-nodes, structuring the scene-graph, ordering render batches, grouping shadowing objects, and the list could go on. Things like these took up ridiculous amounts of time. In the game all this is done through code — when this could easily have been solved by a more data driven approach. I must admit there were times during development of the project when I yearned (almost cried) for a more flexible system. The problem was a lack of script driven programming, or should I say, a lack of a more data-driven system on top of the engine. Everything with the engine is currently done in C++, except maybe the configuration files. I hate it when you have to recompile 20-30 files just because you had to move a local variable to a class member. This does happen, especially for classes that have a long list of data variables and/or the ones that operate and integrate game data. We had initially planned on integrating a script and data-driven system into the engine, but that was later push down the priority of things to be done — and ultimately pushed out from the release due to lack of time and resources. Through not verbatim, that’s probably the story with every dev project out there that has to keep up with at least some sort of deadline.
In data-driven programming, data controls the flow of the program. Data is not just used to define an object state but also used to control the program flow, sometimes externally. Data-driven programming means writing generic code that consumes data and modifies it’s behavior depending on the structure of that data. The concept of data driven programming is not new. UNIX utilities have traditionally been data-driven and many applications use data driven designs. A web browser is a good example of a data driven application. It consumes a web page and modifies it’s behavior based on the structure of the web-page code, in this case HTML. Markups are again an excellent examples of data that encodes structure within itself (XML).
Well, there is a lot to take away from the current project. The engine will be made more data driven in the future, that’s for sure. The game also allowed me to pinpoint exact areas where a data-driven approach is needed. Many of those places wern’t immediately obvious during design.