Wednesday, June 30, 2010

Drawing API's and Frame rate

Today I worked on the ticket to update the draw api (ticket 34). This update now passes the clock delta that the pygame clock.tick method gives us. What is great is today I even used the sed command to apply the new argument to the draw methods in the code. I am glad that I have finally be able to use sed and I hope to be using it more often in the future.

I also quickly added a frame rate display to the game engine (changeset 268cc24...). To activate/deactivate the frame rate display, simply open the game console (ctr+w) and type in the command fps.

Apart from a bunch of other things going on, I changed my gnome look a bit following a few suggestions from one of fran's blog posts. Basically it takes some of the neat features of ubuntu's remix and leaves some of its drawbacks behind. That with gnome-do is a great combination.

Tuesday, June 29, 2010

Fortune Updates and Headaches

Today was a fairly productive day. We got a few tickets tackled, had a couple great discussions, and found a few major problems with the Fortune Engine.

First task of the day was to update the Game Engine's timer api (ticket 30) to simplify it as well as make it more consistent with the rest of the engine. Before this api change, the developer would need to set a timer (between zero and eight) and set the time between fires. After that they would have to listen for a pygame.USEREVENT + id in the event loop and then handle the event as they wanted. The problem with this is they have nine timers that they have to keep track of, making sure they don't reuse a timer between different elements of their code. The new api now takes in a function and a time delay. When the timer fires, it calls the function directly. When the user wants to remove the function, they simply pass in the callback function they wish to remove. The developer no longer needs to worry about what timer they are using, as long as they don't need more then the nine given to them.

In the process of testing the new timer system, I found the cause of the long standing Search Exiting Early bug (ticket 16). This was a bug that when the player was trying to search a room for hidden items using the amulet search method, it seemed to abort early with no reason. Well the cause of this bug was the pyconsole set the repeat character option that was interfering with the game timers when it sent repeat events. I don't like having the console changing the behavior of pygame. While it is useful for the backspace key, it is less then idea to have the console changing global behavior. So my change was to simply remove that from the pyconsole.

While changing the pyconsole I found that the new threading system was causing problems with console input, so I had to make a commit changing pyconsole so that it's process method acts more like the rest of my input handling.

One major problem with the game engine we found was when user's code crashes in one of their callbacks, the game engine would crash causing the window to freeze due to the draw or event loop getting the exception. The problem is, if one of the loops crash, the game should exit all threads and close. The solution was to catch the exception, print its stack trace and then call the stop_event_loop function (ticket 33). This is only one of the major problems we found. Another problem that I haven't solved yet is when their code goes into an infinite loop that doesn't return control to the game engine. This could be solved with a watchdog thread that will kill the loop if it hangs, but that gets messy. Another solution could be to spawn user callbacks in their own threads, but the overhead and thread maintenance would be another headache on its own. At the moment I haven't decided on a solution or whether I shouldn't worry about it at all.

I have also added a few tickets today for a later date. Some of them include adding a profiling system that can be turned on in engine for debugging and optimizing tools it could provide (ticket 31). We also need to modify the draw API so that it can give access to the time elapsed argument to the animation system (ticket 34). The art team and the engine team had a nice long talk about the best way to get animation into the game and we found that giving them all a time difference seemed to be the preferable method. Luckily the pygame click.tick method not only controls our frame rate, but adds the ability to give us the time elapsed since the last frame. A third ticket we made was to incorporate a dirty draw technique to increase our frame rate by reducing the amount of processing we need to do on each draw (ticket 35).

Well with that said I leave you this, Threading is a wonderful thing, but creates a lot of headaches and problems.

Monday, June 28, 2010

Fortune Engine helps Debug Infinite Loop

The fortune engine helped debug an infinite loop with relative ease today. There was a bug in our code that caused the game to come to a halt. The bug was in one of our drawing callbacks that didn't return back to the game engine.

What is great about the design of the game engine is there are (as of today) two threads, a drawing thread and an event loop thread. This bug showed a problem with the design of the engine, you can't run the debug console when the user code in drawing or event thread fails to return control to the game engine loop. I will have to make a fix for this later.

So how did the engine help debug the loop? Well once you can determine that it was with the drawing and not the event loop it cuts out half of the things you need to debug. This was easy to do as the engine now uses a lock to ensure either a drawing or updating state gets to finish before switching threads. So by simply adding two print statements I was able to find it was crashing in the drawing thread as it didn't return the lock.

The next step was to figure out which draw callback was causing problems. This was as simple as adding one print statement.

diff --git a/MAFH2/fortuneengine/GameEngine.py b/MAFH2/fortuneengine/GameEngine.
index 477bd07..610de30 100644
--- a/MAFH2/fortuneengine/GameEngine.py
+++ b/MAFH2/fortuneengine/GameEngine.py
@@ -129,6 +129,7 @@ class GameEngine(object):
             else:
                 self.event_lock.acquire()
                 for fnc in self.__draw_lst:
+                    print "DRAWING", fnc
                     fnc(self.screen)

This one statement brought the scope of the problem down to a single function.


DRAWING <bound method TermBox.draw of <TermBox.TermBox object at 0x99cdfec>>
DRAWING <bound method Dungeon.draw of <Dungeon.Dungeon object at 0x99bf0ec>>
DRAWING <bound method Map.draw of <Map.Map object at 0x99d884c>>
DRAWING <bound method BattleEngine.draw of <BattleEngine.BattleEngine object at 0x99d8f8c>>
DRAWING <bound method BattleMenuHolder.draw of <BattleMenu.BattleMenuHolder object at 0x99d88cc>>
DRAWING <bound method BattleMenu.draw of <BattleMenu.BattleMenu object at 0x99dc4ac>>
DRAWING <bound method MagicMenuHolder.draw of <MagicMenu.MagicMenuHolder object at 0x99dcc6c>>
DRAWING <bound method MagicMenu.draw of <MagicMenu.MagicMenu object at 0x99dcd6c>>
zsh: killed ./MafhActivity.py


This output showed the last function the game engine was able to call in the drawing thread was the draw method of the MagicMenu class. From this point, we knew the function that was causing the issue and from there it was pretty clear to look for any loops.

Week 4 and on a roll

Today starts the new week. We are onto a good roll so far. Some good news, David Silverman was kind enough to get a new logo for Fortune Hunter (ticket 13).

Fortune Hunter Logo

I decided to do a quick task of splitting the console code out of the main engine into its own class (ticket 28). The motivation behind this was to make the engine code slightly cleaner by removing the console specific files. The new file is heavily dependent on the Game Engine, so you could argue that it is not the best idea to move it out, but it does look cleaner.

Another task I tacked today was the decoupling of the animation loop from the event loop (ticket 22). This is great, but at the moment it seems to have caused more problems then it has solved. There is an interesting bug that if the event loop is being fired as it is in a draw loop, you can get some interesting frames. So to fix that I had to implement a thread lock on the draw and event loop (ticket 29). One could argue that defeats the purpose of threading, which it does. So at the moment the threads just get by the waiting for an event to be fired, removing the need to fire a timer for animation.

On a side note created a ticket for one of our Pixel Ninja's to make us a Foss Logo for rit (ticket 4 on fossrit).

Friday, June 25, 2010

Foss-AT-RIT Update

This week has been a bit crazy, not as much on the coding front as the management side of things. I have been updating our mailing list making sure that everyone in the foss project is at least on our fossrit mailing list.

I have also been reorganizing the Foss.rit.edu website. Some changes include adding customized user pages, a user list, and cleaned up some feeds and categories from the news aggregator. I have also be reorganizing the menus. Some changes include a new About Us menu and page. In this new menu I moved our History page as well as made a Trac, Mailing List, and an IRC page.

I have also been cleaning up some internal settings and modules to hopefully help the site out a bit. One useful feature I added is the ability to add a title and description to peoples blogs. So now bloggers can make a useful description to the blog to explain their project. I posted an email to our mailing list to let everyone know.

There still needs to be some work on the foss site, so I crated a ticket: Update foss.rit.edu pages.

Wednesday, June 23, 2010

New URL

Well today I decided to purchase Jlewopensource.com. So now my blog is hosed on blog.jlewopensource.com.

When I get around to it I will put my people.rit.edu profile on this site.

Tuesday, June 22, 2010

NTID Tech Symposium

Well for the past two days we have been showing off Open Video Chat and Fortune Hunter at the NTID Technical Symposium. Today Professor Stephen Jacobs, Remy DeCausemaker, and I gave a presentation entitled OLPC (One Laptop Per Child)/Sugar Video Chat Enhancements for Deaf Communication and Education. This presentation talked about the One Laptop per Child program and our Open Video Chat activity. We had one of our XO's running the activity from the presentation hall and the other from our kiosk in the other side of the building.

In the conclusion of our presentation, we had quite a number of people interested in the sugar operating system. Luckily I had installed sugar on a few live usb sticks that we were able to give out to those interested.

It has so far been a hectic week with this conference. I haven't been able to get too much coding done as I usually do. I am still working on the developer console (ticket #5) for the game engine. Now the console supports setting values to any statement that is a valid python expression by passing the string into an eval statement.

Next I have to be able to delete attributes as well as being able to list and call functions.

Another fun note: OVC made it up on boingboing.net (source seems to be from our innovation.rit.edu blog).

Thursday, June 17, 2010

Busy, but some progress

Ok so the past few days have been full of busy distractions. We have been preparing some materials for the NTID Tech Symposium, playing around with creating sugar usb sticks, stopping by posse, lunch presentations with the other summer research fellows, getting and setting up our own mini computer lab in the foss box, and much more. There are a lot of great things going on in the innovation center and I am glad to be apart of it!

So update with the fortune hunter game engine.

I have been working on a feature to allow a dev console to be added to the game (ticket #5). Recently I was able to successfully use the dev console to edit integer and string data. I have been having some problems with this because of the way python is designed. Luckily python still has some leftover global scope functions like hasattr and setattr which were of great use to this ability. The game engine now keeps track of the last element and token when finding the requested object which can be passed to setattr giving us access to modify the object.

The next step will to support the ability to create more complex structures then int and strings.

Screenshot of dev console setting an enemy's health

Tuesday, June 15, 2010

Game Engine Pep8 Compliance

Pep8

Well today was told about the pep8 python standard which is a little bit more picky then I am when coding. So today I spent a few cycles making sure my game engine is compliant to this standard. I even found a nice vim plugin that allows me to check my code from right inside my editor.

I may need to also run pep8 on the pyconsole.py file to be able to say my game engine is completely compliant, but that will come later if I have some spare cycles.

Console Set Variables

So it looks like having my console modify variables is very hard if even possible with how python passes variables. It seems like python won't allow the game engine class directly edit variables that it doesn't know the path directly. So taking user input and searching for the variable seems to not work. I will have to do some more research and hopefully I will be able to figure something out.

Monday, June 14, 2010

Fortune Engine Dev Console Inspection

Well as we are all still busy working on our tasks. I have been busy writing a debug tool into the game engine. This is a dev console that in its current state, it can view variables and modules in the game. This will be helpful when debugging the game, no longer will I have to add in print statements and restart the game. I can simply open the console and inspect the element.

Today I added the ability to inspect attributes and follow them to new elements (change set) using the dot notation.

Inspecting the battle module


Inspecting the battle module's room variable.

Next I plan on supporting dictionary element lookup so that the developer can check the state of an element inside a dictionary or list. After that, adding a way to modify the state could be useful, but could potentially be dangerous to the games internal state. So that might require some more researching and thinking.

Wednesday, June 9, 2010

Fortune Hunter is back in development

Well Monday marked the end of our fortune hunter break. We have been working hard to get back into action. Three of our original members, Dave Silverman, Keven Hocky, and I, will be actively involved in some way with the project. We have also picked up a new member, JT Mengel.

The Teams

There will be two teams working on fortune hunter this quarter.

Our art team, Dave and JT, will be working on researching and developing graphic standards/techniques for limited platforms like the xo. Their goal will be to come up with some graphic standards that will help rendering performance on the xo laptop. Their research will use fortune hunter as an example implementation.

The game engine team, Keven and I, will be working on creating and optimize a game engine that will be used for the game. This engine will allow easier debugging and cleaner code from the developer's point of view. It will have features like a dev console for debugging and hopefully a snapshot system.

Progress So Far

We have started to improve the game engine from the standpoint of the developer. Today I started off by splitting the game engine away from the main code to keep it clean and organized (t8). This will allow me to package the engine later on as a standalone that other developers will be able use in the future.

After that, I have been busy adding a Developer Console to the game engine (t5). My hope is this developer console will be very useful in debugging the game by allowing access to the game engine internals as well as access to registered components to the game engine.

I thankfully found a console script for pygame that I could just add to the engine. My next step will be to get this console to be more useful by writing methods that will allow inspection and modification of game state.

Infrastructure Update

Fortune Hunter now has a trac on fedorahosted that can be found here: https://fedorahosted.org/fortune_hunter. This track is now hosing our git, a doc wiki, and ticket system. I will still maintain our other git repo, but our developers will work out of fedorahosted.

On another front, foss.rit.edu is now getting some attention, we got some people now blogging on it. Always great to see more people working on the site.