• Unpausing doesn’t work right. The video would jerk and stutter after unpausing.
• Audio and Video would drift out of sync within about 8 minutes on my test video.
• Sound would not restart on a replay

As of today(Monday), I fixed the sound restart issue, thanks to Rene’s advice, and the unpausing issue. Ironically enough, the unpausing issue was an extremely simple fix. The sound restart issue required me to simply play sound buffers of no sound while the sound was stopped. For the audio and video drift issue, I know why its happening, which is because I unlinked video timing from being synced to the audio. I knew I would have to fix this eventually, but it was an issue for later on. I implemented a first kind of draft solution today, which caused the video+audio to jerk and stutter. Very strange.

Once I have these issues fixed, and a lot of the slightly jury-rigged code from various attempts to fix or examine the various issues, I’ll begin adding new features.
I will add for the Beta release:

• Subtitle support. This way you can have your in-game video with subtitles for the deaf and hard of hearing. Trust me on this, its necessary. I’m hard of hearing myself, and I’m seeing more and more games that don’t have subtitles as an option.
• Rect assignation support. You can assign a rect, along with the surface of choice, to dictate which portion of the video image will be written to the surface you give.
• Seeking support. Now, you should be able to seek to (somewhat depending on the format) arbritary points in the video file
• Fix a couple of minor issues, like delayed resizing of the image
• Begin working on a sound api, for developers that choose to redirect the sound samples to the sound system of their choice.
• Adding more backends(like mplayer), and updating the backends we currently have to work better and faster
• With the mplayer backend, the plan is to have the video streamed as frames over pipes, so the smart programmer can do…whatever they want with those.
• Try to clean up the code, make it more readable, add a lot more updated documentation, including flow-charts!
• And other features as requested by the community members. If there’s a feature you want, email me at either zeroth AT oddco.ca or trinioler AT gmail.com. They both go to the same mailbox.

And checking with the schedule I gave the mentors, it appears I’m actually a week ahead of schedule! Granted, I’ve had to change my plans and ideas for the module as I learned more, but thats how the world works. I will predict Beta release in 3-4 weeks, including this week, which will give me time to update and fix bugs in all the other backends, as well as testing and bug fixing, after the beta release. In addition, after that I will begin the work of making the code work and compile on Windows and with Python 3.

First, lets take a look at a couple of classes:

class B(object):
    def foo(self):
        return '10'
 
class A(object):
    def __init__(self):
        self.a='a'
    def foo(self):
        return '1'

The important part here is the (object) subclassing. This trick only works if you do that. Lets take alook at it in operation:

>>> a=A()
>>> a
<changetype.A object at 0x7f0f18dbf9d0>
>>> a.__class__
<class 'A'>
>>> a.a
'a'
>>> a.foo
<bound method A.foo of <changetype.A object at 0x7f0f18dbf9d0>>
>>> a.foo()
'1'
>>> a.__class__=B
>>> a.a
'a'
>>> a.foo
<bound method B.foo of <changetype.B object at 0x7f0f18dbf9d0>>
>>> a.foo()
'10'
>>> isinstance(a, B)
True

As you can see, I was able to override the foo() method with the one in the Beta class. As well, this only works on instanced objects. Now, what use is this you may ask? It is basically meta-programming. For 90% of programming tasks, meta-programming is not needed at all. But for that remaining 10%, you can do some seriously cool stuff, like changing the operation of a class during runtime, without modifying the class variables.

As a real-life example, I just finished writing a simplistic query parser. I realized I had forgetten to take into account price queries, so, I created a PriceToken class, that on instantiation, changes its own class to that of a TermToken. Otherwise, I would have had to rewrite about 100 lines of code to allow the use of a PriceToken. Pretty much useful because I’m lazy. But, yes, in Python, you can change the type of an object on the fly.

I provided a pretty good response, but I thought I’d go into a bit more depth.

Trying to define what CS is, is just like trying to define what Mathematics is. Math gives us the tools to deal with relatively simplistic problems, like algebra, calculus, etc. These tools have allowed us to make enormous strides, in economics, statistics, physics, chemistry, biology, and so on. The presence, and usefulness of Math is undeniable in every field of Science.

Math is an asbtract field, dealing with numbers and logic at their very basic. Working with these, we have made some fantastic tools, but several fields are beginning to see the limitation of the equation.(Hmm, that rhymes.)

What Computer Science is, is the study of solving problems. It is not logic, nor math, nor boolean algebra. It is not linear optimization, database design, or programming. It is a superset, of all those concepts, though being derived from those basics, the sum really is more than the whole.

Thanks to CS, we have the most basic unit of problem solving, the algorithm. As we examine different kinds of algorithms, we create the tools to use and apply those algorithms. To me, this is much like the basic unit of math, the equation. Everything else we have in CS are really just an extension on algorithms. If you’ve studied high level CS, you will have seen that the problems being solved… are extremely abstracted.

The reason for this abstraction is simple. It builds our CS vocabulary and toolbox, giving us tools for screwing screws and hammering nails. Instead of needing a specific hammer for a specific kind of nail, we have an abstraction, that lets us deal in general with all kinds of nails.

Let me tell you a story. I worked for a week, in the cyber cafe for a congress of oceanographers and meteorologists. I had to help them upload their presentations, and in the process, I got to see the latest and greatest of oceanography and meteorology. And here’s the thing: they’re beginning to use tools and concepts that were developed in CS 30 years ago! I asked several scientists on this matter, and they admitted that the equation as a tool doesn’t work for the complexity they deal with, and the algorithm works very well.

We, in CS, are developing the tools and vocabulary needed to describe complex situations and balances. We are learning how to solve problems. We are… at the same point that the grecians were with numbers and mathematics. CS is more than Science or Math, though it contains elements from both. CS is itself a completely new field, and until we recognize that, we’ll be held back.

Oh, and Programming is simply the actual usage of these tools, much like accountacy, algebra, physics are all applications of Math.

One of the most striking concepts was the six stages of art. And it resonated. I realized that those six stages correspond as well to the development and progress of a programmer.

In his comic, the six stages are as follows: Idea/Purpose, Form, Idiom, Structure, Craft, Surface.

The Six Steps of Art

Let’s start at the top: Surface.

Surface applies to the most basic of programming. Simple statements, flow control, basic functions. Every programmer begins their growth at this stage. They learn how basic math works, properties, etc. They learn how to order statements, if conditionals, and loop guards.

Next is Craft.

Craft is where they take the basics, the Surface, and begin constructing bigger things. Functions, classes, basic data structures. Here, they learn how to construct a complex piece of smaller simpler pieces, but they are only just barely beginning to learn why and how it works that way. Any data structures they build are based off of basic data structures, and they don’t yet understand deeply the fundamental ideas of efficiency, logic, and computability. The good programmer also begins to learn about source control, using their tools, building, and deploying their work.

Structure is next in their growth path.

Here, they begin to learn how to organize their complex pieces into a working piece. How to access and parse text files, basic database interactions. They’ll do things the slow, wrong way, but its necessary to reach the stage of development. Here, they begin to worry about efficiency, the right way of doing things. Object Oriented programming starts to make sense as a conceptual model(which is all it really is). The now competent programmer is capable of learning other basic conceptual models.

Idiom is the biggest part of the growth.

Here, they begin to learn about Design Patterns, and begin to apply them. They apply them at every stage, from the basic Surface, to the overall Structure of the program. They also begin to learn about the ideas and concepts behind data protocols, to use them where needed. This is when programmers become cynical about Silver Bullets. This is when they finally realize there is no substitute for skill, experience, and effort. Many programmers do extremely well staying at this stage. However, to become a top-notch programmer, one needs to see and explore the limits of programming.

That is where Form comes in. Programmers at this stage explore the efficacy of Design Patterns, breaking them where and when needed, even developing their own versions. They begin to develop solid ideas about how API’s should work, about what is computable, about efficiency, and about Logic. These are the programmers that take already established tools and concepts, and bring us exciting new ones. Notable examples are: Bittorrent, Linux, and the Mouse. They looked at what was being done, and brought something new, and world-changing to the world of computing.

The final, highest level of development is Ideas/Purpose. This is where programming Gods like Knuth and Stallman rest. This is where Computer Scientists do their heady, ivory tower research that is oh-so-important to the world at large. This is where concepts of algorithms, data structures, efficiency, and logic are explored in their abstract. This is where Computer Science is rooted, and where the birth of the computer industry started. This is where Boole developed his ideas of Boolean logic, where Cray designed his supercomputers, and the very basis of all digital electronics.

Now, this is the normal path most programmers take in their growth. Even though, in College and University, we’re taught the ideas and purpose of programming from almost the start… when we don’t have the basic building blocks of understanding of logic and program construction.

As my friend Khumba just said: “You can’t play Protoss until you’ve played a few games with Terran.” You need to understand the basic building blocks of logic, statements and flow-control and the experience with those to understand the higher level concepts of functions, routines, threads, classes, modules, executables, algorithms.

The thing is though, we can start at any stage we like, from Ideas/Purpose, to the Idioms of programming. But the greatest, best programmers amongst us will explore all of these stages in depth, learning what they need from it to improve themselves and their art. Because thats what Programming is. It is an art, and we are the artists, working with the pure stuffs of thought. We translate the abstract to binary logic, to 1′s and 0′s, and for that… we are artists.

If you disagree, or agree, let me know. Theres a handy comment box right down there.

Its a rather innovative technique, and delivers great results for only a bit of computer power.

The Big Granddaddy Algorithms

First, a bit of background as to what has been done before. The Big Granddaddy of pathfinding algorithms is the A*(called the A-star) algorithm. It makes the complete plan, every step needed, to get from one point to another, then executes it. Unfortunately, the amount of time this takes scales exponentially with the size of the map. It, however, does provide an optimal path.

The other algorithm is the LRTA* algorithm, which looks ahead, and moves based only on that information. For example, it looks ahead, maybe 3 steps, and sees what sequence of 3 steps will bring it closer, in a straight-line measurement, to the goal. This has the benefit of always executing within a certain amount of time. Unfortunately, walls between the agent and the goal can and will prove difficult to surmount.

An addition to the LRTA* raises the “distance” weighting of a node every time the agent goes over it, thus eventually forcing the agent to go around the wall. But it still takes bumping into the wall three or four times to finally find the correct path.

Its all real(time that is).

There are a few constraints that pathfinding needs to work under in games, and even in robotics(Phoenix Mars Lander anyone?). You need to have something that can operate and find its way with only a bit of computation, and predictably work well. It would be a disaster for a $70 million dollar robot to keep bumping into a rock.

As well, with ever more powerful cpus and gpus, gamers demand more and more units, and bigger and better maps. The irony is, that with increasing hardware power… comes even less time to compute pathfinding and general AI. Computer power has only quadrupled a couple of times since Starcraft, yet, we demand 100 times more units, with smarter and more intuitive AI, coupled with four or five times bigger maps.

Dynamic Lookahead

So, the way that D LRTA* works is first, they have dynamic lookaheads. Some squares on a map require more searching to find a near optimal solution, particularly around corners. One way to determine the lookahead value for a square, is to naively compute the required minimum lookahead depth to any other possible square. Then, store the pairs of coordinates and that lookahead depth, and just look it up! Simple, eh?

Not really. On a 512×512 map, that results in ~68 billion pairs to store. On a normal desktop, that would take about 2 years to compute(probably a lot less on a compute farm… google could likely do it in one minute, because its an extremely parallelizable problem.) This is quite unacceptable, both due to time constraints and space constraints. This is where the research group’s second innovation comes into play.

A house divided…

They found that splitting up the map into spaces, and then computing the optimal lookahead depth from one space to another worked very well. In the worst case, it devolved into LRTA*. However, there must be a better way to divide things up…

Clique Abstraction

[Sturtevant, Buro 2005]

Clique abstraction was developed in the above cited paper. It is the concept of taking adjacent tiles, and lumping them into one larger tile. For example, four adjacent tiles that are all interconnected, could be replaced by one larger tile. And so on, with larger and larger abstraction at each level. (Take a look at page 38 from the PDF)

It becomes a lot easier to pre-calculate the optimal lookahead depths when you have a sufficient level of abstraction. Granted, you lose a bit of that oh so sweet optimalness, but its worth it for getting things to work within a certain amount of time. Of course, walls and pockets on maps still give the budding algorithm a bit of trouble. Which leads us to the next addition to D LRTA*:

Setting goals

The team found that by setting intermediate goals, they take advantage of a small property of lookahead algorithms: they’re more accurate closer to the goal. By setting goals in each of the subdivided spaces, its plainly obvious to the algorithm that going that-away is better than going this-away.

As well, by not placing goals in spaces that are obviously farther away from the ultimate goal than the starting point, it makes the algorithm ignore those spaces.

Right now, there are two ways to do dynamic lookahead: pre-calculated with clique abstractions, or calculated on the fly with sub-divided spaces and intermediate goals. They both come with their pros and cons, and if the game company can afford it, it appears that precomputed is much more reliable.

Optimal lookahead:

Optimal lookahead depths for a Baldur's gate map

Stored Lookahead

Stored lookahead depths for a Baldur's gate map

I do have a few questions about the research, that unfortunately I didn’t ask at the time, for example, the outliers on the graph on page 70. One of the results for the little dots was very efficient, but the other two dots are optimal, yet expanded lots and lots of moves. As well, I’d like to know exactly what the different algorithms that were used for the graphs, specifically. I will ask the presenter today.

What else?

What needs to be done to expand this research, is to look at how to handle dynamically changing maps, and moving targets. As well, they haven’t looked at memory storage techniques or compression of precomputed files.(According to Information Theory, the data files could likely be extremely compressed, on the order of 75% compression or so.)

A few more lessons I’ve learned:

• sometimes theres a faster way to do stuff.
• make sure you aren’t putting repetitive data into a database
• verify the data format before you download 2-3 GB of it

Okay, so, faster way to do stuff. Python has both a performance advantage and disadvantage. The advantage is that it only takes one or two hours to code up something to process data. The disadvantage is that in an effort to be clear and simple, one can end up coding a task that takes 20-100x longer than it should. Like I did.

I had a lot of nested loops, python speed loops, involving lots of duplicate handling, inserting to a database, etc. It took five hours to go through only 14 sets of queries to clear out. I had a lot of duplicate rows that needed to be erased. For a query looking for rows with an id of 15, there are 25,607 records. Removing the duplicates yields… 807. Brilliant.

Today, I decided to take most of the loops, and replace them with their functional counterparts, map, lambda, and Google’s functional tools in python, goopy. In only two hours, it has gone through now, 160 ids. In less than half the time. Pretty amazing, eh?

Here’s a sample:

for row in all:
     curs=curs.execute('insert into elements2 values(?, ?, ?, ?, ?)', (row[0], row[1], str(row[2]), str(row[3]), ''))

replaced with:

map(lambda row: <code>conn.execute('insert into elements2 values(?, ?, ?, ?, ?)', (row[0], row[1], str(row[2]), str(row[3]), ''))</code>, all)

A little bit more difficult to read, yes, but, the speed improvements are well over 50 times faster…

All this work to clear out duplicate entries, and how intensive it can be to fix, is a perfect example of why the “Look Before You leap” programming paradigm works better than, “Ask for Forgiveness Not Permission”.

Now, once the processing is done, I’ll be able to go through all the data… and add a piece of information I forgot to process in the first place to each entry. Yay me!

Memory handling schemes go awry

Well, not quite. More like, a leaky abstraction, compounded by my own idiot mistakes in the code. When memory is allocated in a loop, it is normally a smart optimization to hold onto that memory. What this means is that there are some cool things that you can do, like, refer to variables that were allocated inside a loop, and they will be in the local scope. They will just have the latest value thats been assigned to that variable.

However, in my case it backfired. The memory was held onto… and never reused. Essentially, I had a memory leak.

My own stupid mistakes

What happened, is that I was loading in a variable from a pickled file. However, what I had done was:

elements = pickle.load(open('file', 'rb'))

Normally, this would be okay, however, due to the size of the files, and the fact I was doing this in a loop, over different files, is that there was a now opened multi-megabyte file floating around, that has not been closed or reallocated. Actually, several. I came home after two hours to find that almost all of my RAM and 70% of my swap space had been used. Thats 70% of 3.8 GB. Yeah, great job Zeroth.

The lesson here is, that what works well for a small loop, or small files, does not neccesarilly work well for large files or large loops. Always make sure you close every file you open, and if worst comes to worst, allocate memory by using the del keyword in Python. I’m using this, and there is very moderate memory growth, as compared to the quite massive almost 6 GB of memory the code was taking up before.

So the proper way to do this is:

f=open('file', 'rb')
elements = pickle.load(f)
f.close()
del f

I do need to make this clear. This fault was not due to Python, or any problems or bugs in it, but rather with my own sloppy code. Even the best of us make mistakes, and I’m definitely not the best of us.

A new installment in my ever-popular series.

Todays installment will concern one of the best performance enhancing tricks in python: list comprehensions.

Most beginning pythonistas will produce code like this:

lst=[]
for i in range(0, 10):
     lst.append(i**2)

Now, thats pretty okay. It runs… okay. It is the kind of code I would expect from a newcomer to Python, however, one of Python’s weaknesses is its slower running speed. This, by the way, is a weakness for pretty much any interpreted language, like Java or Ruby.

Now, imagine you have a much larger data set to work with. On the order of thousands, hundreds of thousands. Processing all of it at Python speed will drag your program down.

But, you are in luck: there is a faster way.

Unfortunately, this faster method has its own set of issues, and the first and most obvious one, is legibility. Done wrong this technique can and will obscure the meaning of your program, and make it harder to maintain.

This technique is list comprehensions. The upper piece of code would be, in a list comprehension,

lst=[i**2 for i in range(0, 10)]

This line of code runs in C speed, not Python speed. For a large dataset, this can be an improvement of 10-100 times faster!

Now, lets break it down: there are three parts to a list comprehension. The first portion is an expression. The second portion is a for clause. And the third portion is one or more for or if clauses.

The first for clause in the list comprehension declares a variable, and the expression must do something with that variable.

Or, for those language lawyers:

test ::= or_test | lambda_form

testlist ::= test ( “,” test )* [ "," ]

list_display ::= “[" [listmaker] “]”

listmaker ::= expression ( list_for | ( “,” expression )* [","] )

list_iter ::= list_for | list_if

list_for ::= “for” expression_list “in” testlist [list_iter]

list_if ::= “if” test [list_iter]

Basically, a list comprehension consists of:

[expression using 'x' variable for clause declaring 'x' (optionally: if 'x' meets some condition)]

Again, one of the cardinal rules of optimization are that you only optimize when you know where the bottlenecks are. So, when you first code a for loop or list initialization, use the regular for loop. Then, after the program works, you can optimize it out to a list comprehension, and test the resulting speed.

This will, in most cases, make your program faster, and make you a Python guru. So, till next time, keep on hissing!

Due to its nature, Python is very flexible and very versatile, and over the years, I’ve learned some very very cool and useful python idioms and tricks.

What I will show today is a Design Pattern that fits the ideology of Python well, and delivers a great amount of flexibility and usefulness. Its called the Borg Design Pattern.

I’m sure we’re all familiar with the Singleton design pattern. The Borg DP is almost precisely the opposite. Instead of one instantiated object, and just one, the Borg DP allows you to instantiate any number of the objects, and have them all share the exact same traits, methods, variables.
(assume there is proper formatting for this function)

1| class Borg:
2| _share_state={}
3| def __init__(self, *args, **kwargs):
4| self.__dict__=self._shared_state


Here’s the beauty of the Borg DP: on any of the instantiated objects, if you modify a variable, all of the instantiated objects reflect that modification. Every single one of them. Hence the name, Borg Design Pattern.

The important line here is line two: “__dict__={}” before you declare any methods of variables. When you do this in Python, all instantiated classes have a reference to that single variable and object. And __dict__ is an internal dict of the class, that stores all methods and all variables!

The power of this trick is such that, you can use it for many of the same places you once used a Singleton, but without needing to worry about references, thread safe access, even checking how many objects have been instantiated. It cleans up all associated code, and gives you the confidence to know exactly what is going on with the object.

And thats part one! Stay tuned for more Cool Python Tricks(tm), hopefully one a week!

EDIT: Fixed borg design pattern, small bug.

I’ve made enough posts here without making a mission statement of any sort, so here goes.

I want to help others like myself, curious and wanting to learn. I wish I’d had someone to share things with me several years ago, things I learned through my own trial and error, through blood and sweat dearly earned.

I chose to become a programmer simply because their is nothing quite like it. All you need is intellect, logic, and creativity. And with those base ingredients, you can construct anything. Anything at all. It appealed to me, the power a programmer has over this inscrutable machine called a computer. I found it easy, and interesting, and thus my life goal was set.

However, what kind of programmer was I to be? Will I be an egghead academic, working on complex and unknowable topics? Will I become a Unix hacker, complete with scruffy beard and free software on the tongue? Will I become one of those web 2.0 darlings, perfectly awkward in the limelight, and caring about things like ‘spiders’ and ‘eyeballs’ like they were some witche’s brew? I don’t know yet, but I do know, I have more fun making and designing games than anything else, and that is where I will head.

But no, I don’t want to join Blizzard, or Bioware. No, I’m starting my own company! One where code monkeys can swing in the trees and go home at the end of the day. One where Artists of every kind aspire to be hired. A place where brilliance seeps out of the walls, and is breathed in like so many spores. I am making OddCo, with my best friend, Ruby. Join me for the ride.