Opioid2D Pages Down

The Opioid2D web page is currently unreachable for some reason. I'm waiting to hear back from my server provider, but meanwhile, the pages are temporarily mirrored here.

June Status Update

Apologies for the long hiatus. I've just recently finished a really hectic project at work, and I'm now slowly getting back to Opioid2D. The first order of business is to finish the Box2D integration which I already got decently far. While I was "away", Box2D released the official 2.0.0 and 2.0.1 versions, so it was actually pretty convenient to delay the integration this far. There's also lots of very promising stuff coming, based on Box2D's HEAD revision (like automatic polygon decomposition), which will be very useful in O2D.

My summer vacation begins in the middle of July, and that's when I'll try to complete some bigger new features. On August, I'm moving about 150km closer to my job, so that'll cut down my commuting times significantly (translating into more free time to use on personal projects).

Future Musings

I've apparently lived in a cave for the last few months (or in actuality, at the work place) and was almost completely oblivious to the existence of pyglet, before it was pointed out to me in IRC today. Sure, I had heard about pyglet before and had a vague idea about what it was, but I had no idea it was already this advanced and sophisticated. Alex Holkner and the other pyglet contributors have really done a terrific job.

Opioid2D development has been really slow lately. It's mostly because of my work projects, but also partly because it has started to become difficult to add new functionality to the Opioid2D core. As I've developed the framework, it has unintentionally been emphasizing very specific kind of sprite based games (which were what I was mainly using pygext for when I started porting it to C++) to the point where the code base has become rather monolithic against certain kind of fundamental changes. I ran into this when implementing the box2d integration and while I would've gotten around the problems for that particular feature, there are same kind of problems when implementing support for isometric games or even plain 2D tile maps.

The main issue is that there is too much stuff that's coded in C++, that could just as well be pure Python and the C++ components have too much hard-coded dependencies to each other. It pains me to admit this, but pygext (my previous framework) was actually a lot more flexible and malleable, all while providing a nearly identical main API. On the other hand, the performance is way better, still over 10x for a large number of sprites, even with the latest improvements to psyco and the CPython interpreter.

At this point, I see it as a very attractive option to abandon most of the C++ core of Opioid2D, and migrate the API to use pyglet. Pyglet does lot of the low level stuff like windowing, timers, events etc. a lot better and cleaner than the Opioid2D code. I would also break up the Opioid2D framework into smaller, reusable components that could be cherry-picked into pyglet projects, instead of conforming your whole program to the "Opioid2D way" of doing things. The sprite engine would be cleaned up and written as a C extension (with box2d doing collision detection and physics) that would be an independent component that could be used by any pyglet project. Lastly, there would be a backwards compatibility layer called "Opioid2D" that would use these new, small components and transparently provide the same API as the current incarnation.

I haven't decided anything yet, but the above idea is one thoughtworthy possibility for the future of Opioid2D.

Bitograph 0.8 Release

I finished all the essential functionality, so I'm releasing the Bitograph library for others to try out. You can download the library from here and read the user guide online here.

Bitograph

I had to put the box2d integration on hold for a while, because of more urgent projects. However, this weekend I had a sudden inspiration to improve and expand the bitmap font support a bit. The current bitmap-font feature in Opioid2D (and pygext) is pretty primitive and doesn't let you fine tune things like kerning or have smart support for accented characters. The new one is the Ultimate Bitmap Font Engine(tm), with every possible fine tuning parameter you can think of, in order to have professional looking typography.

Creating a new bitmap font begins with a template file. This is automatically generated by Bitograph (the new library) according to the template parameters defined in the font project file. The generated template with the linked project file looks like this:



You can then load up the template file to your favorite graphics software and decorate the font as you see fit. The library also contains some stock effects (like Outline and DropShadow in the above example) that can be used by us non-artist programmers.

The linked project file might seem a bit daunting with the sheer amount of metadata, but choosing proper values is done very iteratively. You begin with nothing but the basic values (like line_height etc.) and then just add small adjustments according to how the font looks. This is made easier by the included Font Viewer:



You can tweak the kerning etc. values in the property file, and instantly see the changes in the Font Viewer (no restart needed).

The rendering code supports automatic text wrapping and will eventually support various text alignment and justification options. You can also compile long strings into bytecode-objects for the rendering engine, which makes line-wrapping and rendering a lot faster.

Expect to see the first release version of Bitograph soon.

This is Why I Like Bazaar

Bazaar has been a great productivity booster for me lately. It enables me to work on several concurrent major refactoring tasks, and painlessly merge between them. You can imagine what it would be like to do several merges daily with SVN or (*shudder*) CVS.

The biggest new thing I'm currently working on is the Box2D integration. I'd estimate I'm about 40% done now, and the biggest obstacle has been (once again) having enough time to code, but I hope to have the main functionality + a simple demo working next weekend or next week.

The Bazaar Is Open

I tested Bazaar for real development for a while, and it is really great. So, from now on all Opioid2D development will use Bazaar and the old Subversion repository is no longer maintained. The are two main branches in the public Bazaar repository

http://opioid-interactive.com/opioid2d/bzr/trunk

and

http://opioid-interactive.com/opioid2d/bzr/experimental

The trunk will mainly get bug fixes for now, and all new features are developed and published in the experimental branch. Once the features mature and undergo enough testing, they are merged into the trunk and a new alpha is released. I'm not going to rush the new releases until the new features are properly finished and the API stabilized, so I encourage you to get the experimental branch every once in a while if you need the latest and greatest features. Now that Opioid2D fully supports mingw, it should be pretty easy for anyone to compile their own extension. However, I can provide binary snapshots of the experimental branch if needed, so let me know if that is the case.

In order to download the trunk, for example, all you need to do is

bzr get http://opioid-interactive.com/opioid2d/bzr/trunk opioid2d

However, if you are going to use several different branches, I recommend you do the following:

bzr init-repo opioid2d
cd opioid2d
bzr get http://opioid-interactive.com/opioid2d/bzr/trunk
bzr get http://opioid-interactive.com/opioid2d/bzr/experimental

Creating your own local repository lets Bazaar share metadata between the different branches, so it's a bit more efficient.

Now if you want to make your own changes or fixes to the Opioid2D source, you should create your own branch. E.g.

cd opioid2d
bzr branch trunk my-bug-fix

The my-bug-fix is the name of the branch, which should be as informative as possible. I usually name bug fix branches beginning with fix-, so e.g. fix-sprite-edge-bug. At this point, you have your own complete copy of the source tree in the my-bug-fix folder, and you can freely make any changes you need. After you are done (and periodically while you are working), you run bzr commit to record your change history into your local branch. Finally, you run

bzr send -o my-bug-fix.patch

Which creates a patch file you can send to me to be included in the main trunk. Alternatively, you can publish your branch e.g. via HTTP and just send me the URL.

Opioid2D Version Control

I've been reading a lot about distributed version control systems lately, and have come to the conclusion that the development of Opioid2D would benefit from lot of the features available in them. I code on several PCs and e.g. my laptop is often cut off from the net when I travel. Distributed version control like Bazaar would make it easy to retain version history while offline and then merge the revisions to the online repository when regaining net connectivity. I'm also going to be doing some major refactoring of the C++ internals, and I think the distributed model of "branch per feature/bugfix" would make things a lot easier.

The one thing that worries me is that Subversion is something that is familiar to almost all developers, so it is easy for anyone interested in O2D to grab the SVN trunk. Distributed version control systems, however, don't seem to be as widely used or even known. I looked at several different solutions, and Bazaar is currently my top choice because it seemed to have the lowest barrier to entry with decent documentation and support for Linux, Windows and MacOSX. Mercurial was a close contender, especially since TortoiseHg seems more mature than TortoiseBzr at this point, but after giving them both a try, I slightly prefer using Bazaar (and its quick-start guide was a lot more comprehensive).

Another good thing about Bazaar compared to SVN is that I could publish the repository via a standard web hosting service and thus put it on the same server that contains the Opioid2D web pages. I'm currently renting a virtual server to run svnd in, and it hasn't been very reliable (nor cheap enough to justify the mediocre up-times).

January Update

Unfortunately I don't have much to tell regarding Opioid2D, even though it's been several months again. There have been small patches and adjustments since the last release, but most of my coding time has been spent on the game project I'm doing at work. The game is nearing its release deadline and the crunch is on, so I really haven't had that much energy for personal projects.

There are a couple of Opioi2D related things I've been thinking about, but haven't yet started implementing. The biggest is the rethinking of the node hierarchy system and sprite drawing order. The current design just isn't flexible enough in all use cases, and also isn't as efficient as it could be. Another important thing is the drawing system (lines, triangles, rects etc.) and how to tie that neatly into the action system and rest of Opioid2D. I also happened to come upon a really promising looking 2D physics library called Box2D, which would be a perfect fit for Opioi2D. I've browsed through the API, and I don't think it would be all that difficult to integrate it, giving Opioid2D true physics support.

When thinking about how to integrate drawing primitive shapes with the action system, I've built a prototype for a more generalized action API. This is something that will be released both as a part of Opioid2D and as a standalone action library that can be used with any Python program (pygame games etc.). The API currently looks like this:

@action
def example():
   size = interval(10, 15, time=0.5, mode=pingpong)
   for x,y in interval(start=(50,0), end=(70,100), time=2):
       draw.color = (255,0,0)
       draw.circle(x, y, size.value)
       yield
   for alpha in interval(255, 0, time=0.5):
       draw.color = (255,0,0,alpha)
       draw.circle(70, 100, size.value)
       yield

How does that look? My goal was to design the API so that it would be somewhat clear what the code does, even for someone not familiar with the API beforehand. interval objects give a value based on the current time and their initial parameters, so for example interval(0, 10, time=10) will increase its value by 1 per second until it reaches 10. yield is used to suspend the action until the next frame update.

October Update

My laptop (which was my primary development PC) had a hardware failure last month, so it has taken some time to order parts for a new machine and setting up the development environment for Opioid2D. Since setting up the free MS tools for Python extension compiling is somewhat of a hassle, I decided to try open source tools this time around.

The Opioid2D alpha 6 patch 3 released today has been modified so that it compiles correctly for Python 2.5 using MinGW32. Also, since the official release of Python 2.5 is now over a year old, I've decided to use that as my main platform from now on. If you need Python 2.4 support in Opioid2D, please let me know, as all future testing and releases will otherwise be for 2.5 only.

Other than that, I haven't had much time to develop new features and such, as I'm currently commuting about three hours a day to my new job. However, this is only a temporary phase and later on I will telecommute most days from home and that should free up some more time to work on my personal projects.