Archive for the 'programming' Category

Movie Module Progress: Week 6

June 29th, 2009 | Category: Uncategorized,programming

So, week six. I devoted this entire week to exhaustive testing and bug fixing. Its just good software development to take some time, and test and fix bugs. No new features, nothing. I also took the time in the process to refactor a section of code I felt was extremely hacky and brittle. The benefit is that I ended up creating a couple of special-purpose functions which can be reused in multiple areas in the code for the future, possibly. As I found small bugs or issues, like deadlocks, I fixed them. There were a few that remained by Friday:

  • 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.

Comments are off for this post

Changing types in Python

December 10th, 2008 | Category: programming,python,python tricks

Okay, so its another entry in my long-abandoned python tricks series.

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.

1 comment

What is Computer Science?

August 26th, 2008 | Category: computer science,programming

There is a great debate going on over at the compsci.ca blog, in the comments, about just what is, or isn’t computer science.

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.

3 comments

Art of Programming

August 21st, 2008 | Category: creation,design,design patterns,programming

I just recently finished reading a book, no, rather, a comic, by Scott McCloud, called Understanding Comics: The Invisible Art. It was a fantastic read, very illuminating in many aspects. A lot of things I didn’t understand about art in general are finally beginning to be less murky.

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

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.

2 comments

Dynamic pathfinding(Cutting edge research!)

July 29th, 2008 | Category: AI,game design,npcs,programming

Today, I went to an awesome presentation by Vadim Bulitko about his most recent research. Here’s the presentation, but I’ll summarize what the presentation was about for general use. (I just found that the pdf didn’t come through the pdf export very well, apparently.) This was a presentation at UBC-Okanagan, in Kelowna, BC for reference. Vadim is thinking about taking his sabbatical here at UBC, yay!

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

Read more

3 comments

Next Page »