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?
lunes, 30 de junio de 2008
domingo, 29 de junio de 2008
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.
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.
sábado, 28 de junio de 2008
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.
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.
miércoles, 18 de junio de 2008
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.
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.
domingo, 15 de junio de 2008
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 :)
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 :)
sábado, 7 de junio de 2008
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 :)
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 :)
viernes, 6 de junio de 2008
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 :)
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 :)
Suscribirse a:
Entradas (Atom)