angelhill.net/code

Have you ever felt that you were dreading the thought of creating a new django app because you didn’t feel like doing the urlconfs or copy and pasting all those annoying view helper methods?

Or maybe you didn’t like having to apply the same decorator to every view function?

Maybe even, your views.py files grew so large that they became hard to maintain, and splitting them up seemed like a hastle?

Well, the above problems and more are solved with the django url framework, which I wrote to emulate some of the functionality of Ruby on Rails.

A quick and dirty explanation is that you create controlller files with a class that extends the ActionController, and all instance methods of that controller are automatically made into URLs.

Included the the ActionController is all the functionality that you may need, such as a flash inter-request messaging system, redirects and action/controller based url resolution, filters to run before and after each view and more. Look it up on the google code page and give it a whirl.

So you want to install Leopard from a DMG file. I don’t know how you got it, and I don’t care. However you have a problem, you only have a USB drive.

You might have noticed that you can’t install Leopard by restoring a Leopard install DMG onto a USB drive, since most Macs wont boot from USB.

But if you have a Mac, odds are you have an old Apple Restore DVD lying around. If you have a Mac OS X Leopard restore DVDs that you got with your new mac, you might have noticed that those DVDs wont allow you to install onto an older mac…
In theory the information below should work with a Tiger DVD as well.

So you have a USB drive with a restored Leopard image on it, and you have a Leopard (or possibly Tiger) restore DVD from your new shiny mac.

Together they form a working Leopard install. I will enlighten you. The information below applies to a Leopard Restore DVD, so YMMV.

Boot the restore DVD by holding down C when restarting your computer with the DVD inserted. It will tell you that Leopard can’t be installed on this computer. Press OK, do NOT press Restart.

Open the Terminal application from the Utilities menu. By now your USB drive should be inserted and powered.

I am assuming some knowledge of using the command line.

Navigate to the Leopard partition on your USB drive:
cd "/Volumes/Mac OS X Install DVD/"

cd "System/Installation/CDIS/Mac OS X Installer.app/Contents/Mac OS/"

You have now entered the secret dungeon of the Mac OS X Installer.

This will run the installer:
./Mac OS X Installer ../../../../Packages/OSInstall.mpkg

Your Leopard install should now begin and you are on your way to Leopard Heaven.

Technorati Tags: install, leopard, mac os x, usb

I found a way to fix a limitation with cake scaffolding.

When defining scaffolding in a controller, use:
var $scaffold = 'admin'
or whatever prefix you want your scaffold urls to have!
This is not documented, so it might just be a feature of the latest 1.2 branch.

This way you can place your scaffolding methods into a separate namespace and be able to create non-scaffold methods without having to override the scaffolds and thus lose scaffold functionality.

I personally feel that the cake scaffolding is very powerful, especially in version 1.2. It certainly does not replace a full admin center, but is enough to get the project up and running. Once your model is more or less frozen, you can start removing scaffolding or even better, extending it.

I’m working on getting Totem (the best all-round media player for gnome in my opinion) to work nicer with HTTP authentication when compiled with xine-lib.

Also planning on delving into an authentication framework for xine. Although that is a much bigger issue and I’ll need to brush up on the xine API first…

This is my first ever work on a major open source project and while none of my patches have yet been committed, I feel great. The idea of giving back to the community that has paid my bills for many years is super cool. I wonder if you ever get tired of contributing to open source projects? I’m such a n00b!

update: my very first patch has been submitted

It’s been around 2 years since I posted here on this blog.

I have decided to once again revive this blog with interesting projects and other code-worthy things.

One day perhaps this blog and /life will merge, but for now they are indeed separate beings focused on separate issues.

First things that I will be posting here are collections of documents and other fun things related to interesting projects that I did during the last three years at university (KTH).

I must admit reading some of the old entries brings back memories of incompetence and such. I’ve learned a lot since then, but I still have much to learn.

Technorati Tags: blogging

How about this idea…. Python is a pilot, and C++ is the ship.

Basicly I figure that I still want to keep most of the object infrastructure in C++ but let python control some objects such as ships.

I did come up with the idea of sending extensive data back and forth via lists rather then separate methods for everything… this will surely save time and code, since I wont have to have a method for every little detail that python or C might need to know about a ship.

In any case, I am still working on this whole integration thingie.

Today I realised that perhaps the best way to store data about graphics, sounds, objects and actions would probably be XML.

After creating some basic XML files containing the data for my meager game, I have come to realise that I was correct. Using XML files might create a larger file, but in the end I believe it to be worth it.

XML makes it easy to store the data about all kinds of shit, and by using DTDs I can even set default values for rarely used fields and all that kind of stuff.

In other words, the ambiguity of ["ship-01","ship.png",12,5,1] was replaced with

<ship type="ship-01">
    <action name="default">
        <animation name="ship-01-default"/>
    </action>
</ship>

With the animation itself being in a different place. Basically I believe this will allow me to easily create lots of versatile templates for my game without having to wonder down the road what the hell it all means.

I am currently working on parsing the XML files with libxml so I can start using the data from the XML files. It has taken me some time to figure out how the stuff works, but I think I got a grasp on it now and tomorrow I should be able to shun the python data files and just use XML. I hope.

An important thing to consider:

At the moment, most default values for speed, names, hitpoints and such are all set inside unchangeable C code.

And python has no way to change it. This is bad, simply because python should be the one dictating how many hitpoints the Player ship has and what the speed of torpedoes is.

Tomorrow (or whenever i get time to continue with this), I shall thoroughly look over the control that python has over the objects, and try to decide how to give it more control, as well as get the communication between python and C++ code improved.

I believe that C++ should keep track of objects collisions and such, their life or death state etc, and report any change back into python, while python will be the one to set the values.

Still hungry, and tired.

After coding for a few hours, I’ve come to a pretty decent idea of what I am dealing with.

At the moment, sprites and sounds are completely separated from actual objects.

Well, sounds are actually extensions of the base Object, and sprites are stored in a MAP with the object id being the key.

The issue right now is that there is no way for the object to inform the sprite as to what graphic it wants to have.

Earlier this was done with the object type string, however the object type is now an integer and is more a generic type to help with the creation of the correct class in python.

I realise now however, that the reason python was using strings for object type was simply because the strings were equal to the class names inside the C++ code. I think I will go back to that for simplicity.

Also, the whole object type thing, while very useful for torpedoes, still needs some clarification as to it’s role in other instances.

As for which sprite will be assigned to which object, perhaps the addObject method can simply accept the name of the sprite that is needed, or even better, the python code will use it’s newly created Action code to assign a sprite to an object, until such a time, the object will simply be a floating piece of nothing.

However upon first creation of the object the action code will assign a sprite by default so we dont have to do too many method calls for creation of every object.

Basically this post if full of random thoughts, so i can remember this stuff tomorrow.

I added a new method to the base object called destroyAllChildren. This one not only makes children into orphans, but also kills them, meaning they are garbage collected and removed from the object manager upon the next loop.

This has proven useful when we add sounds as children to objects. Because as the object is destroyed, so are the sounds and any other children that are associated with it. However it is also a problem because even though a ship is destroyed, it’s torpedoes live on. So I think this method will surely not live inside the constructor. I think the best way to get rid of all useless sounds is to make their isAlive method return false when the sound is done playing.

Also I just noticed how cleverly (I think) I handled the sound issue. By making sounds into extensions of object class, I have simply been able to add sounds into the very same object container that holds all the other objects. Making sounds into children of objects, I am able to give sounds position data from their parents without relying on specific functionality in the object manager.

This seems to work extremely well, and the only downside is that right now sounds are not automatically garbage collected because their isAlive method always returns true. If I could simply make it return false when the sound is finished, garbage collecting sounds will be a piece of cake. Or rather, it will be done automatically since the function is already there.

Perhaps a similar method could be used for graphics. To create a Graphic or Animation extension of the object class, and assign this graphic as a child to whatever object it should be assigned to. Then make it’s obey parent obey the parents every move (not just match velocity), and we’re good to go. This might be the best idea I’ve had yet.

The cool thing is that with this method, we don’t need too much special functionality in the object manager, and we can also extend the Graphic object with more details such as multiple layers and whatnot.

Hungry. Must eat.