Sunday, May 12, 2013

Removing Unity Global Menus, Scroll Bars, Dock and returning to GNOME 2-esque Ambiance or Radiance

I'm back from the dead, after a couple years of not posting, and I'm here today to give you my current script to "fix" Ubuntu 12.10 Quantal Quetzal and 13.04 Raring Ringtail.  This script removes Unity's Global Menus, Overlay Scroll Bars, and Dock, and returns to a more GNOME 2-style look while still supporting the Ambiance or Radiance theme.

Download

This is provided AS-IS, without any guarantees of any particular outcome. Please read "what does it do" so you know what you're getting into before you run this:

http://855nerdfix.com/userfiles/fixunity.sh

What does it do?



  • Adds a new session type called "Discord"
  • Replaces Unity's top panel with GNOME Panel 3.  This is not a reversion to GNOME 2's Panel, but the much better version 3 panel which goes mostly unused from what I see. You will notice one major difference from version 2 - you have to hold in Ctrl+Super in order to right click and edit the panel's composition or arrangement.
  • Replaces Unity's left panel with Docky as a bottom panel.
  • Removes Global Menus.
  • Removes Overlay Scrollbars.
  • Steals ALT+F1 and ALT+F2 back from Unity and gives them to the Applications menu and the Run Application dialog box.
  • Installs Pidgin (because why not?)
  • Configures some sane defaults for Compiz.
  • Installs Applet Indicator Complete plugin on the top panel. This gives the Panel the ability to use Ubuntu's sexy Mac-like indicators and clock area and system menu.
  • Please be aware that this script will turn off the Global Menu and Overlay Scrollbars even for your Unity session type.

How to Use FixUnity

  1. Download the script from the link above.
  2. Set execute permissions on the script.
  3. Run it.
  4. After it completes, log out of your session, and before logging back in, choose "Discord" as your session type.
  5. Log in, and wait while the initial login reconfiguration happens.
  6. Enjoy Ubuntu the way it should have been.
Good luck!

Help Me!

If the script completes and you log into the new session type, and the outcome isn't very similar to the screenshot pictures above, let me know what happened and let's figure out how to fix it.  I am open to suggestions on how to improve this.

Recent Changes

0.82 - Renamed session type from "Docky" to "Discord" to more represent what I'm trying to accomplish. (This tool is still useful even if you remove Docky from auto start-up and run Gnome Panel only!)

0.81 - Fixed some Compiz settings that weren't applying properly due to the migration to dconf since I first wrote the script.

0.8 - First public release for Ubuntu 12.10 or 13.04.

Wednesday, February 23, 2011

Google vs Bing

As a computer instructor, I am often asked why I prefer Google over Yahoo or Microsoft's search engine (whatever they are calling it this year).  80% of the world uses Google, which can be a little scary to think about.  It would be so easy for them to abuse their power.  I will be the first to admit that they have gotten a little less cool in the last five years, and I wish they had an advanced version that had less hand-holding and would let me just get on with my searches, but even with all that, Google is miles above their competition in a few key areas.  (I'm not going to really talk about Yahoo here, they have about the same market share as Microsoft, but they have too many ads and they don't try very hard to make their search better than any one else's)

No matter how "evil" Google gets, rest assured that Microsoft has done worse.  I should give some of Microsoft's history on here sometime, that would be fun.  Let's just say that you don't get to the top of the Business software game by being nice.

Google still has a sense of humor, although it's been getting dimmer over the years, and their April fools jokes are more about highlighting their newest product than having fun, and the Google Doodles are more about public relations than about celebration.  But, compared to any of the older corporations, Google is as playful as a puppy.

Google is a friend to Linux and Mac.  Because of the other markets that Microsoft is in, they cannot afford to be nice to Linux or Mac, and the more "features" they have that are incompatible the more people who will be unhappy with a move away from windows.  Enter Silverlight, .Net, ActiveX and all of their other web products.  Try using IE9 on anything but the newest Windows.  And, I'm using Google Chrome on my Ubuntu box to write this post.

Lastly, Google's results are better.  I have a fun example for you all, and I know it's nothing but one example, but it shows what each company thinks of getting relevant search results to the user, and really, at the end of the day, that's what we are all looking for.

I did a straight image search for the word rose, and then added the color filter of green, and here are the results:

Bing has ONE green rose out of fifteen results.  You get better results searching for green rose in the first place and ignoring the color filter.

Google has twelve green roses, two pictures from the movie Green Rose, and ONE rose that is not green.

Like I said, this isn't a rigid test, just one example I stumbled on while working on a lesson plan.

Saturday, January 8, 2011

2D Games with Kitten-Fu, Part Three

Alright, so last time I promised you a second cat and some grass for them to walk on. When I originally got this far in my program I just copied and pasted and created a few if statements in order to take care of the second cat, but instead I'm going to use objects because they are going to be more efficient in this case (where the cats aren't significantly different in how they behave.)
Kitten-Fu is at version alpha 17 now, which is what i will be using for this tutorial. The earlier and later versions should be 100% compatible with what we have done so far.

The Sprites


We have two sprites to create before we work on the next bit of programing. The first is a copy of our first cat with some coloring changes. I also changed the head shape and the way the tail waves-this way they will both have a little different character without needing to re-do all that animation work from earlier.


Next, I'll make a ground sprite. I'm not really happy with the way this turned out. I'm thinking of making a new sprite that is just grass and will be placed higher on the screen along with a second sprite of just dirt at the bottom to give it that street fighter pseudo 3D feel. Remember, I am sticking to 4 colors per 16x16 block to help keep the 8bit retro style. Also remember that transparent counts as a color.


The Code


Let's start with adding the ground tile, since that's pretty simple. First create the ground stamp:

stamp ground("ground.png");
No need to worry about slicing it at this point. When we have more variety then we can convert it, but for now a stamp will work just fine.

Next, let's add a for loop that utilizes the stamp we just created and place it at the beginning of our painting section (after we clear the screen, of course)

  for (int i = 0; i < 8; i++) {
ground.put(i*16, 104);
}

If you compile your program now, it should display the ground tiles across the bottom of the screen.

So far we have just been using structured programing, meaning the code just goes through in order what we told it to do without employing any fancy code. We're going to get a whole lot fancier in just a bit. The next thing we are going to do is add a second cat. We COULD just copy our code and rename all of our variables with a 1 and 2 after them, but what if we need to add a third or fourth cat? (for example if we were making a kitteny RPG) That would get old really fast as we duplicated all of our code four times. So, to solve that we are going to employ classes.

I'm going to move all of the code having to do with the cat logic and painting into a kitten class. Since I am still fairly new to object oriented programing, I don't really feel like I can explain what I'm doing in very high detail, so I'm just going to show you what I ended up with.

If you don't know what a class is, you can think of it as a cookie cutter that you create with its own variables and functions (these have different names when they are a part of a class ... whatever) Once we have the class/cookie cutter set up, we can use it to create instances of our class (the actual cookies). This way, we can tell the program what a cat should look like and then make as many as we need with minimal needless duplication of code.

If you know HTML at all, this has the same function as CSS does, it's f*ing amazing and lets you do all sorts of cool things to control all your similar processes all at once.

Without further ado, let's look at the kitten class code (this goes right after we include KFu on line 5.) Actually, I take that back, I'm going to be converting the code into object orientedness in two passes. This first will be the game logic, the second will be the painting portion which I will cover in more depth than the game logic. okay, for real this time:

int framecount = 0;

class kitten {
public:
int kx;
int ky;
int walkleft;
int walkright;
int facing;
kitten();
void step();
private:
};

I made framecount into a global variable for now and changed the k1x and k1y variables into just kx and ky (make sure they get changed in all the places you were using them!)

Next, let's make the constructor:

kitten::kitten() {
kx = 110;
ky = 88;
walkleft = 0;
walkright = 0;
facing = 0;
}

You'll notice that the above code was basically used to declare and initialize the variables that we're using in this class. Go ahead and delete the duplicate variables at the top of main().

At this point we need to create an instance of our kitten class in main(). I'm going to call it kitten1, but you can name it anything you like. Since we are going to add the paint routine to the class, we will need to call it after we create the screen, so go ahead and add this:

  kitten kitten1;

And now let's make a method (it's basically a function) which will take our actual game logic code that we reference the kitten in and make it available to use with the class:

void kitten::step() {
if (framecount%2 == 0) {
if (walkleft == 1) {
kx = (kx - 1);
if (kx < -16) { kx = 128; }
}
if (walkright == 1) {
kx = (kx + 1);
if (kx > 128) { kx = -16; }
}
}
}

Again, you'll want to delete the code that we have now duplicated and replace it with the following:

  kitten1.step();

Before we're done, take a look at the SDL input handling. We use walkleft, walkright and facing there ... we'll need to point these to our kitten1 instance of the kitten class by adding kitten1. in front of each variable.

Okay! Go ahead and compile your code and make sure it still runs at this point before you continue. If you get an error, read it and take a good look at the line number it gives (if it gives one). Make double sure that you didn't leave anything important out like a semi-colon or a brace. If you still can't get it to compile, take a look at the sample code at the end of this post - we are doing some major revisions to the structure of the code and that can be a little confusing at times.

Once you have your code compiling and running again, let's break it again! we're going to turn the painting routine into another method in our class.

Before we start, we need to change the way we declare our slices and stamps again so that we can separate them into variable declarations and variable values just like we did with the other variables.

  stamp* sprites;
sprites = new stamp("kitten1.png", KFU_LOAD_FLIPH | KFU_LOAD_NORMAL);
slice* stand;
stand = new slice(*sprites, 0, 0, 16, 16);
slice* walk[4];
walk[0] = new slice(*sprites, 16, 0, 16, 16);
walk[1] = new slice(*sprites, 32, 0, 16, 16);
walk[2] = new slice(*sprites, 48, 0, 16, 16);
walk[3] = new slice(*sprites, 32, 0, 16, 16);
I also got rid of the kitt1 from the name of the variables since that won't make a lot of sense when it is part of a generic class.

So, what are those asterisks that we added to our code for? They are memory pointers that we are using to separate the variables. Jeff is possibly changing kfu to make this easier, so I'm not going to try and explain it :-) If you want to know more, read a good introduction to pointers in c++.

Next, we should add the following to the private section of our class:

  stamp* sprites;
slice* stand;
slice* walk[4];

And the following to our constructor:

  sprites = new stamp("kitten1.png", KFU_LOAD_FLIPH | KFU_LOAD_NORMAL);
stand = new slice(*sprites, 0, 0, 16, 16);
walk[0] = new slice(*sprites, 16, 0, 16, 16);
walk[1] = new slice(*sprites, 32, 0, 16, 16);
walk[2] = new slice(*sprites, 48, 0, 16, 16);
walk[3] = new slice(*sprites, 32, 0, 16, 16);

Now, we need to make a method that replaces the painting code:

void kitten::paint() {
if (walkleft == 1) {
walk[anim4]->put(kx, ky);
} else if (walkright == 1) {
walk[anim4]->put(kx, ky, KFU_PUT_FLIPH);
} else {
if (facing == 0) {
stand->put(kx, ky);
} else {
stand->put(kx, ky, KFU_PUT_FLIPH);
}
}
}

Since we use the variable anim4 in our class method, let's make it a global variable next to framerate for now. And then of course delete the original painting code and point to the class method with the following:

  kitten1.paint();

Pretty cool, huh? Make sure your code still runs and debug as necessary.

wooo .. let's take a deep breath and take a look over all the code. Clean up any extra spaces and comment as necessary. Make sure you understand and recognize all of the various parts of the program still.

Now for the fun part, let's add that second kitten!

Tuesday, December 7, 2010

2D Games with Kitten-Fu, Part Two

When we left off in part one, you should have had a kitten that skated across the screen forward and backward. This would be awesome for a hover ship, but let's animate our little cat so that its legs move while it is walking. (oh, I'm also using the KFu alpha 13 library now)

The Sprites


We're going to use a sprite sheet for our cat, so that means adding all of our cat's various poses to a single .png file. I'm going to limit myself to 16x16 for each of the kitten's poses, that way I don't have to keep track of what size I made what, and it helps with the retro look too. Kitten-Fu allows you to specify any size you choose, just make sure you keep good track of your sprites if you make them irregular.


You can see four poses of my cat here. The first is the original position from part one, the second is with the right legs extended, the third is with all four legs in the middle. I was purposely vague on which leg was in front for this middle pose so that I didn't need to draw a second center pose. The last position is with the left legs extended. It took me quite a while to get the animation correct. If you are drawing your own sprites, I would recommend that you get the basic shape you want, then code the animation sequence, and then fine tune it when you can see the changes in action. I used a couple of YouTube videos to help me get the leg shapes correct.

My first attempt at animating my cat was in the middle of the night while I was almost asleep. I'm including it here as an example of what not to do!


The Code


So far we've only been working with a KFu stamp, and we really haven't tapped its full potential at all. One of the cooler things a stamp is good for is making "slices". A slice is a piece of a stamp that is cut out and used as a sprite the same way we used the stamp in part one. What makes a slice special is that it doesn't take up more space in memory to use it. We can load one sprite sheet, and then cut multiple slices from it, creating a veritable cornucopia of sprites on the actual screen!

After we add the new kitten poses, we can leave our stamp code the same, but we're going to add our slice code underneath:

  slice kitt1stand(kitt1, 0, 0, 16, 16);

We'll also want to change where we put the kitt1 stamp to refer to the slice instead:

  kitt1stand.put(k1x, k1y);

Now we're going to use an array of slices for our animated kitten. An array is a way to give a list of items numbers rather than names--this can be quite handy as we will see in a moment. In this case, we're going to pre-load all four frames of our animation, and save them as slices.

  slice* kitt1walk[4];
kitt1walk[0] = new slice(kitt1, 16, 0, 16, 16);
kitt1walk[1] = new slice(kitt1, 32, 0, 16, 16);
kitt1walk[2] = new slice(kitt1, 48, 0, 16, 16);
kitt1walk[3] = new slice(kitt1, 32, 0, 16, 16);

You can see that for each slice above (for the animation and the first pose in kitt1stand) there are a couple different parts:

kitt1stand or kitt1walk[x] are both slice names that we use later to call them into use, and after that are our options in the parentheses. kitt1 refers to the stamp that we set up earlier on line 12 of part one. The series of numbers refer to the x-position and y-position (the top left corner of the slice), and the height and width of the slice. Of course the slices could overlap if we wanted them to, but for now that would make our cat look like a mutant.

We can't just replace kitt1stand with kitt1walk, otherwise our kitten would be animated even while it was standing still, so we need a way to tell if the cat is moving, and only show the animated slice array while that is true.

We already have a walkleft and a walkright variable that is set to true while the cat is moving, so we can just multi-purpose them! The way we're going to solve our animation problem for now is to set a counter that will rotate through the numbers 0-3 every x frames. We'll feed this number into the kitt1walk array and this will flip between all of the slices of the array in order. Add the following code right before you clear the display and begin painting. (and, don't forget to add any relevant variable declarations at the top of the program!)

  // ANIMATION //
if (framecount%8 == 0) {
++anim4;
if (anim4 >= 4) {
anim4 = 0;
}
}

Then, to make the counter tick, add the following to increment the frame counter every time through the game loop (I added it directly underneath the GAME LOGIC heading.)

  ++framecount;

We can re-use this counter for anything that we want to also run with four frames, as long as we don't mind that it is running in tandem with our cat.

Now that we've set up our animation, let's get it painted to the screen. Add a /// PAINTING /// heading underneath the animation code, and let's add some if statements around where we put kitt1stand. Basically, if walkleft or walkright equal 1, then we display kitt1walk, otherwise we display kitt1stand. I could write out the code for this a little more compactly than I have it below, but since we are about to add flipping, this sets up our statement nicely for that:

  if (walkleft == 1) {
kitt1walk[anim4]->put(k1x, k1y);
} else if (walkright == 1) {
kitt1walk[anim4]->put(k1x, k1y);
} else {
kitt1stand.put(k1x, k1y);
}

If you make your program at this point, you'll notice that the cat, although animated, moves way too fast (even for a ninja cat.) We need a way to slow that kitten down. How about a throttle on the game process? every x frames, we will register a movement. If we were working with smaller pixels, this would be less of a problem, but when your cat moves at 30 pixels per second, and your screen is only 128 pixels across ...

In the GAME LOGIC section, underneath the frame counter, let's stick our movement controls into a throttle of sorts:

  if (framecount%2 == 0) {

Now when you make the file, the cat walks slower but, especially if you're on an older / slower computer, you'll notice that the cat fluctuates in speed depending on your CPU usage. That's because I forgot that we need to use KFu's FPS thingy. To set it up, we need to add the following lines to the top of our actual game code, right after we finish declaring our variables and slices.

  fps framerate(1000/30);
framerate.start();

Then, at the bottom, right before we flip to the screen, add the following:

  framerate.delay();

we could have named framerate anything, and set the speed to anything we wanted. I can imagine that you could change this number for underwater scenes, or something like that.


Everything should work now except for the fact that your cat can only face one direction! Let's fix that (although, the moonwalking kitten is pretty cool.)

KFu already has options set up to allow for flipping, all we need to do is activate them. First, we need to create a flipped "instance" of our stamp. This creates a complete copy of the stamp in the memory, so don't flip or rotate more than you'll actually need for your program.

Your new stamp declaration should look like this:

  stamp kitt1("kitten1.png", KFU_LOAD_FLIPH | KFU_LOAD_NORMAL);

FLIPH is for flip horizontal, and then NORMAL is so you can load the regular file. If you don't declare any positional variations, KFu assumes you only wanted NORMAL, but as soon as you start declaring variations, you have to tell it exactly what you want.

Do you remember where we made our if statement a bit long winded for our cat animation? Change your slice code to the following for when the cat is walking right:

    kitt1walk[anim4]->put(k1x, k1y, KFU_PUT_FLIPH);

Now, the only remaining 'error' is when your cat stops walking, it always faces left ... Using a variable on the key presses, see if you can flip kitt1stand to face the correct direction after he finishes walking. I have a solution in the code included at the bottom of the post--see if you can figure it out without looking.

So, I lied about showing you how to add another cat, that will have to wait until part three. We'll create a kitten object, and work on the logic that will make kitten-2 follow kitten-1, as well as some grass for them to walk on.

The Files


You can download everything from part 2 here: kittens-02.tar.gz

* * *

Friday, December 3, 2010

2D Games with Kitten-Fu, Part One

As part of the UVOG arcade project, Jeff has been working on a 2d graphics library for C++ called Kitten-Fu. It's cute and fuzzy like a kitten but powerful like a ninja ...

I'm going to be using Kitten-Fu (KFu) and other open software to create a retro, side-scrolling game about ... what else, ninja cats.

As a way of introduction, I am a novice programmer who has dabbled in PHP and AVR Assembler. I'm going to be blogging my very first C++ program during this series.

First, we need to install the KFu library. KFu has a couple of dependencies, so make sure you install them first:

$ sudo apt-get install build-essential libsdl1.2debian libsdl1.2-dev libsdl-image1.2 libsdl-image1.2-dev

Once you have that, go to the Kitten-Fu wiki page and download the latest version of the library. I'm going to be using KFu alpha 10 to start with. After you have the file downloaded, extract it and in a terminal, navigate to the extracted files and type:

$ sudo make install

Now we have access to the KFu C++ libraries and can use them in our program.

Now, let's create a folder for our program to live in, for example: /home/yourName/Programing/kittens

The Sprites


I already know that I want my program to involve cats, and since I'm better at drawing than coding at this point, I'm going to start by drawing a sprite and then worry about getting it to the screen. For sprite creation, I use a program called MTPaint which is a great pixel editor. You can use any graphics program you like.

I drew my first cat at 16 by 16 pixels and in 4 colors, one of which (black) will end up transparent. I saved my sprite as an 8bit .png, which is an indexed file format - perfect for making a retro game. You could also use a 24bit .png which has alpha transparency (various shades of transparent) which lets you have pretty, smooth and curvy edges all at once! Make sure to let the file know that you want the first color to be transparent. In MTPaint this is through the save dialog. Here's a screenshot of my final kitty:




The Code


Okay now let's create our program files. I like to work with Nano, a command line text editor. You should use whichever program you are comfortable with as long as it's a text editor and not a word processor. (ie, not Open Office Writer or AbiWord, but using Kate or Gedit is fine)

In my kittens folder, I create a new file titled kittens.cc with the following contents:

// kittens
#include <unistd.h>
#include "KFu/KFu.h"
using namespace kfu;


This tells me the name of my new program, and that I want to use the KFu library. Save the file and then create another empty file named Makefile. A makefile is a type of script file so that you don't have to type out the compile instructions every time:

all: kittens_norun

kittens_norun: kittens.cc
 g++ -o kittens kittens.cc -lKFu -Wall --pedantic

kittens: kittens_norun
 ./kittens

IMPORTANT: The spaces on lines 4 and 7 are really tabs, make sure you replace them in your code.

Okay, save that, and now let's get that sprite to the screen! Open kittens.cc and add this to your file:

int main(int argc, char* argv[]) {
screen display(128, 120, 640, 480);
stamp kitt1("kitten1.png");

kitt1.put(100, 100);
display.flip();

sleep(5);
}

Before we talk about what everything does, let's make sure it works:

$ make kittens

A smallish black screen should pop up and have a little cat standing in the middle of it, and then it should close after 5 seconds. If this didn't happen, look back over all your code, and double check that everything is correct. I do have the project files included at the bottom of this post if you need them.

So, let's take a look at the code we just added. int main(...) { ... } is the wrapper for our actual program. Pretty much everything we do will be included inside of it.

screen display(128, 120, 640, 480); This sets up the parameters of our game screen. The first two numbers are the width and height of the game window. The next two numbers are the width and height of the screen. The game space will expand and center in the available screen space. This lets you change the size of the pixels on the screen. With the setup that we're using, we'll have a fairly small screen, and the pixels will be magnified x4.

stamp kitt1("kitten1.png"); This line sets up our stamp, giving it a name (kitt1) and telling it which file to use.

That's it for the setup, now we get to actually place the kitten on the screen.

kitt1.put(100, 100); Here, we name our stamp, tell it to "put" it to the screen, and tell it the x and y coordinates.

display.flip() is what actually paints the sprites to the screen. Very important, don't leave this out!

The last thing we do is tell it to do nothing for 5 seconds (sleep(5);) and then it gets the the final } and closes our program.

There are two things we need to add to our "game" to make it a bit more functional: movement, and a way to close it when we want rather than only letting it last for 5 seconds. Both of these are going to involve key presses, so let's add those in!

In between the screen set up and where we actually paint the cat, let's add a section:

/// HANDLE EVENTS ///
while (SDL_PollEvent(&event)) {
switch (event.type) {
case SDL_KEYDOWN:
switch (event.key.keysym.sym) {
case SDLK_ESCAPE: done = 1; break;
default: break;
}
break;
}
}

This basically says, look at all the keys that are down, if you see the escape key get pressed, then done equals 1 and then skip to the end of this section.

You will also need to add the following line to the top of your program, right after int main() { in order to access the SDL event handling.

SDL_Event event;

Now, we need to tell the program that it should should skip on down to the end of the entire program when we press escape.

So, surrounding everything but the first few lines of setup, add a while statement:

int main(int argc, char* argv[]) {
SDL_Event event;
screen display(128, 120, 640, 480);
stamp kitt1("kitten1.png");

while (!done) {
... your code ...
}
}

We're going to have to set up the variable at the very top of our program, in between main() and the SDL_Event line:

int done = 0;

Now, we can clean up our code by removing sleep(5); as well as #include <unistd.h> since we aren't using them any more.

I guess I should mention that you should be compiling and running your program in between each set of changes so that you see the progression as we go along.

So, let's make that kitten move! Add the following line underneath the escape key press:

case SDLK_LEFT: walkleft = 1; break;

This sets the walkleft variable to 1. Add the walkleft variable underneath the done variable:

int walkleft = 0;

All by itself, that doesn't do anything--we need to use that variable in an if statement in order to change the coordinates of our cat.

First, change kitt1.put(100, 100); to:

kitt1.put(k1x, k1y);


now, let's preset our kitten's coordinates to the bottom right of the screen by setting our variables:

int k1x = 110, k1y = 88;

Now all we have to do is create our if statement and place it right before we put the cat to the screen:

/// GAME LOGIC ///
if (walkleft == 1) {
k1x = (k1x - 1);
}

If you run the file now, you'll notice that the cat smears itself across the screen, we need a way to clear the screen each time we paint. So let's add the following right before we "put" our cat to the screen:

display.clearSurface();

Next, we need to get the kitten to stop moving after you let go of the left arrow. We need to add a whole section to our Handle Events section right after the break; for case SDL_KEYDOWN::

case SDL_KEYUP:
switch (event.key.keysym.sym) {
case SDLK_LEFT: walkleft = 0; break;
default: break;
}
break;

To get the kitten to wrap around to the other side, add the following tight after we decrement our x position:

if (k1x < -16) { k1x = 128; }

The numbers I chose here make sure that the kitten disappears off the screen before it re-appears on the other side.

You should be able to add all of the code to move the kitten to the right rather than just the left.

Next time we'll flip the kitten, animate it and add another kitten to follow it around!

The Files


You can download everything from part 1 here: kittens-01.tar.gz

* * *

Monday, September 20, 2010

UVOG Arcade Machine

Umpqua Valley Opensource Group is building a classic-style Arcade machine (with a few innovations.) I am in charge of drawing the sprites for one of the games, so I spent the weekend studying 8-bit video game palettes.

I settled on using limitations similar to the 8-bit NES. The NES itself only had around 54 possible colors on the system palette (technically there were 64 color indexes, but 10 of them were black and two were white!) There were also many additional limitations on how many colors could be used at a time on the screen as well as how many could be used per tile or sprite.

I am using the same basic ideas to restrict the artwork for this game, but I have created an expanded palette using a full range of 64 different colors. I also hand-tuned the choice of colors, and re-ordered the palette in a more sensible way.

Because the Arcade Machine is an Open Source Project, my palette is Open Source as well. I am calling it the UVPALETTE. It is available as a GPL (GIMP PaLette; which is usable in mtPaint also, and is basically a text file with a list of RGB values) at the following address:

http://communitycomputercenter.com/userfiles/UVPALETTE.GPL

I also have a demo of the palette here is a PNG file:


In order to make discussing and working with the palette easier, I have prescribed a canonical name for each color:

Names of colors on the first row (0x00 - 0x0F) Black, Dark Blue, Dark Cerulean, Dark Mint, Dark Green, Dark Lime, Dark Yellow, Dark Tan, Dark Orange, Dark Red, Dark Rose, Dark Orchid, Dark Violet, Dark Indigo, Forest, Charcoal.

Names of colors on the second row (0x10 - 0x1F) Gray, Blue, Cerulean, Mint, Green, Lime, Yellow, Tan, Orange, Red, Rose, Orchid, Violet, Indigo, Brown, Slate.

Names of colors on the third row (0x20 - 0x2F) Silver, Light Blue, Light Cerulean, Light Mint, Light Green, Light Lime, Light Yellow, Light Tan, Light Orange, Light Red, Light Rose, Light Orchid, Light Violet, Light Indigo, Jade, Chalk.

Names of colors on the fourth row (0x30 - 0x3F) Pale White, Pale Blue, Pale Cerulean, Pale Mint, Pale Green, Pale Lime, Pale Yellow, Pale Tan, Pale Orange, Pale Red, Pale Rose, Pale Orchid, Pale Violet, Pale Indigo, Gold, White.

Here is another version of the palette demo with the prescribed color names listed for quick reference:


Enjoy!

Friday, September 3, 2010

Robot Logic, Part 1

UVOG has decided to make a robot as a club project. It will consist of Open Hardware and Open Software, and be easy for people to make at home on the cheap by repeating our steps.
My specialty is the software. So far, we have decided to use a handful of ATtiny2313 chips to control the various appendages and modules of the robot. The ATtiny2313's will be hooked up to a root controller of a type that is yet to be determined. So, I'm going to be learning AVR assembler to program the ATtiny2313 chip, but for now, I've been doing my experimenting with C. Assembler actually looks easier to use in this case, since I am so interested in direct pin manipulations and our memory space is so limited (2k program memory plus 256 bytes of SRAM and 256 bytes of EEPROM.)

One of my eventual goals is to learn the self-programming functions of the AVR instruction set so that I can reprogram any chip in the robot in place without any additional wiring other than that which we are using to send instructions from the root controller to the sub-controllers, but for now (until I have taught the chip how to do this), I have to use an external programmer.

Programming the Microcontroller

I've used three different programming boards for the 2313 so far. The first one was a hand-made parallel port programmer, which pulled its current from a USB connector. The second one is a board from Evil Mad Scientist which connects to the PC entirely with USB, through an adapter. Both of these were ok, except I kept having to pull the IC from the programming board, and put it on my breadboard for testing, then after failing (it is inevitable), pulling it again and returning it to the programming board. The third programmer is also a hand-made one, but this time it has two female headers running the length of the chip that I can plug test wires into. It also has a six-pin connector to attach or detach the parallel cable, which is a lot easier than running around behind the computer every time.

My debugging process now looks like this:

Plug the IC into the programming board. Plug the USB and Parallel into the PC, and plug the other end of the Parallel into the programming board. I will leave the IC , the USB and the Parallel (on the PC side) plugged in the entire time I'm working. The only cable I will unplug during the debug process is the programming board side of the parallel cable.

So far, I have not been using the UCSK, MISO, MOSI, or RESET pins (a.k.a., pins 1, 17, 18, or 19) in my actual experiment, so I can leave the IC on the test board, and hook up my other components by jumping a wire from the headers to the breadboard.

I unplug the single wire going from GND (pin 10) to the breadboard's ground bus, and I plug in the six-pin parallel connector, then run "make", and my toolchain compiles and automatically uploads the compiled code into the chip. Next, I plug the wire from pin the breadboard's ground bus back into pin 10 (GND) on the header, and I unplug the six pin connector, which releases the RESET pin causing the chip to boot up and run my code.

When I want to test again, I simply unplug GND and plug the six pins back in.

If I simply need to reset the chip to test the boot sequence again without reprogramming it, I can either apply a GND lead to the reset pin, or plug the 6-pin parallel connector in momentarily to accomplish the same thing.

How I Plan to Use the Chip

The 2313 has a nice amount of general purpose input/output pins. They have given names to the pins to indicate how they are treated internally as "ports." Along the "left side" of the chip, we have RESET (which doubles as PA2), then we have PD0, PD1, PA1, PA0, PD2, PD3, PD4, PD5, and GND. And going up the right side of the chip we have PD6, PB0 through 7, and VCC (our voltage source.)

For most of the chips in this project, I plan to use them in the following way:

Pin 1, 10, and 20 are keeping their purposes as RESET, GND, and VCC. Although repurposing RESET is possible, it is dangerous because it disables the programmability of the chip (RESET is normally held low while the chip is flashed.)

All the other pins down the left side are going to be used as inputs, in addition to pin 11 (the bottom pin on the right side.) This gives us a total of nine input pins which are known internally as PORTA and PORTD (with the exception of PORTA bit 2, which is reset.) When used as inputs, the values are actually read from the ports called PINA and PIND. All of the remaining pins on the right side will be used for outputs, which is known internally as PORTB.

Quick Review:
Input: 2 bits of PORTA and all 7 bits of PORTD. (actually PINA and PIND)
Output: All 8 bits of PORTB.

Some of our inputs have special functionality that we will be interested in, so we need to be careful to reserve those for the purposes we intend to use. Specifically, pin 6 and 7, a.k.a., PORTD2 and PORTD3 are the lines used to raise INT0 and INT1. INT0 is interesting to us, because it is the only regular user-definable interrupt that can raise the micro-controller out of its power-saver or sleep condition. (I don't remember exactly the term used for this particular sleep mode at the moment.)

I plan to use INT0 and INT1 to "talk to the chip" from the root controller.

This leaves us with the following general purpose inputs, which I would tend to utilize in the following manner:

Most Significant - - - - - Least Significant
PD6, PD5, PD4, PA1, PA0, PD1, PD0

If I care to get this into a single byte (sans the high bit), I think I can do so by performing the following bitwise operation:

MyInput = ((PIND & 0x73) | ((PINA & 0x03) <<>

Because the ATtiny2313 uses internal pull-up resistors, the default state of all the pins will read as high values (1). To toggle a pin, we must apply ground to it, which will lower it to zero. In other words, when we are dealing with inputs, "low means active." We might, therefore, want to inverse the value of all bits of input, so that we can logically use 1 to indicate active and 0 to indicate inactive.

Gotta run, I will post more on this later.