14 July 2008
08 June 2008
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).
17 April 2008
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.
05 April 2008
31 March 2008
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.
20 February 2008
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.
16 February 2008
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
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.
bzr branch trunk my-bug-fix
my-bug-fixis 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-fixfolder, and you can freely make any changes you need. After you are done (and periodically while you are working), you run
bzr committo 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.
06 February 2008
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).
23 January 2008
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:
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)
for alpha in interval(255, 0, time=0.5):
draw.color = (255,0,0,alpha)
draw.circle(70, 100, size.value)
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.
14 October 2007
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.