Tuesday 17 November 2009

Further Scene Editor Progress

So as I've mentioned a few times previously, I'm working on a scene editor. The goal of which is to make it easy to produce content for the many game ideas I have :)

So far progress is slow but steady, I'm being a bit of a perfectionist so large chunks of the code have been written at least twice, sometimes three times and there are still things I'm not happy with.

I'm currently working on importing Wavefront *.obj models. I know I've got a partial obj loader somewhere, I just need to find it, and integrate it. These are the goals for the first release:

1. Load and save irrlicht scene files

2. Create, manipulate, delete cubes, spheres, meshes, lights and terrains

3. Create, edit, delete and apply materials

4. Cut, copy and paste meshes

5. Manipulate the scene tree (make parent-child relationships etc.)

At that point the editor can be used to create landscapes. The following release will add:

6. Custom entity positioning

7. Advanced object properties (invisible, transparent, etc.)

8. Skyboxes

9. Octree based culling

And then some time later:

10. Python integration

11. More file formats

Friday 6 November 2009

Criticising the Koala

So, unless you've been living under a rock for the last month or so, or you've been busy with Windows 7 launch parties, you will know that Canonical launched the latest version of Ubuntu, version 9.10 the Karmic Koala.

I spent launch day in #ubuntu-release-party along with over 1000 other people anxiously awaiting the release. I, of course, was already running 9.10, on my desktop, laptop and work desktop. I haven't had a single problem with any of them, post-beta anyway.

Still, I can't help but think that this particular release was a little rushed.

The updated boot splash is a massive improvement, and it saw a lot of work over the weeks up to the launch, but even here, there are a few niggly little issues... even now I still get an occasional worrying "Waiting to mount home" message underneath the minimalist white Ubuntu logo. The new X splash doesn't fade out properly all of the time, on my home desktop it never does. The background image showed visible banding on my highest resolution monitor, although this seems to have been rectified now. Also, I haven't seen a disk check in a little while, but the last time I saw it - it was scrolling past each percentage point. All these things show a lack of polish that I'm fairly sure an extra weeks development would have solved. Before anyone asks, yes I checked these bugs were reported.

I'm actually pretty impressed with the log on screen, of all of the artwork I'd say GDM and the white Ubuntu logo on shutdown were the parts where I actually thought to myself - yes this can compete with OSX. That said, I did feel there were better background choices on the Ubuntu wiki, and I do understand when users say it feels cold... because.. well it does, it's hardly sunshine and flowers is it?

Now, after log in is where everything falls apart. The introduction of the Humanity icon set was a step forward, but whoever decided that a bright orange background would look good with the new boot splash was frankly off their head. Why didn't they just use the same background as the GDM? Yes it's still dull and brown, but at least it would have been consistent.

The GTK theme changes were just a mess, the window borders have changed to a dark muddy brown, the previous Human colours at least would have matched the orange background slightly... the whole desktop theme seemed like a last minute rush because all the time had been spent on boot. Again, a week longer and we could have had that extra polish that Ubuntu deserves.

Still, this is just the beginning of the design work, hopefully 10.04 will get this stuff sorted once and for all.

Generally speaking, functionally Karmic is running well for me. My ATI based desktop still has slow minimising when Compiz is enabled, I really hope this is fixed soon as it makes the whole desktop feel sluggish. I've grown accustomed to the way that notifications are displayed, however I still believe that positioning them at the bottom of the screen would get in the way even less, and I stand by my feeling that the position should be configurable, because no matter where the notifications are, they will get in the way of some application that a user regularly uses.

Pulseaudio has really improved this release, I haven't had a single sound issue so far, however it does sadden me that Ubuntu still aren't paying attention to upstream (e.g. the removal of rtkit) although I've heard there is more communication going on now.

Empathy. If there was one thing I would say was a complete bloody mess in 9.10 it is the premature replacement of Pidgin with Empathy. I know that Empathy is the future, but that future is not here yet. Empathy is still buggy, it looks like a mid 90's throwback and it still lacks the many features that Pidgin offers. I don't understand why there was such a rush to replace Pidgin before Empathy was ready? Still it's easy to swap it out for Pidgin so I guess I can't complain too much.

The indicator applet is nice, although I do wonder why I can launch applications there when there is a perfectly good applications menu. I thought introducing more than one way to do something was bad from a usability POV? It makes the whole point of the applet ambiguous. Leave the launching of applications to the applications menu, and leave the indicator applet to well, indicating notifications.

The Software Centre is a massive improvement over Add/Remove, I do wonder whose idea it was to give it a blue background though. So now we have black, white, brown, orange and blue. Talk about consistency! I thought Mark employed a design team! I also still don't agree with the "Close" menu option though, it should definitely be "Quit" IMO and I don't buy the excuse I was given on the bug report. "The Ubuntu Software Store has no need to require users to know whether it is "running" or not"... what? Course they do... they opened the bloody thing.

So lots of little issues, I'll continue running 9.10 but I don't feel that this was Ubuntu's best release (9.04 was) but there have been a lot of changes (new GDM, GRUB 2, Xsplash etc.) that will hopefully mature over the next 6 months to form a solid base for 10.04, being an LTS, this is the release to watch.

Monday 12 October 2009

Scene editor progress...

So, I've decided to focus my spare time on a couple of projects rather than continually fiddling and investigating the source code with a myriad of OSS projects (Wine, notify-osd, ATI Linux drivers, etc. etc.) I've set myself an end goal: to write a decent 2.5D platform game.

There has been this idea for a game on my mind for some time (and I've blogged about it previously). I know how it's going to work, I know what/who the main character will be, I've thought about all the intricate details of the gameplay. So now, it's time to actually get coding on it. I decided to use Irrlicht as the graphics engine, but (as I've mentioned before) it wasn't long before I hit a little road block. Irrlicht's main scene editor is IrrEdit - a Windows-only closed source editor which unfortunately doesn't run under Wine. I did look at patching Wine, but it's not a trivial fix.

There are other methods of content generation for Irrlicht; Blender, Deled etc. But Blender was more complicated than I liked, and Deled suffers the same problems as IrrEdit.

So, I decided to brush off a project of mine that had stagnated a bit; my scene editor - Kazscene.

Previously I'd written it using wxWidgets, but I suffered quite a few issues with wx's GL canvas widget. So I ported it to Gtk+ and used GtkGlExt which is working like a charm, using Glade as a UI editor is awesome too and the whole application seems snappier in comparison to the wxWidgets version.

So, porting took quite a bit of time, but since I've focused on writing a lot of the underlying infrastructure, (re)organizing the code and coding features. At the current state the application is still essentially useless (it doesn't load or save yet). But at the moment it has the following:
  • A scene graph
  • Terrain generation from a heightmap
  • Cube creation
  • Rotation and translation of objects (still buggy)
  • Selection, mouse-over highlighting
  • A virtual file system (allows reading from directories or zip files, with help from PhysicsFS)
  • Smooth and flat normal generation
What I'm working on at the moment:
  • A texture manager and material editor
  • Python interpreter integration (using boost::python)
  • Ogre and Irrlicht file loading/saving
Here's a screenshot:

It's getting there, once I get material editing and scene loading working, it'll look more impressive :D

Monday 21 September 2009

When will the music industry get it?

So the illegal file sharing debate is continuing to rage on and I guess really I just wanted to throw my opinion out there, because unfortunately the industry still doesn't understand. They don't understand the technology, they don't understand what's at risk and they obviously don't even understand their audience.

Let's get the first most important myth out of the way. A shared file is NOT a lost sale. How any one can believe that's the case baffles me. If an artist has a good album, I will go out and buy it, probably physically on a CD, then at least I have something to show for it, or perhaps from Amazon on MP3. Now, if I'm at work, and my newly bought album is sitting at home, I will feel no guilt WHAT SO EVER about downloading it over bitorrent, I've paid my money to those concerned. Of course that's not the only situation, some people will just sit at home downloading the tracks from bitorrent and not buying anything, but wait, file sharers actually buy MORE music than non-filesharers. Granted, there will be a minority that don't pay, but those people can't copy the experience of a live GIG can they? Which brings me to my next point. File sharing is the single best method of promotion out there!

The Internet has presented right at the feet of the artists is a network of free advertising. Leak a track onto bitorrent and EVERYONE will be talking about it and the majority of those people will then go and buy the album. New artists can build a following on file sharing sites that will attract people to their gigs and to buy their merchandise. Lily Allen, an artist I have a massive amount of respect for, who built her career from MySpace, apparently can't even see that file sharing is essentially the same thing: a free method of advertising. 50 Cent gets it, hopefully more artists will aswell.

Now let's get to the important issues. The technical side of this, imagine the Internet as a massive postal service, except literally millions and millions of letters are sent EVERY SINGLE SECOND all around the world. These letters are known technically as "packets" of data. There is no way on Earth that anyone can do all of the following:

a.) Monitor all this traffic
b.) Determine which traffic is file sharing
c.) Determine that said file sharing is illegal

Torrents are used for many many legitimate causes, including software distribution, free music, videos, and images, etc. blanket banning it would be like banning all phone calls because you might insult someone. Even if it is possible, you really want someone snooping all your emails and messages? If illegal filesharing in it's current form is stopped, then everything will just move to encrypted methods, there will ALWAYS be a way.

The real problem is this, the music industry is broken. The music industry needs to adapt to changes in technology just like everyone else, they can't just sit there trying to force through legislation that makes 1 in 10 people a criminal just so they don't have to change their business model. Recordable cassettes didn't kill the industry, file sharing won't either. The only thing that will kill the music industry is itself.

Friday 14 August 2009

Why name prefixes are evil

Many programmers and database admins seem to prefix their variables or table names with a few letters to indicate the type of the entity. For example, for some reason unknown to me, most of the databases I have come across have "tbl" prefixed to every table name, and even worse I've seen "fld" (for field) prefixed to every column!

In a time where every database has a set of GUI tools to view them, which conveniently groups tables, views, stored procedures with their own icons... what benefit does this naming bring? To me it only seems to bring problems, I'll give you an example.

Where I work we inherited a set of legacy databases to build a new web application on top of, the old website needed to continue to function. We decided to reorganize the databases to make them easier to maintain. To remain backwards compatible with the legacy website, we created views to the actual tables to mimic the old design. Here is the problem, the views are now named "tblXYZ" instead of "vwXYZ", an annoyance, making the already pointless prefix naming, now down right counter intuitive. The only way to change this situation is to go back and change all the code that accesses the table and rename the views. A long, and potentially bug inducing process.

It's even worse with variable naming, if at some point down the line, you decide that your intVariable needs to become a fltVariable you need to go through an rename every occurrence of the damn thing, what advantage does that naming bring in either statically or dynamically typed languages?

Don't prefix names based on types. By all means prefix to prevent name clashes (member variable vs local variable) but prefixing based on a type is more hassle than its worth.

Thursday 6 August 2009

Am I just patching over the cracks?

So, my last blog post got a fair bit more notice than I intended. I actually didn't think anybody read this blog except my Twitter/Facebook/IM contacts so I was totally (surprised|amazed|horrified) to find the post on the front page of Reddit and posted to wine-devel and on numerous Linux and Open Source websites. On reflection, I did write that post in a particularly bad mood so perhaps the wording could have come across slightly more inflammatory than intended. Still, on the sites I visited, I only saw one comment that proclaimed I was an idiot, many comments of the "OK, perhaps the Wine the process isn't quite perfect" nature and some saying they enjoyed my writing... I should post in a bad mood more often! Some good has actually come from my post in the form of this wiki page, which I think is a great idea!

Anyway, in the post I stated I am going to write a web-app to display patches that may have fallen into the black hole; rejected with or without feedback and then never resubmitted. I've started it, it's more tricky than I thought (matching patches is going to be a headache) but as soon as it's ready I'll post a link here.

However, I've been thinking that maybe I'm tackling this back-to-front and looking at the comments, others seem to agree.

At work, we use Redmine as our issue tracker. It is, just pure awesome. It's like Trac but better, it allows for multiple "trackers" so, bug trackers, feature trackers, support trackers and.. you guessed it PATCH TRACKERS! It also supports GIT integration, news posting, milestones/roadmap, multiple projects, wikis and forums. Wait a second, that's ALL the stuff that Wine needs!!

Wine uses Bugzilla as its bug tracker, something else for its wiki, patches are sent via mailing lists, milestones are kept track of by Bugzilla tags, and the forum is another piece of software. But if it was all integrated that would be really cool, in a bug report you can link directly to a file under version control, you can link to a revision where the bug was fixed and see the change, you can link between the wiki, the tracker issues and the VCS. Emails could be sent to wine-patches when a patch is submitted through the patch tracker. Also with the ability to plan an actual roadmap of releases the frequency of stable releases could be increased.

Obviously, migrating everything would be a massive undertaking and, it probably wouldn't be the best way to go. The Wine devs rely on mailing lists to do their day-to-day work, so any move to something like Redmine would need to be able to keep with their workflow. Like I said, the patch tracker could be configured to send emails to wine-patches... but I don't know if someone's reply to the email can make it back into the tracker. Also the wine-users forum integrates with the mailing list, and the Redmine Wiki does seem more limited than Wine's current one. Sigh.

I guess if Wine was to start from a completely clean slate, then Redmine might be the way to go, but as that's not the case maybe the devs could take a step back and cherry-pick ideas from other combined bug trackers to more greatly unify their tools. I know integrating logins between all the tools is quite a high priority. Perhaps a patch tracker (e.g. a bugzilla for patches) which integrates with wine-patches should be the next step, maybe instead of retrospectively trying to find the code that has been lost, I should instead be focusing on preventing future patches going missing? Perhaps, there should be an all encompassing super tool which combines patch tracking and patchwatcher? Who knows?

Wednesday 22 July 2009

wine-patches the black hole of code?

The Problem

On Monday, I took part in the first Wine Bug Day (one of hopefully many). It was a great success, I managed to rope in some support from some friends specifically Sean and Yorik both of whom are Wine users, not Wine developers (yet!).

And it wasn't just us, there was of course Scott Ritchie who organized the thing, but also several users popped up in #winehackers asking for others to change the status of their bugs. It was all quite exciting in a weird kind of way.

It was because of this buzz of excitement that I continued my bug triaging efforts. I knew that Autocad 2008 was supposed to *almost* work, so I thought I'd download the trial and give it a spin in the latest Wine. Surprisingly it worked pretty well, once I'd installed the prerequisites using winetricks that is. The installation went smoothly but on the first load of Autocad all of the icons were black - I've seen this issue before and I knew that using a native gdiplus.dll would fix it, but of course this is a bug in Wine so I thought I'd look at little closer. Sure enough there were 2 gdiplus calls that Autocad uses which are just stubs in Wine: GdipCreateHICONFromBitmap and GdipCreateHBITMAPFromBitmap.

Now, this is where I confirmed (I kinda knew, and mentioned it in a previous blog post) that there is a real problem with sending patches to Wine. Google showed me these two links. The work has already been done before! But it's not in Wine...

I'm not criticizing the fact that these patches were rejected, even skimming over them I can see a few issues that could do with fixing before they are accepted. What I do get annoyed about is these people have spent hours of their lives developing something, they've gone through the effort of creating patches and emailing them to the wine mailing list, and the first patch didn't even get a reply! Yes, they could join #winehackers and chase for comments, yes, they could take on board the comments and resubmit, but why? They've already put in the extra effort to get the patches out there, isn't a bit unfair to expect them to jump through hoops to get the patches in to Wine? I think so.

I know how frustrating it is to get patches into Wine. In fact, of the patches I have submitted I think only one went in first time, and that was only because it was a simple addition to an existing structure. It's taken me 3 attempts to get even simple patches in, this is not encouraging for a developer looking for a project to devote their time to. Even I have just abandoned patches, simply because I couldn't be arsed to go through the loop again for a minor minor thing. So let's break down the actual problems:

  • Patches rarely receive feedback - positive or negative - on the wine-patches list

  • Patches that are rejected aren't labelled as such, or publicly given a reason for why they were

  • Hundreds of patches don't get in, that just need a tweak or two, that would REALLY improve the wine experience

  • These failed patches can't easily be seen by anyone unless they know exactly what to Google for

The solution

What we need is a public notice board for these failed patches. We need a way for everyone to see why a patch was rejected and we need a central point to find these patches so they can be cleaned and resubmitted. Time permitting that's what I intend to develop, and here's how it might work.

wine-patches holds every patch that is sent externally to Wine, whether it was accepted or not. Given a month and year, we can programmatically dig out a list of all the emails that were submitted by parsing the index page at http://www.winehq.org/pipermail/wine-patches/{YEAR}-{MONTH}/thread.html - this is our master list. We can follow those links and also, in code, read the bodies of the patches. Some of them will be attachments, others will be embedded in the page. Either way, we can parse the majority of them, some emails won't have a patch attached we can strip these ones out. At this point we have a list of patches submitted, now we just need to know whether they were committed....

Fortunately, wine-cvs holds the answer. wine-cvs contains emails for every commit to the master repository. What we need to do is match the patches in our master list, to the ones in wine-cvs. If we can't find a close match then we can assume the patch never made it in. So, in theory we can generate a webpage with this information, with the possibility of devs submitting feedback against the patches so they can be cleaned up and resubmitted. We can go back pretty far in time with this, I would say at least 6-8 months back before the patches just become too old to be worth bothering with. Stay tuned...

I'd just like to clarify some things. Firstly, I'm not attacking Wine here I'm just pointing out that there is code that slips through the net on wine-patches that could be cleaned up and resubmitted if there was a central point to find these patches and a means to find out what was wrong with them. I'm not just aimlessly moaning either, I've stated that I hope to develop a web app to do just that.

Secondly, I have contributed to Wine A LOT over the last couple of years; submitting patches, application tests, contributing to discussions on wine-devel and aiding developers and community members like Thunderbird, Stefand and Yokozar with their contributions, and I hope to continue to do so. I am not new to Wine development.

Thursday 16 July 2009

2010 - The Year of Linux on the Desktop?

Every year for at least the last decade has been jokingly associated with being the "year of the Linux desktop". Optimism surely is strong in the Open Source world and it's only in hindsight do we realize how far short of the goal we have been. Even now, on new years day Linux geeks think to themselves, maybe this year will be the one. But of course it won't be, I mean, for a start to have a "year of Linux on the desktop" (YOLOTD) you need to actually quantify what that means.

The year of Linux on my desktop was back in 2005, when I installed Ubuntu Breezy and never looked back. But obviously that's not what the YOLOTD actually means, what it means is the year that a large percentage of desktops run a Linux based operating system. But what percentage? I guess enough to be noticed. Enough that the big developers start writing software for Linux because the audience they would be missing out on is just too large to ignore.

It's widely circulated that OSX market share is around 10% yet most developers are still developing for Windows only, with only certain products making it to the Mac desktop. That seems to imply that Linux needs more than that. I'd hazard a guess that Linux and OSX market share combined would need to hit 20% before people start really taking notice. At that point if you develop only for Windows, you are ignoring 1 in 5 potential customers.

If you were a developer in that situation, what would you do next? If you were smart you'd see which had the next highest market share after Windows and port to that platform. Aha, so to actually get a YOLOTD we don't need to compete with Windows, we need to compete with OSX. If Linux can get a higher market share on the desktop than Mac, then two things happen:

  1. The magical 20% margin for non-Windows desktops is broken

  2. Linux becomes the next target for developers

Nobody knows what Linux desktop market share is, I've heard figures vary from 1% to 8%, but for now, let's stick with a conservative 2%. So Linux desktops need an 8% increase to even "start" the YOLOTD. I believe that this will happen before the end of 2010 and here's my reasoning...

Ubuntu has become the largest desktop Linux distro in the world in a very short time. Each release adding more and more features, many for technical reasons (improved X server, Pulseaudio, automatic proprietary driver installation) but still many new users see it as too complicated, or confusing. But the last release of Ubuntu - somthing changed. A new feature was added which wasn't technical in nature, it wasn't to get something working, it was to make the experience more pleasant - the notification system.

The new notification system in Jaunty has set the ball rolling. Already for the Karmic release cycle we've already seen the 100 Paper Cuts project which in the first month or so has made real changes. The notification system is seeing lots of commits, the DX team is organized and getting work done, Canonical seem to actually have a plan. They definitely seem to be focused on a goal, and reading between the lines of Mark Shuttleworth's interviews that goal is set for completion in 10.10. A new sleek desktop that will just be pure class from boot onwards. If slicker than Mac doesn't win audience I don't know what will.

Then there is ChromeOS, Google's entry to the OS market, due out next year. Google has a habit of excelling in every venture - Picasa, Google Earth, Desktop Search, Android, Gmail I can't see this trend changing. ChromeOS will be based on Linux, so yes it counts and with Google's brand power, I believe they'll easily win 1-2% of the desktop market within a year, albeit likely via Netbooks.

Now, Linux's debut in the Netbook market was completely sabotaged by the limited crappy Xandros based OS of the eeePC which inevitably resulted in even worse copycat distros from other manufacturers meaning that by the time Ubuntu Netbook Remix came along, the Linux Netbook world was a barren wasteland with XP sitting over the bridge in green fields of victory. Things will change though, there is a place where Windows just can't go: ARM.

ARM Netbooks with long battery life and good performance will be out over the next year, with ChromeOS and UNR splitting the marketshare between them.

So here's my prediction; 2010 will be the YOLOTD, 2011 cementing it. Hopefully by 2012 balance will restored to the IT industry. It's good to be optimistic :)

Wednesday 15 July 2009

Thoughts on Wine's development model...

Scott Ritchie has just blogged about the need for a new Wine stable release. Everything he says in the post, of course, makes perfect sense. Both distributions and the Wine project itself would benefit from a new stable release. But I think the lack of releases actually stems from a more fundamental problem with Wine's development model as a whole.

The Wine repository gatekeeper is Alexandre Julliard, who is notoriously strict about the quality of the patches he accepts. To contribute code to Wine, you should mail a patch to the wine-patches mailing list, AJ and other developers watching the list will check your patches and give you lengthy feedback about how to improve your patch if it is not accepted. At least, I think that's the idea behind wine-patches. In reality, if your patch is rejected or accepted, you likely won't be notified at all. There only seem to be two ways to get feedback, firstly, if your patch happens to wonder onto the turf of a Wine developer (e.g. a subsystem they maintain), then you may get feedback from them, alternatively you can wait a day or two then pester AJ on #winehackers for feedback. The most common outcome if your patch is rejected though is that it disappears into they abyss of the wine-patches archives for an eternity of bit-rotting. This is a real shame, I would hazard a guess that 60% of patches which hit wine-patches are almost right and just need minor fixes, but are rejected. And I guesstimate 50% of those patches are never ever resubmitted and just disappear.

I believe the reason that it is so difficult to get patches into Wine is that there is NO development branch. OK, theoretically there is the 1.0.x branch which is stable and the 1.1.x branch which isn't, but releases are so rare that the stable branch is obsolete and the development branch is the branch you are supposed to use.

This leads to major problems aside from those mentioned in Scott's blog post. One of these such problems is the inability to make any major structural change to Wine.

As an example, recently a guy called Max spent time writing a DIB engine. DIB handling in Wine is quite slow, and the DIB engine is supposed to rectify that situation. Despite Max writing a working DIB engine which passed the Wine tests and showed speed improvements in several apps it was not accepted, the reasoning for which is quite sound; the design was wrong. But why was the design wrong? Why did Max spend ages writing something which he knew would never be accepted? Because to implement it properly would cause mass breakage because it required fundamental changes to Wine (specifically gdi32.dll). AJ won't accept patches which cause mass breakage because the development branch is essentially the ONLY branch.

Here's the catch 22. Wine needs regular releases to allow for big structural changes and Wine doesn't have regular releases because the criteria for the next regular release require big structural changes.

What's the solution? I think the best solution is to right now create a stable branch from the development branch. For the next 6 months, stablize that branch, add no new features just bug fixes. In the mean time open the flood gates for massive changes and not-quite-right-but-nearly-there patches into the development branch. After 6 months release a new stable version based on the stable branch and then once that release is done, sync the development branch to the stable branch to begin another 6 month stablization cycle.

This is exactly what Ubuntu does with Debian Experimental. At the start of each release cycle, sync from the unstable branch and spend 6 months stablizing it. Wine should do the same. This method has many benefits:

1. If a patch is sent that isn't quite right, then it can be accepted into the development branch anyway to be fixed up.
2. Big structural changes can happen
3. Wine development would be easier to get into, meaning more devs, meaning faster progress.

If this cycle was adopted, then some kind of semi-automated means of getting patches into wine-unstable would be nice, with AJ remaining in charge of wine-stable. I'm thinking of some website which displays the patches sent to wine-patches. Developers can vote a patch up or down and comment on it. If a patch gets 3 votes up, it automatically is committed, if it gets 3 votes down it is rejected. Wishful thinking I know, but that would be awesome ;)

Tuesday 14 July 2009

My newest project... a scene editor

So, over the last few months I've been planning an interesting 2D/3D platform game with a new camera concept, it's one of those ideas that won't go away, so I started implementing it using Irrlicht (which is a very nice engine btw) but I got stuck pretty quick when I went looking for a scene editor...

There are various ways you can generate scenes for Irrlicht, you could use Blender for example but that's overkill for me, all I want is a way to load models, place them on a heightfield and then save it. There is of course IrrEdit.. the closed, Windows only editor. Unfortunately this doesn't run under Wine, and after chatting with Stefan Dösinger one of the Wine D3D guys, it turns out, it's not easy to fix.

After Googling various methods, I thought sod it, I'll write my own. So that's what I'm doing, it's a simple, unique scene editor written in C++/OGL and wxWidgets. It's unique in that it behaves unlike any other editor I know, hopefully I'll have a preview in the next couple of weeks. The general idea is that everything is done via a single 3D view and a tree view which displays the scene graph. So far I have terrain generation (either a plain grid, or via a heightmap), object selection/hovering, a lot of underlying infrastructure and the scene tree view. Next on my list is camera movement, this is going to be particularly cool, because selecting an object will cause the camera to move so the object is focused ready for you to manipulate it. More updates to follow ;)

Oblig screenshot:

Thursday 12 March 2009

I need to update more...

OK, I'm useless at blogging. So what's happened since last time?

Well, I've written a book for a start. Beginning OpenGL Game Programming 2nd Edition will be available to buy on March 24th in the US, and about the same time in April for the UK. Since I finished writing the book I've been working on a new project: http://launchpad.net/lucadestudios.

Our aim is to write a couple of games, but in doing so build a set of high-level reusable component libraries. I'm currently working on the networking subsystem, while other members are working on physics and sound. We seem to be getting a lot done quite quickly which is always good.

Anyway, back to work...