This is the newer version of the MKV2M2TS conversion script I previously posted. This new version is faster and has less dependency plus the addition of HandBrakeCLI into the mix means that even when all else fails the script can still do a slower but guaranteed to work full encoding.
Showing posts with label work. Show all posts
Showing posts with label work. Show all posts
Friday, July 05, 2013
Wednesday, August 29, 2012
Caseware Fun Day 2012
The following video was recorded in 720p click the youtube button to see the full size video.
The following video was recorded in 720p click the youtube button to see the full size video.
The following video was recorded in 720p click the youtube button to see the full size video.
The following video was recorded in 720p click the youtube button to see the full size video.
Monday, November 07, 2011
Programming definition: Fragile Code
I've seen variations of the programming term "Fragile Code" lying around but I thought I'd formalize it in a post so that other programmers can get an idea of what this means. For me fragile code is defined as follows:
Generally speaking fragile code is not discovered until a strange bug occurs that was caused by violation of one of the assumptions in the original fragile code. What makes fragile code dangerous is it makes time estimates increasingly difficult as a small feature ends up breaking the fragile piece of code despite it having no direct relation to the feature being added.
On the internet Fragile code is referred to as copy and paste code but I frequently find that too specific in fact some programmers in my profession I find write fragile code by nature because they can have access to the entire code base so they assume the contents of other classes and methods won't change.
How do you not create fragile code?
#1 Never trust the contents of methods always assume that anything inside a method may change the only thing you can rely on is the method name to indicate what the methods should do.
If you encounter this scenario you should either indicate the dependency through the method names or (preferred) have automatic function call dependency. I.E. add code so that if you detect func2() was called without func1() then have func2 execute func1. However it would be preferable that if you have this scenario to not expose the utility functions altogether.
Fragile Code: Code that is hard to service, modify or improve without introducing many bugs. Fragile code tends to rely on too many assumptions that quickly become no longer true a features are added.
Generally speaking fragile code is not discovered until a strange bug occurs that was caused by violation of one of the assumptions in the original fragile code. What makes fragile code dangerous is it makes time estimates increasingly difficult as a small feature ends up breaking the fragile piece of code despite it having no direct relation to the feature being added.
On the internet Fragile code is referred to as copy and paste code but I frequently find that too specific in fact some programmers in my profession I find write fragile code by nature because they can have access to the entire code base so they assume the contents of other classes and methods won't change.
How do you not create fragile code?
#1 Never trust the contents of methods always assume that anything inside a method may change the only thing you can rely on is the method name to indicate what the methods should do.
#2 Don't even trust yourself. Ok so you wrote a function and you know that you only call it with a non null condition. The problem is this assumption that you made quickly falls flat when working with a team. Other people modify your code and your original assumption that you can expect a certain call order I.E. function 2 will always be called after function 1 and therefore funciton 1 will make a class level variable not null is not a stable assumption.
There is a way around this however. If you absolutely need function 1 to be called before function 2 stick an assertion that says that. Assertions are NOT program logic they are programmer tools an assertion states the programmer's assumptions at runtime. If you are assuming something and you know you can't handle a situation where your assumption isn't true stick in an assertion. This will at least make your fragile condition easier to track down in the future.
#3 Never rely on call order. One type of fragile code is function call order reliance this is when a programmer creates utility functions func1() func2() func3() and they must be called in order func1() func2() func3() calling any one of these out of order will cause a failure. The problem is to an outside observer func1() func2() func3() look like independent functions and don't look like they have anything to do with each other so in theory they may think you can call func2() and it should be fine.
There is a way around this however. If you absolutely need function 1 to be called before function 2 stick an assertion that says that. Assertions are NOT program logic they are programmer tools an assertion states the programmer's assumptions at runtime. If you are assuming something and you know you can't handle a situation where your assumption isn't true stick in an assertion. This will at least make your fragile condition easier to track down in the future.
#3 Never rely on call order. One type of fragile code is function call order reliance this is when a programmer creates utility functions func1() func2() func3() and they must be called in order func1() func2() func3() calling any one of these out of order will cause a failure. The problem is to an outside observer func1() func2() func3() look like independent functions and don't look like they have anything to do with each other so in theory they may think you can call func2() and it should be fine.
If you encounter this scenario you should either indicate the dependency through the method names or (preferred) have automatic function call dependency. I.E. add code so that if you detect func2() was called without func1() then have func2 execute func1. However it would be preferable that if you have this scenario to not expose the utility functions altogether.
Tuesday, July 12, 2011
The importance of intuitive interfaces
Good user interfaces aren't just for users. We programmers forget that nice intuitive interfaces actually prevent programmer error. For whatever reason GXT chooses to have the most unintuitive interface in the world take this for example.
The selection model affects what happens when a user tries to make a selection on a grid (think excel table). The method accepts any selection model as well as null. If a programmer wanted to disable selection on the grid they would intuitively do:
That would be what you and I would and without any prior knowledge of the library we would think this means that the selection model is disabled when it is not provided.
Obviously this doesn't work otherwise this post would be pointless if you try the above you get a null pointer exception. So how do we disable selection at all? Will through this obscure post we find out that in order to disable selection on the grid you must first provide it with a selection model and then disable it.
or in a more compact way
What's the problem? Well for one you still have a selection model in the system and all selection models have to implement this "locked" mode which means disabled. You can't just disable a selection model.
But you say "It is documented when you dig through the documentation" that much is true their documentation has this to say:
But the point is when there is such a thing as the interfaces behaving in an intuitive way. A programmer should take into consideration their fellow programmers and add convenience methods in order to give other programs an intuitive way of doing things. For example if the grid itself had a:
Which sole purpose is to set the selection model locked or unlocked this would be much easier to use.
Grid.setSelectionModel(SelectionModel m);
The selection model affects what happens when a user tries to make a selection on a grid (think excel table). The method accepts any selection model as well as null. If a programmer wanted to disable selection on the grid they would intuitively do:
Grid.setSelectionModel(null); //Sets the selection model to null (disabled)
That would be what you and I would and without any prior knowledge of the library we would think this means that the selection model is disabled when it is not provided.
Obviously this doesn't work otherwise this post would be pointless if you try the above you get a null pointer exception. So how do we disable selection at all? Will through this obscure post we find out that in order to disable selection on the grid you must first provide it with a selection model and then disable it.
SelectionModel sm = Grid.getSelelctionModel();
sm.setLocked(true);
or in a more compact way
Grid.getSelectionModel().setLocked(true);
What's the problem? Well for one you still have a selection model in the system and all selection models have to implement this "locked" mode which means disabled. You can't just disable a selection model.
But you say "It is documented when you dig through the documentation" that much is true their documentation has this to say:
setLocked
public void setLocked(boolean locked)
- True to lock the selection model. When locked, all selection changes are disabled.
-
- Parameters:
locked- true to lock
But the point is when there is such a thing as the interfaces behaving in an intuitive way. A programmer should take into consideration their fellow programmers and add convenience methods in order to give other programs an intuitive way of doing things. For example if the grid itself had a:
Grid.disableSelection(boolean disabled)
Which sole purpose is to set the selection model locked or unlocked this would be much easier to use.
Tuesday, June 07, 2011
GXT sucks moment
I was using this library called GXT at work and man does it have bugs.
Here's an example if you click on a menu button too fast your context menus never disappear.
It would appear that web developers don't have the same level of robustness as conventional developers / engineers. Then again maybe the people behind this library are just lazy.
Here's an example if you click on a menu button too fast your context menus never disappear.
It would appear that web developers don't have the same level of robustness as conventional developers / engineers. Then again maybe the people behind this library are just lazy.
Friday, November 12, 2010
Javadoc Rant
Javadoc is this wonderful invention. It allows a programmer put a comment into their code above the methods they are writing in order to generate automatic API documentation. But it’s simplicity is also a curse often times Javadoc descriptions are absolutely awful.
And in some cases Javadoc descriptions which are suppose to contain how and why you would use something serve to only remind a programmer what the method name was called. For example in the GXT API for google web toolkit extra widgets we have this excerpt:
getStyle
public TreeStyle getStyle()
- Returns the tree style.
- Returns:
- the tree style
Hmm… I think most programmers can guess the that from reading the method. But what is a style? In particular what is a TreeStyle? What does it define?
Almost all JavaDocs I’ve come across so far suffer from lack of information. If any JavaDoc users out there are listening. The reason many programmers flock to languages like C# is the documentation is gold. Javadoc is a great technology but if it is to compete Javadoc writers need to not only state what the method does but also mention why you may want to use it.
In addition almost every MSDN documentation I’ve seen to date gives at least one example of the method in practical use so the programmer has no doubt as to how to use that API. Ask yourself when’s the last time you saw a useful example inside a Javadoc?
Technology is great Javadoc is incredibly easy to generate, but the ease of use leads to very poor documentation. Most JavaDocs are an afterthought and it’s highly disappointing.
Wednesday, July 14, 2010
Reading Android XML Resources
I’ve been playing recently with some Android development and recently I needed to load an XML resource (for API 3). I was very surprised to find that Android doesn’t have a super easy way of loading XML resource files.
The XMLPullParser works but it’s very bare metal and does leave quite a bit to be desired. So I decided to go ahead and create a generic XML parser that all android developers can use (and improve).
First we establish a base XML data structure I decided to keep things simple here so I'm not at all doing anything about attributes if you wish to handle attributes you need to add a new ArrayList for attributes.
Now that we have our basic XML data type we can start create a class to read it:
public static XMLData Load(XmlPullParser parser) {
XMLData xmlModel = null;
XMLData currentNode = null;
try
{
int eventType = parser.getEventType();
while (eventType != XmlPullParser.END_DOCUMENT){
String name = null;
switch (eventType) {
case XmlPullParser.START_DOCUMENT:
xmlModel = new XMLData("root", null);
currentNode = xmlModel;
break;
case XmlPullParser.START_TAG:
name = parser.getName();
if (name != null) {
XMLData dataNode = new XMLData(name, currentNode);
currentNode.mChild.add(dataNode);
currentNode = dataNode;
}
break;
case XmlPullParser.TEXT:
name = parser.getText();
if (name != null) {
XMLData fieldNode = new XMLData(name,currentNode);
currentNode.mChild.add(fieldNode);
}
break;
case XmlPullParser.END_TAG:
name = parser.getName();
currentNode = currentNode.mParent;
break;
}
eventType = parser.next();
}
} catch (XmlPullParserException e) {
Log.e("ParseEx", e.getMessage());
} catch (IOException e) {
Log.e("IOEx", e.getMessage());
}
return xmlModel;
}
So let's back up for a second and look at what this does. We start off by first executing:
This reads off our first tag for the XMLPullParser.what follows is the main while loop.
There are 4 Major event types we are concerned with:
START_DOCUMENT and END_DOCUMENT denote the beginning and end of the document when we get a start we concern ourselves with initializing the XMLData so we can start to build an XML tree.
START_TAG and END_TAG denote when each of the tags expand. On a START_TAG we prepare ourselves to traverse into the ENTRY by creating a new XMLData.
case XmlPullParser.START_TAG:
name = parser.getName();
if (name != null) {
XMLData dataNode = new XMLData(name, currentNode);
currentNode.mChild.add(dataNode);
currentNode = dataNode;
}
break;
dataNode in this case is the newly created node ready for traversal. We then perform currentNode = dataNode remember that we are now traversing down the node.
On END_TAG we do one and only one thing we go up one level from our tree structure. This is accomplished with the following code:
case XmlPullParser.END_TAG:
name = parser.getName();
currentNode = currentNode.mParent;
break;
Finally we have TEXT in which we read off the actuall data of an element:
case XmlPullParser.TEXT:
name = parser.getText();
if (name != null) {
XMLData fieldNode = new XMLData(name,currentNode);
currentNode.mChild.add(fieldNode);
}
break;
Hopefully this tutorial breaks down an easy way to access your XML data. If you want to use XMLData right away you can grab it here! I haven't decided what license I'll release it under but I'm thinking it'll be under the same license as Google SDK.
DOWNLOAD SOURCE
The XMLPullParser works but it’s very bare metal and does leave quite a bit to be desired. So I decided to go ahead and create a generic XML parser that all android developers can use (and improve).
public class XMLData {
public String mValue;
public XMLData mParent;
public ListmChild;
public XMLData(String value, XMLData parent) {
mParent = parent;
mChild = new ArrayList();
mValue = value;
}
}
First we establish a base XML data structure I decided to keep things simple here so I'm not at all doing anything about attributes if you wish to handle attributes you need to add a new ArrayList for attributes.
Now that we have our basic XML data type we can start create a class to read it:
public static XMLData Load(XmlPullParser parser) {
XMLData xmlModel = null;
XMLData currentNode = null;
try
{
int eventType = parser.getEventType();
while (eventType != XmlPullParser.END_DOCUMENT){
String name = null;
switch (eventType) {
case XmlPullParser.START_DOCUMENT:
xmlModel = new XMLData("root", null);
currentNode = xmlModel;
break;
case XmlPullParser.START_TAG:
name = parser.getName();
if (name != null) {
XMLData dataNode = new XMLData(name, currentNode);
currentNode.mChild.add(dataNode);
currentNode = dataNode;
}
break;
case XmlPullParser.TEXT:
name = parser.getText();
if (name != null) {
XMLData fieldNode = new XMLData(name,currentNode);
currentNode.mChild.add(fieldNode);
}
break;
case XmlPullParser.END_TAG:
name = parser.getName();
currentNode = currentNode.mParent;
break;
}
eventType = parser.next();
}
} catch (XmlPullParserException e) {
Log.e("ParseEx", e.getMessage());
} catch (IOException e) {
Log.e("IOEx", e.getMessage());
}
return xmlModel;
}
So let's back up for a second and look at what this does. We start off by first executing:
int eventType = parser.getEventType();
This reads off our first tag for the XMLPullParser.what follows is the main while loop.
There are 4 Major event types we are concerned with:
XmlPullParser.START_DOCUMENT
XmlPullParser.END_DOCUMENT
XmlPullParser.START_TAG
XmlPullParser.END_TAG
XmlPullParser.TEXTSTART_DOCUMENT and END_DOCUMENT denote the beginning and end of the document when we get a start we concern ourselves with initializing the XMLData so we can start to build an XML tree.
START_TAG and END_TAG denote when each of the tags expand. On a START_TAG we prepare ourselves to traverse into the ENTRY by creating a new XMLData.
case XmlPullParser.START_TAG:
name = parser.getName();
if (name != null) {
XMLData dataNode = new XMLData(name, currentNode);
currentNode.mChild.add(dataNode);
currentNode = dataNode;
}
break;
dataNode in this case is the newly created node ready for traversal. We then perform currentNode = dataNode remember that we are now traversing down the node.
On END_TAG we do one and only one thing we go up one level from our tree structure. This is accomplished with the following code:
case XmlPullParser.END_TAG:
name = parser.getName();
currentNode = currentNode.mParent;
break;
Finally we have TEXT in which we read off the actuall data of an element:
case XmlPullParser.TEXT:
name = parser.getText();
if (name != null) {
XMLData fieldNode = new XMLData(name,currentNode);
currentNode.mChild.add(fieldNode);
}
break;
Hopefully this tutorial breaks down an easy way to access your XML data. If you want to use XMLData right away you can grab it here! I haven't decided what license I'll release it under but I'm thinking it'll be under the same license as Google SDK.
DOWNLOAD SOURCE
Monday, June 28, 2010
iTunesMonitor 2.5 (Update)
I've recently updated iTunesMonitor to 2.5 status you can find the original description here (The download link was updated there as well).
The main difference is it now respects Windows 7's UAC controls so no more crashing due to permission issues. Keep in mind you will need .NET framework 4 to run this now.
Among other nice features 2.5 iTunesMonitor finally gives iTunes the ability to work with your media keys even when iTunes does not have focus for those die hard iTunes users.
The system is "install free" meaning as long as you have iTunes installed detection and launching is automatic.
Download iTunesMonitor 2.5
Monday, May 17, 2010
Learning Unity a Beginner's Prespective
First I should probably give everyone a little background. I'm a Programmer by trade not an artist so I approach things from a programming standpoint. Me and a friend of mine recently decided that we would like to make an attempt at producing an indie game title.
After some of the ground work had been established we decided that it's would be an appropriate time to take a look at some toolkits. The Unity Game Engine has been recieving a lot of praise from the indie crowd recently. I felt it was appropriate to at least give it a fair evaluation.
Arriving from a programmer's background the first thing one would notice is that Unity is built somewhere in between the artist and programmer tools. Although I would place unity more heavily towards the artist side of the game development. The first hurdle a programmer will find is that a lot of the terminology is geared towards the artist so it may be hard to figure out what "bones" are or the concept of a "scene" is.
Once you get beyond that and start your own project you find another lacking area of Unity the tutorials seem to span. "This is the UI" and "Here's an advanced tutorial that we expect you to know how to use the toolkit well" but nothing in between. What I was looking for as a coder is "this is your first unity level" but there really wasn't any tutorial that ran you through creating a box with the player in it and giving it some basic lighting.
In this area unit could be improved upon. If the tutorial exists then it really wasn't made that clear where you could go and find it.
As a programmer game development for us works as follows. Build Rough Game Mechanic concept --> Make ugly place holder graphics --> Test game concepts --> Refine and acquire final art assets. Unity however doesn't work this way. Any object you want to put into Unity must be first drawn in your 3D modeller package. Unity does not include any form of "primatives" you can just drop in. This basic disconnect forces people used to the programming model to adhere to the unity work flow model of: Build rough art assets --> Drop into unity --> Attach scripts --> Test gameplay --> Refine models.
Admittedly to non artists this model can seem Alien often times we use code to compensate for the fact that we don't understand how to use all the features of the complex 3D modelling packages such as rigging, bones, mesh deformation, and particle effects.
Overall though for a first look Unity may seem baffling at first but I can definitely see signs that once you get a hold of how to appropriately utilize the tools unity definitely seems to speed up the "concept / code / test" cycle we are used to. I only caution the programmers about to be introduced to this tool to be cautious and be aware that when they first start they will be baffled in what appears to be a tool designed for artists.
Flash programmers would be well aware of this concept that the editor doesn't assist the coders instead it's somewhat expected the coders use their own coding environments to get the job done.
After some of the ground work had been established we decided that it's would be an appropriate time to take a look at some toolkits. The Unity Game Engine has been recieving a lot of praise from the indie crowd recently. I felt it was appropriate to at least give it a fair evaluation.
Arriving from a programmer's background the first thing one would notice is that Unity is built somewhere in between the artist and programmer tools. Although I would place unity more heavily towards the artist side of the game development. The first hurdle a programmer will find is that a lot of the terminology is geared towards the artist so it may be hard to figure out what "bones" are or the concept of a "scene" is.
Once you get beyond that and start your own project you find another lacking area of Unity the tutorials seem to span. "This is the UI" and "Here's an advanced tutorial that we expect you to know how to use the toolkit well" but nothing in between. What I was looking for as a coder is "this is your first unity level" but there really wasn't any tutorial that ran you through creating a box with the player in it and giving it some basic lighting.
In this area unit could be improved upon. If the tutorial exists then it really wasn't made that clear where you could go and find it.
As a programmer game development for us works as follows. Build Rough Game Mechanic concept --> Make ugly place holder graphics --> Test game concepts --> Refine and acquire final art assets. Unity however doesn't work this way. Any object you want to put into Unity must be first drawn in your 3D modeller package. Unity does not include any form of "primatives" you can just drop in. This basic disconnect forces people used to the programming model to adhere to the unity work flow model of: Build rough art assets --> Drop into unity --> Attach scripts --> Test gameplay --> Refine models.
Admittedly to non artists this model can seem Alien often times we use code to compensate for the fact that we don't understand how to use all the features of the complex 3D modelling packages such as rigging, bones, mesh deformation, and particle effects.
Overall though for a first look Unity may seem baffling at first but I can definitely see signs that once you get a hold of how to appropriately utilize the tools unity definitely seems to speed up the "concept / code / test" cycle we are used to. I only caution the programmers about to be introduced to this tool to be cautious and be aware that when they first start they will be baffled in what appears to be a tool designed for artists.
Flash programmers would be well aware of this concept that the editor doesn't assist the coders instead it's somewhat expected the coders use their own coding environments to get the job done.
Sunday, January 03, 2010
Game Developments Thoughts
I haven't updated here in a while I've recently been busy with my current employer developing a casual video game for the PC market. A lot of details are NDA so I'll try and keep that info from landing on here.
Suffice to say after several tech considerations we decided that the most appropriate platform (read not best) would be flash with action script 3.
In the last month I've been plagued with flash surprises that just astound me. For one flash is the only language that when you add an object that's already on the stage to another container that's also on the stage the original reference disappears from the first container?! This is a bit of an oversight since you will no longer be able to do instancing. Worse still there's no built in .clone operation for display objects so you'll have to start writing your own workarounds for this. Again oversight.
Performance wise we've been discovering flash isn't great for example one effect we wanted to do is a full screen lens blur. To make the CPU requirements low we decided we were just going to pre-process a blurred version of the image and alpha blend the clear version into the blurred one... Guess what full screen alpha blending with 2 images on flash is painfully slow and we had to ditch the idea, in favor of a static staged blend animation.
Progress on this project is pretty good everything is on schedule I'll be throwing in more of the art assets this week. The game is starting to finally look right moving past just a mechanical place holder and starting to take the final form of the game.
There's a lot of "what flash doesn't have this?" that I've been collecting I'm going to see if I can post some here and discuss why it feels like an oversight.
Suffice to say after several tech considerations we decided that the most appropriate platform (read not best) would be flash with action script 3.
In the last month I've been plagued with flash surprises that just astound me. For one flash is the only language that when you add an object that's already on the stage to another container that's also on the stage the original reference disappears from the first container?! This is a bit of an oversight since you will no longer be able to do instancing. Worse still there's no built in .clone operation for display objects so you'll have to start writing your own workarounds for this. Again oversight.
Performance wise we've been discovering flash isn't great for example one effect we wanted to do is a full screen lens blur. To make the CPU requirements low we decided we were just going to pre-process a blurred version of the image and alpha blend the clear version into the blurred one... Guess what full screen alpha blending with 2 images on flash is painfully slow and we had to ditch the idea, in favor of a static staged blend animation.
Progress on this project is pretty good everything is on schedule I'll be throwing in more of the art assets this week. The game is starting to finally look right moving past just a mechanical place holder and starting to take the final form of the game.
There's a lot of "what flash doesn't have this?" that I've been collecting I'm going to see if I can post some here and discuss why it feels like an oversight.
Wednesday, September 02, 2009
Finishing up Grad Studies
Well finally the end is in sight one way or another the graduate degree chapter will be over. Right now there's a lot of back and forth as final corrections are being thrown around and a committee is being put together.
I personally am a little bit panicky from time to time because I feel that I'm behind schedule but that is most likely because I like to finish things ahead of schedule so I schedule things in such a way that it will happen.
I'm hoping by next week I'll have a more accurate idea of when is the exact day I will be finishing. I hope everything is in order so schedules for post-graduate activities don't have to be pushed back.
I am looking quite intently at the beginning of my career post graduation a lot of exciting stuff coming up looking forward to it all.
I personally am a little bit panicky from time to time because I feel that I'm behind schedule but that is most likely because I like to finish things ahead of schedule so I schedule things in such a way that it will happen.
I'm hoping by next week I'll have a more accurate idea of when is the exact day I will be finishing. I hope everything is in order so schedules for post-graduate activities don't have to be pushed back.
I am looking quite intently at the beginning of my career post graduation a lot of exciting stuff coming up looking forward to it all.
Tuesday, May 26, 2009
iTunes Monitor
iTunes on the PC is quite popular but iTunes has a nasty habit of more often than not eating up way too many resources even while it's not running.
The culprit?
iTunes needs several services that it doesn't shutdown when it closes these are:
iTunesHelper
iPodService
AppleMobileDevice
BonjourService
(and a few others)
I found this unacceptable so I wrote a little program I call the iTunesMonitor. It's sole job is to set all these services to manual so you don't get them on startup and to launch them when it's started and then launch iTunes once all the services are up.
The program then sits idle in the background checking every 5 seconds to see if iTunes is closed. When it sees this it will immediately clean up any remaining services.
What about the media keys they don't seem to work one you don't have iTunes in focus. Well since my program has to sit in the background and wait for iTunes to close anyways I felt that I should fix the way media keys behave. Now iTunes will respond to media keys regardless of if it's in focus or not and the media keys are unregistered when the program is closed.
Try iTunesMonitor for yourself. It requires no configuration other than an installation of iTunes. It will automatically detect your installation of iTunes and launch it along with the supported services. No configuration is required however it is recommended you replace the iTunes icon in your start menu with the iTunesMonitor for transparent operation.
Download iTunesMonitor 2.5
Thursday, May 07, 2009
ToJam 2009
Tojam 2009 concluded last Sunday. By far ToJam is the craziest most fast paced game development competition around. Teams and individuals try and put a game out from scratch in just 3 days.
Most teams work around the clock forgoing sleep to nurture their creations.
Team AnyKey pictured here this year went with a very ambitious project, and some members including myself are still spending a few hours a week tuning the final result for the arcade.
There were many days where we went from Extreme coders to musicians to artists in a way ToJam is less about what you know and more about raw talent. To anyone thinking of going to ToJam but fear they won't place, come anyway! Part of the joys of ToJam is being around great people doing what you love and learning in the process.
There were plenty of awesome games to be seen many of them way too good for you to feel like they could've been created in 3 days.
I can't credit these pictures above they were taken by David Vanvliet, another participant at the event.
Tuesday, April 28, 2009
A Better Game Sound Engine For AnyKey tojam#4
Today I had a thought about something quite interesting leading up to our game competition. Since none of us are music experts and all music loops are quite short and designed to be connected to each other I'm proposing a very interesting change to our game music engine.
Our original music engine was monolithic as in it only played one massive track.
< Level >
[Songfile]
We could in simple terms switch to a basic shuffle system
< Level >
[songfile1][songfile2][songfile3][songfile4][songfile5]
But then I thought of a much better idea which I hope to be able to be able to implement today or tomorrow. Each song data will consist of 2 parts the track itself and a linked list reference to another part. Music then becomes a sort of directed graph with cycles. Edges then can be taken randomly. This kind of thing is better explained with a picture.
The advantage to using this system is that we can prevent one obvious section from continuously looping and we can enforce tracks that sound better after each other to happen. The end result is a pseudo-random music that will make the listener think it's more intelligent than it is.
Auto-generated in game music
Today I had a thought about something quite interesting leading up to our game competition. Since none of us are music experts and all music loops are quite short and designed to be connected to each other I'm proposing a very interesting change to our game music engine.
Our original music engine was monolithic as in it only played one massive track.
< Level >
[Songfile]
We could in simple terms switch to a basic shuffle system
< Level >
[songfile1][songfile2][songfile3][songfile4][songfile5]
But then I thought of a much better idea which I hope to be able to be able to implement today or tomorrow. Each song data will consist of 2 parts the track itself and a linked list reference to another part. Music then becomes a sort of directed graph with cycles. Edges then can be taken randomly
Our original music engine was monolithic as in it only played one massive track.
< Level >
[Songfile]
We could in simple terms switch to a basic shuffle system
< Level >
[songfile1][songfile2][songfile3][songfile4][songfile5]
But then I thought of a much better idea which I hope to be able to be able to implement today or tomorrow. Each song data will consist of 2 parts the track itself and a linked list reference to another part. Music then becomes a sort of directed graph with cycles. Edges then can be taken randomly
ToJam 09 (pre-event info)
ToJam #4 is taking place this weekend from Friday to Sunday. I always enjoy this event but there are currently a few lingering issues:
1. The organizers via twitter have already stated that there is no wired internet and there might not be wireless.
When someone says might not be wireless, what they mean is some fool forgot to secure their open wi-fi and it's now going to be bombarded by 100 participants of the event. The organizers are looking into tethering but I doubt one device will be able to support the rates required for things like downloading art assets or free soundtracks.
For that reason our team is considering also having a tethered option for this event.
I'd personally imagine teams by now will have their game idea done, and I'm hoping there won't be any of that "tape giant sound blaster posters on the sun facing window" fiasco we had last year.
Hopefully mickey the mouse was cleaned up too.
At the same time team Any Key this year will probably not bring a mountain of snacks making us by far the snack team.
Currently I'm debating if I should bring my linux box to the event with it's sole purpose to act as a GIT repo
1. The organizers via twitter have already stated that there is no wired internet and there might not be wireless.
When someone says might not be wireless, what they mean is some fool forgot to secure their open wi-fi and it's now going to be bombarded by 100 participants of the event. The organizers are looking into tethering but I doubt one device will be able to support the rates required for things like downloading art assets or free soundtracks.
For that reason our team is considering also having a tethered option for this event.
I'd personally imagine teams by now will have their game idea done, and I'm hoping there won't be any of that "tape giant sound blaster posters on the sun facing window" fiasco we had last year.
Hopefully mickey the mouse was cleaned up too.
At the same time team Any Key this year will probably not bring a mountain of snacks making us by far the snack team.
Currently I'm debating if I should bring my linux box to the event with it's sole purpose to act as a GIT repo
Friday, January 18, 2008
NSERC!
Got a big meeting for NSERC with a local motion picture company (random) the proposal is to design a haptics device that will be able to provide a full upper body level of force feedback.
So when you bump into a wall you'll feel it on your shoulder and when you bump into a person you'll feel it, when you walk past someone too close you'll feel them brush by. Another application is video games if you get shot you'll feel from where or if your in a racing simulator (like the big blue one at McMaster) we can simulate you bumping up against the seats.
There's a lot of possibilities with this device part of the meeting will be focusing on what the vision is for this project. Should be fun I look forward to consulting with 5 ppl that have come in from the office to meet on McMaster.
So when you bump into a wall you'll feel it on your shoulder and when you bump into a person you'll feel it, when you walk past someone too close you'll feel them brush by. Another application is video games if you get shot you'll feel from where or if your in a racing simulator (like the big blue one at McMaster) we can simulate you bumping up against the seats.
There's a lot of possibilities with this device part of the meeting will be focusing on what the vision is for this project. Should be fun I look forward to consulting with 5 ppl that have come in from the office to meet on McMaster.
Friday, December 07, 2007
Final exams
Well would you look at that it's final exams already, crazy time of year where everything is upside down and it's a last chance to either make things work or hard code them to work.
I haven't been updating this blog this year as often as I like but I'll be doing some backlog of updates over the Christmas break, mainly to do an update on my newest project a TF2 level. Might turn into a semi tutorial while I'm at it.
I haven't been updating this blog this year as often as I like but I'll be doing some backlog of updates over the Christmas break, mainly to do an update on my newest project a TF2 level. Might turn into a semi tutorial while I'm at it.
Tuesday, October 23, 2007
It's alive
Today I managed to get things going with the compilation and had the robot running around the lab with existing code. Also did some modifications to the code base in order to use FPS style controls.
What's a bit strange is that this robot actually has worse straight line driving than our thesis bot at the moment. So I'm preparing to perform several upgrades to the robot base driving code in order to match the thesis bot driving as it should preform better since every component is much more accurate and faster on this robot.
One thing that stands out is that MvM choose to use a full PID controller where in our thesis project we eventually dropped the PID in favor of just plain PI due to the negative effect of the D component.
At startup currently the robot violently oscillates before it's able to find some sort of steady state, I'm pretty sure this is because he doesn't bother removing the D component on first run this would cause the robot to cacluate d(off center) / dt where dt = 0, whick would create a violent oscillation as we briefly get infinity.
To confirm the problem I'll be turning off the D component and checking the behaviour of the system. If I get more stable behaviour I'll try and fake dt for the initial run giving it some effectively high value such as 100 to minimize the effect of the D component when calculated at the beginning. This should be easier and preform better than some branching code where we don't use dt at the initial run.
Our thesis bot was smart enough to self calibrate, this was done by running the motors for a set distance until steady state was reached in our PI controller. The accumulator for the I component was then exported to the system for later use thus when the robot is run the next time it would start closer to steady state. This is because we know that if motor A is less powerful than motor B it's quite likely that that doesn't change between runs in that motor A will always be more powerful than motor B by close to the same amount. If we see that last time we needed to send less power to the motor A and more the B in order for them to match speed and we record what this power difference is, than we could use it again and chances are we get pretty close to perfect movement again.
There was a more advanced version of self calibration to implement on our thesis bot but eventually gave up because the bot was too limiting. Even though we know the robot motors were off by certain power levels the recorded values are for the system when it's "at speed". While the robot is accelerating these power levels might not be accurate. A more advanced system I might try is to take readings at different speeds and derive a linear or polynomial approximation for the power curve required to seed the system while it ramps up, the disadvantage here is the system will be "floating" as each interpolating point will change during the run as each new power level is achieved. Unfortunately the only way to determine the ramp up power difference is to run tests and premodel the system rather than dynamically build a model inside the system itself.
Essentially what we are trying to do with advanced calibration is to scale Ki component of the PID controller proportional to the system speed so that Ki is small when the system is running slow and Ki is large when the system is running at higher speeds, or in other words Ki will try and effect the system proportional to the speed it's at. I have a theory this might be pointless but I'll need to model it to find out if that's so, as I builds fast when the wheels are spinning fast and I builds up slow when the wheels are spinning slow anyways. This side effect might end up being the same as if I scaled Ki.
The final method is to take our advanced telemetry engine (which was also unimplementable) where we calculate the error based on error = dy/dt where dy/dt represents the deviation from center. This is a strange approach but we actually work with physical distances rather than ticks, I'm still unsure how different this will be from our original ticks model since essentially in the ticks model I do close to the same thing except I measure if one wheel spun more than the other. Not how far I'm from the centreline this last method will be implemented ifjavascript:void(0)
Publish Post I can prove that it'll provide substantially better results than the current method.
Ok that's enough thoughts for today.
What's a bit strange is that this robot actually has worse straight line driving than our thesis bot at the moment. So I'm preparing to perform several upgrades to the robot base driving code in order to match the thesis bot driving as it should preform better since every component is much more accurate and faster on this robot.
One thing that stands out is that MvM choose to use a full PID controller where in our thesis project we eventually dropped the PID in favor of just plain PI due to the negative effect of the D component.
At startup currently the robot violently oscillates before it's able to find some sort of steady state, I'm pretty sure this is because he doesn't bother removing the D component on first run this would cause the robot to cacluate d(off center) / dt where dt = 0, whick would create a violent oscillation as we briefly get infinity.
To confirm the problem I'll be turning off the D component and checking the behaviour of the system. If I get more stable behaviour I'll try and fake dt for the initial run giving it some effectively high value such as 100 to minimize the effect of the D component when calculated at the beginning. This should be easier and preform better than some branching code where we don't use dt at the initial run.
Our thesis bot was smart enough to self calibrate, this was done by running the motors for a set distance until steady state was reached in our PI controller. The accumulator for the I component was then exported to the system for later use thus when the robot is run the next time it would start closer to steady state. This is because we know that if motor A is less powerful than motor B it's quite likely that that doesn't change between runs in that motor A will always be more powerful than motor B by close to the same amount. If we see that last time we needed to send less power to the motor A and more the B in order for them to match speed and we record what this power difference is, than we could use it again and chances are we get pretty close to perfect movement again.
There was a more advanced version of self calibration to implement on our thesis bot but eventually gave up because the bot was too limiting. Even though we know the robot motors were off by certain power levels the recorded values are for the system when it's "at speed". While the robot is accelerating these power levels might not be accurate. A more advanced system I might try is to take readings at different speeds and derive a linear or polynomial approximation for the power curve required to seed the system while it ramps up, the disadvantage here is the system will be "floating" as each interpolating point will change during the run as each new power level is achieved. Unfortunately the only way to determine the ramp up power difference is to run tests and premodel the system rather than dynamically build a model inside the system itself.
Essentially what we are trying to do with advanced calibration is to scale Ki component of the PID controller proportional to the system speed so that Ki is small when the system is running slow and Ki is large when the system is running at higher speeds, or in other words Ki will try and effect the system proportional to the speed it's at. I have a theory this might be pointless but I'll need to model it to find out if that's so, as I builds fast when the wheels are spinning fast and I builds up slow when the wheels are spinning slow anyways. This side effect might end up being the same as if I scaled Ki.
The final method is to take our advanced telemetry engine (which was also unimplementable) where we calculate the error based on error = dy/dt where dy/dt represents the deviation from center. This is a strange approach but we actually work with physical distances rather than ticks, I'm still unsure how different this will be from our original ticks model since essentially in the ticks model I do close to the same thing except I measure if one wheel spun more than the other. Not how far I'm from the centreline this last method will be implemented ifjavascript:void(0)
Publish Post I can prove that it'll provide substantially better results than the current method.
Ok that's enough thoughts for today.
Wednesday, September 05, 2007
Online and on time
One thing I like about being with a DSL service is if they say your line will be up at a certain time, most of the time it will.
After debating with the Installer today about the questionable nature of the wiring in this apartment we are finally online and kicking with bell DSL.
What's more amazing was that the activation cost for the dry loop was only $1.22 That's right I saw on my invoice I was deducted $10 promo, $6 rebate, and a few other misc savings for being an existing member. That's just awesome.
Bell surprises you with charges you don't have to pay where cogeco would just surprise you with incidental charges.
So the total cost of activation so far is $20 for buying the modem and $1.22 for the install.
Currently the line rates are 3008bps down 800bps up. Pretty awesome all things considered. I did need to make an extra run to the local shop to exchange the initial modem which was defective, I guess that's a crap shoot anyways.
After debating with the Installer today about the questionable nature of the wiring in this apartment we are finally online and kicking with bell DSL.
What's more amazing was that the activation cost for the dry loop was only $1.22 That's right I saw on my invoice I was deducted $10 promo, $6 rebate, and a few other misc savings for being an existing member. That's just awesome.
Bell surprises you with charges you don't have to pay where cogeco would just surprise you with incidental charges.
So the total cost of activation so far is $20 for buying the modem and $1.22 for the install.
Currently the line rates are 3008bps down 800bps up. Pretty awesome all things considered. I did need to make an extra run to the local shop to exchange the initial modem which was defective, I guess that's a crap shoot anyways.
Subscribe to:
Posts (Atom)
-
Here's a linux utorrent script so you can start utorrent server like a service on linux machines! Currently tested working on ubuntu a...
-
It's time to switch up the wallpapers again so I've come up with a new concept for everyone to enjoy Hex WallPapers (in the same vei...