Final GSOC 2008 evaluations

I have submited the required code to Google for the final GSOC evaluation, well, now I just have to wait for my GSOC shirt! :)

Recently I started to use WingIDE to work on carcode, I tested wing in the 2.x series and current 3.1 version is really good, I like its code analysis tools specially, I applied for an free OSS license and got it right away next day!, now that is fast!

Now, I have to workout a few issues with carcode which appeared recently when testing for the beta release, collision detection is not working as it should, it could be a problem with the geometry (in memory geometry does not describe the rendered object accurately) or the algorithm, however I recall having it working in Alpha 2, propably I should have added a test suite for it, now I will have to see which version broke it, fortunately git bisect command will be very useful for this.

Now time to do some testing and reading for pharmacology exams next week!

Carcode GSOC

I haven't posted anything since Alpha 1 and currently we have Alpha 2 available, Beta 1 is around the corner (has been for quite a while).

Google Summer of Code has ended, most features from my proposal where fulfilled, but I'm still working on it on my free time, altough now with school I don't have as much time as in summer vacations but is free time anyways.

I have updated the screenshots section from the carcode project page with latest work (beta 1):

http://code.google.com/p/carcode/wiki/Screenshots

Currently I'm working on adding a few levels in order to have a Beta with something to work on, more levels will come and ofcourse, you can make suggestions, there is a wikipage on level design:

http://code.google.com/p/carcode/wiki/LevelDesign

Feel free to add and modify!

Last but not so last, I'm Alive! and working on carcode! don't worry :)

Carcode 3.0 Alpha1

Carcode is an experiment in programming education. The idea is to give beginning programmers carcode, which provides an animated car they can drive around the screen either using the keyboard, or programmatically through a simple API. By working on a series of problems (such as "park the car in parking space A"), beginners learn to program in an engaging, and goal-driven environment they already have much familiarity with.

The first version derived from GSOC 2008 code has been released, is an alpha release with a good and working code base but it is still not feature complete, you can however try it out and experiment with it.

Major features in this release:

• Level scripting capabilities
• Car scripting capabilities
• Car sensors
• Widgets for in game UI and dialogs
• Few examples of scripting in demos directory

Downloads:
http://code.google.com/p/carcode/downloads/list

Issue Tracker:
http://code.google.com/p/carcode/issues/list

Don't forget to send feedback!, use the tag Milestone-Alpha1 when sending a new issue in the tracker.

This release has been out for a few days however there has been some heavy rain and electric storms in my area which delayed my work a few days, but I'm in working shape again (I hope there is no more storms for now).

Next thing to do is to add the event tracking system, add support for adding conditions and goals to the level and refine scripting in general, a few UI enhancements and I'll do another release.

GUI branch

After working a few days on my GUI branch of carcode, I got some interesting results, I completed a basic set of widgets that integrates well with carcode, I did a main menu and a file dialog to open script files:

It was interesting to work on this, I wanted once to create my own toolkit, based on SDL and C, but it ended up being a bit time consuming, this time was very simple and fast, using python + pygame + OpenGL to do all.

OpenGL has many useful features, for example Stencil buffers, I make use of them for clipping widgets inside windows or other widgets, even having multiple widgets that make use of it inside other widgets works fine, you just need to take care of how many times the buffer has been written.

Well, midterms are approaching but the project is on schedule, even better than I expected.

Choice of tools

All projects use different tools, carcode is hosted on Google Code and uses Subversion, being coded in Python it is cross-platform.

I use Linux (Madriva 2008 Spring) and Git for versioning with git-svn for carcode subversion push, as for IDE I use a plain editor, Kate, I used VIM before but found Kate a bit more productive. I also like Nedit. I tried Eclipse + Pydev but I find it too big and I don't use most of the features it offers. I tried KDevelop but I didn't like it, it feels like a plain editor (for python, for C++ Qt is a good IDE), I tried Wings trial which I found comfortable but is not OSS although its price is affordable.

I usually don't use autocompletion features that offers certain IDEs, I know OpenGL well and have books at hand (OpenGL Game Programming), pygame documentation is all I need, any other thing missing may be found in the python shell by using dir() on the object, help() or internet.

As for development machine currently I'm using an HP pavilion dv6000 series laptop, which has an Intel core 2 duo processor (1.8ghz), I started working on the project on my later HP Pavilion ze4900 with a Celeron M (1.4ghz), I have an old test machine, an IBM ThinkPad 460XL with a Pentium 133Mhz just for the kicks, I tested other projects of mine on this machine when optimizing. Is really handy for that :).

As for Windows development I have windows XP dual-boot, I use Eric4 and msys-git (a windows port of git using msys), although I barely use windows, mostly rare windows development and some games that don't have a windows port or don't run under wine, but I usually buy games with linux support (such as doom3 or Neverwinter Nights) or play OSS games.

Additionally I have a host of virtual machines, one with Ubuntu (for deb packaging), other with OpenBSD and other with ReactOS, I will probably add more later (FreeBSD).

What do you use?

Carcode GUI

At the beginning of the project I wanted to use PGU library to create a nice GUI for carcode, however, after moving to OpenGL it seems that pygame refuses to blit to screen surface when OpenGL is enabled, thus I had two options, look for a workaround and use PGU or to use an library which renders with OpenGL.

A workaround may implicate disabling OpenGL support from surface after arena drawing code, looking around it seems that the problem is with SDL and thus a workaround is discarted, it may be worth but it can be too much effort and time, it will complicate distrubution too. Anyways, PGU hasn't been updated since 2007, go figure.

Looking for an OpenGL compatible library doesn't gives much hope, there is a couple that may do but that would be another dependency, I will keep checking if I find something useful.

Meanwhile I created a branch to work on create a set of GUI widgets for carcode, is not that difficult and we don't need them to be very complex, currently I have labels (text), buttons, lists (listbox) and text inputs (simple one line inputs) working and integrated with carcode all this using OpenGL.

Additionally I'm looking at Box2D, a 2D physics library which has python bindings, I will create a branch to play with it later probably after GSOC is over.

When the project is more or less featureful I will start working with performance, there are many places where I can improve, specially OpenGL rendering code which has many optimizations available.

Carcode improvements

Since last post I have already make good advances with carcode, collision is now working, I started using the Separating Axis Theorem (SAT) for collision, it works with boxes but it will be extended to polygons and other figures later on.

Also I have enabled car scripting, I did a small demo where you have a path and 2 sensors, the script uses sensor information to try to follow the path, it is a very simple script, it just steers the car according sensor data.

A few new entities have been added for level scripts, such as Box and Text, there is the object Console where you can write some text to the screen.

Currently I'm working on windows support, fixing things here and there and improving py2exe support which works pretty well (unless you install pyOpenGL 3.0). I have implemented game pause.

Next step will be providing packages for any brave testers :), improve collision detection, improve car scripting, create levels, improve UI.

Math

It has been a while since I had to use math a bit more complex than just your common arithmetic, for collision detection I had to sharpen my skills again, I worked all night with pen and paper aided by a simple plotting script to check results.

I got a full page packed with formulas to solve finite line intersection, then circle with circle (pretty easy) and finally line with circle, there was where everything went wrong and very messy; I ended opening one of my old math books which had an easier solution for line on circle by using determinants instead of the direct approach I was using.

Probably the small script I used for plotting could be released as a project, I called it glPlot, which could be a cool project, an OpenGL plotting canvas with python scripting where you could easily visualize data and parametric functions, it can already zoom and move trough the 2D space.

Anyways, I will incorporate the intersection code to carcode collision module this night and do a few demos later.

Code updates

My semester officially ended the last Friday, finally free!, I'll be going back to home today for Fathers day.

Now about some code updates, I redid the basic tracer lines code for OpenGL, which consist of creating a series of lines given the movement of the car from Pos1 to Pos2, of course this could potentially waste a lot of resources, however, each new line is compared with previous one and if they have the same angle the previous line is just extended, additionally you can turn the tracer on and off, here is a nice example of things you can do with it :)Tracer lines are mostly done, and so are sensors, next thing is car scripting, I still not very sure on what approach to take, I could just load the script and execute it each time the car is updated, other way could be by using events, having the user hook to specific events (update, sensor, etc.), or just have them create a class where the function update is called each time the car updates, and so on, this last approach has the advantage that you can use the class for storage (variables). Who knows, I will probably just branch and take all approaches and see what works best then merge it with HEAD and be done with it :)

More update to sensors

I'm working fast this night, I changed the way the sensor reads pixel data, now it should return unsigned bytes, also I created a subclass called ColorSensor, which looks for a specific color, when its found sensor pixel is set to True, otherwise False.

Finally I created a small event dispatcher class to handle sensor events, when the sensor is updated an event is raised and appropriate functions are called, this is very useful for ColorSensor, I exposed this functionality to level scripting and created a demo level where you need to get your car to a specific color block.

Now I can mark sensors as done on my TODO list :-), next thing should be a better showcase demo! with some winning conditions thrown in :)

Begining GSOC

Finally this week I'm less constrained by school work, I have already finished most courses, only two are left for next week (pharmacology and immunology), thus I'm getting more and more free time to work on carcode.

It is unfortunate to lose 2 weeks, but I started working earlier and the code base is in good shape and ready to keep working.

Currently I'm working with sensors, I had the basic code but had some problems with positioning, I fixed that and now sensors are correctly positioned according car position and angle, the problem I had with this was that when rendering using usual OpenGL drawing functions, the origin is at the top left corner of the screen, however, when reading raw pixel data from backbuffer the origin is located at the bottom left corner of the screen, I catched this when I started drawing the sensors as small boxes.

The sensor will read it's data on the draw function of the car class, before the car is drawn, the sensor will read the pixel in a given position relative to the car center (the screen center).

I added the sensor class to the level script space as the class Sensor, you can also get the car class with the arena function Arena.get_car()

The next step is to add collision detection facilities, maybe I will start with placeholders to get to scripting faster, next would be car scripting, probably this would be a module or function that will be executed (like level scripts) after drawing each frame, but I still have concerns about parallel execution of rendering loop and car scripting, but this could be addressed later by the use of the threading module.

After adding some scripting facilities and documentation I will start making releases for courageous testers :)

OpenGL Branch Merged

I have merged my OpenGL branch with my mainline work and I'm beginning to work on level creation, based on simple python scripts.

Current work basically loads the python script and gives a custom environment to access needed carcode functionality, which roughly includes adding entities to Arena, basic prebuild entities and OpenGL functions to create your own entities.

Next steps to improve general usability of level loading should be documenting rendering API, which functions needs to be implemented by and object to implement drawing, collision detection and event handling.

I'm currently using Sphinx to generate documentation from RST files, this system is used for the official python documentation.

Collision Detection

Collision can be done in several ways, the most usual being by the use of Bounding Boxes, in this case, a rectangle that more or less covers the area of our object, this can be done in several ways and it is very easy to implement, however, for carcode I stepped this up to something more generic with a given set of vectors, which should be very similar to 3D Bounding Box collision detection, but 2D, I had to workout my rusty math skills but I came up with a nice and general way.

At first I tough of making assumptions such as that the box was actually a rectangle, however this isn't generic enough, I could want to have a non rectangle quadrilateral or even define an area with more than 4 vectors, the answer was "triangles", you can basically divide any "regular" polygon defined by n vectors in triangles, and thus began my quest for collision detection inside a triangle.

By using a vector as the basic unit for collision detection (a vector inside a given area) it should be generic enough for "collisioning" two different polygons, the basics of this is to pick 3 vectors for the triangle, noted by v1, v2, v3, translate the figure to Origin by using v1 as base, now we calculate the angle between v1 and v3, and rotate so V3y will be exactly 0 (on the X axis), we do the same to the vector we want to collision test (Vc), now with Vcy we calculate the distances in the X axis of a pair of vectors that delimits the triangle on Y - Vcy, this is basically done by using the angle alpha1 (angle of V1) and alpha2 (angle of V3).

X1 = tan(90 - alpha1) * Vcy
X2 = tan(90 - alpha2) * Vcy

We do a substraction, X2 - X1, if the result is negative basically means that Vc is outside the triangle (in Y), you could also check this by using V2y, now we test if: (V3x - X2) > Vcx > X1, in case of being true it means that the vector is inside the V1,V2,V3 delimited area (in X).

Doing all this for every frame could be time consuming, but we can pre-calculate a lot of things such as dX and dY from the translations and rotations, then tan(90-alpha), which will basically reduce the whole algorithm to a pair of additions, two multiplications and tree comparisons, in the optimal case (the area is not moving, and we use V2y for Y test).

That is the basics, but even then I'm making some assumptions, I will try to prototype some code and do the necessary refinements. Hopefully I will have some time next week after the Pharmacology (this Friday) exam and the Physiology exam (next Tuesday), which obviously pharmacology is way way bigger than physiology.

Prototyping

I have been very busy with school this last days, but this weekend I have some free time to keep working on Carcode, today I'm working on my OpenGL branch, currently I have the old car ported to new rendering (using glRecti), I tried with textures but admittedly I'm not very good at graphics so we'll keep the plain rectangle for now.

Added some framerate controlling code which yields a pretty and smooth animation, with current code we can have a world as big as we want, I already added a new object, the Road class which draws a simple road, which is currently just for test purposes.

The next thing on the list is to document the API for creating drawable objects, which mostly comprise of implementing the update and draw function, then layout the specs for collision detection and scripting.

Talking about scripting, I'm looking at two approaches to it, one would be have a function on the scripted object which may modify its behavior or internal data like "update", this could be nicely integrated with the current mainloop, however, it could be limiting for the car scripts, for example, for loops would not be very useful for things like moving the car, as updating and drawing of the car will only occur after execution, which means that in order to move the car to a desired place you cannot just loop and wait, however, given the nature of the car control (by acceleration and direction angle) I don't think this could be a problem, we should however stop comparing carcode with LOGO, as dynamics of carcode are very different.

The other approach to scripting could be threading, with this we could have non-blocking loops inside scripts, however, this could cause a nightmare of possible synchronization issues if not done right, it is possible that it would be more work implementing it than is worth, we could probably use yield and have some code checking if the script returns an iterator and keep executing the iterator each frame.

A snapshot of my opengl branch is available at http://cdrv.centralnogales.com/carcode-opengl.zip

Current experiments

Currently I'm prototyping a few ideas for carcode features, I have to plan very well what I'm gonna do as everything should be flexible in order to facilitate future development, here are a few things I have been doing:

Tracer lines

One of the features needed was to implement tracer lines, my initial idea was to use an additional surface and just draw them there, this worked well and was very easy to implement, however, this restricts the level size to the screen size, in the future we want to be able to work with maps bigger than the screen.

To alleviate this problem I just recorded the lines coordinates as they where being draw, each new line is checked against the last one in order to see if they have the same angle, if they do we only extend the last line, this helps a lot with memory consumption. In a test I did I generated around 680 lines by just moving forward and doing a half curve, this was reduced to just 15 lines with the checks in place.

OpenGL Rendering

I have a branch with OpenGL rendering as an experiment, which could potentially help with many features, it makes easy to implement big levels and corrects visual problems (skewing) introduced by rotozoom function used to rotate the car surface. Additionally OpenGL rendering is very fast in my machine (with a puny old intel graphics card, mind you), faster than plain pygame.

This could be a good enhancement has it will facilitate future development, we could substitute pixel graphics for 3D models.

Carcode gsoc08 branch, rev49

Originally from http://cdrv.centralnogales.com/?p=76, from 21 April.

This revision makes some deep changes to the carcode structure, which includes rendering and event handling, this in order to accommodate later features such as scripting.

Current state, sound works, the car moves as with original code, there is now a working tracer line.

Rendering

Initialization, mainloop and event dispatching are now handled by the CarcodeApp class, this creates the main window surface and an instance of Arena which handles rendering.

I rewrote the arena code, we now use two surfaces, one for the background (unused still) and other for the tracer, the rendering loop goes more or less like this:

• Clean the background
• Draw all entities of the arena, not including the car
• Draw the tracer surface
• Draw the car

The arena code handles the tracer too, it first gets the current position of the car, then tells the car to self update and draw, then we get the new position, we do a few checks in order to not draw lines across the screen when the car passes from side to side, and the just draw a line from original position to new one.

Event Handling

The new CarcodeApp class handles all initialization and event handling work, we use a dictionary of Key Codes and Functions to handle keyboard input, just like old Arena code, but we use the function add_key to hook new functions.