SVG rendering on C#

Want some?

check this out!

some good news around the street corner…

I will only post this picture those pictures right now and you will figure it out. Later I will explain more and lay down my plans for the next months…

To Banshee, Newbie_X11 and Thanatos: Yeah..im giving in! Its about fucking time! Let the texture mapping begin.

To everyone else: both experiments are still VERY early and currently unusable. The texture mapping is mostly a very insecure code (handling video memory directly) and very inneficient. Im tweaking as much as I can. Im still trying to figure out how to do floor and ceiling textures fast.

The multiplayer code already be obtained @ SVN,but is very unfriendly and not very useful. Right now, all it does it sync both players on the map, but doesnt handle game logic at all.

I sincerely dont know how long will it take to finish this, as now Im working (as a intern) at Nano Games (hoohay! gone pro!) and we’re developing some really cool games (after all, I would only join a company if I really like their games).

There is a third experiment that I might post here around the weekend…who knows?

Angstron 2 released!

Among changes are bug fixes and major revamp and the levels and graphics. Please check it out @ http://batterypoweredgames.blogspot.com/2009/07/angstron-2-droid-hunter-release.html

BTW, I entered the GPC 08 indie game competition with Angstron 2 on mobile games category. Let the best win.

BZK and lightning

Due to my graduation thesis, I’ve been working on my lightning and shading algorithm for the render. The results?

The shades feel much more realistic, but also gives the level designer more work, as he/she has to lit everything.

Im still finishing my thesis, but when its done, I will figure out how to deal with that

Just check out the screen shot from this post and compare with the screenshot from this post. You can clearly see improvements on lightning. After both screenshots, I’ve also added (with little to no impact on rendering quality) pre-baking the lightning, so it doesnt need to process all the static lightning over and over every frame. Now I only have to take into consideration the doors. Im about to give this a proper solution before commiting the code to SVN.

Angstron 2 – finishing touches

UPDATE: wanna try this? so follow this link - http://batterypoweredgames.blogspot.com/2009/05/angstron-2-droid-hunter-beta-test-2.html

Finishing the last debugging, improving speed (for the first time, Im quite satisfied with most of the game speed. but level 3 is still my concern) and – to my shock – solving some plataform specific issues:

- Sound in maemo. I dont know whats wrong, but the sounds is not working with the 770. I will look over the old angstron1 code @ garage to see whats wrong…

- Memory footprint in EZX. The A1200i handle the first two levels graciously, but the game dies when loading the third, after a lot of time loading.

- Also on EZX: The chapter screens need some serious re-work .Ok, they need some re-work on all plataforms, but on EZX  its far worse.

- And finally, on EZX, I dont seem to get the icons working on the menu again. I had it working in the past. I dont know whats wrong now.

For desktop PC and EeePC  everything is fairly done.

And now, some teasers!

My plans is to have the game finished and released for the Rio Game Show 2009

Angstron 2: Droid Hunter finished-almost

UPDATE: ITS FINISHED!!! http://corporatedrones.wordpress.com/2009/07/22/angstron-2-released/

Hello folks.

I guess I’ve finished all the ingame  assets for Angstron 2: droid hunter. Sure the render is not ready for prime time (but it does perform decently in most cases), but this is a matter of time.  In any case, I’ve got a OpenGL version of it fully working and a OpenGL ES version is on the way.

My previous decision of scrapping level 2 was aborted (hence you will see the horde of morcegos in all its glory), but almost all the levels need some better POV-BSP-prunning during rendering before shipping. There are several points with some minor visible artifacts , some culling errors here and there and a few slowdown spots. While for a freeware game where there’s no compromise, I cant simply allow this to be released.

The game play remained unchanged from the previous beta releases, with some adjustiments still to be made.

The 2D artwork is seriously faulty and in need to be re-drawn. This is going to be a looong paper-and-pencil-than-flatbed-scanner-then-inkscape process. Dont hold your breath.

The game was somewhat delayed due to my lack of luck with UNIX this last weekend (http://corporatedrones.wordpress.com/2009/04/14/solaris-ubuntu-xandros-eeepc-problemas-meu-dia-de-azar-com-unix/)

The release will reach both Maemo 2.2 and the upcoming Maemo 5 (“fremantle”, powered by hardware acelerated OpenGL ES!), EZX , EeePC (this time, with a better packaging system, from the official SDK!)  and desktop linux.

Maemo 5

I, for one, welcome our new OpenGL ES-powered Internet Tablet overlords!

Im about to install the new experimental SDK (just right beside Gregale) and start playing with this OpenGL ES thing. I hope to make a special BZK fork to play nice with it and render some cool and fast graphics.  Future looks promissing.

BZK for EZX – finally!

UPDATE: wanna try this? so follow this link – http://batterypoweredgames.blogspot.com/2009/05/angstron-2-droid-hunter-beta-test-2.html

After the last (portuguese only, sorry) post on how to configure a SDL toolchain for EZX phones (at least A1200 motoming) and some hard effort and tweaking, I could finally build and try some BZK games on my phone. The results are quite surprising:

- Angstron : Slow. Slower than the first build for N770! tested with -O3, but with full depth processing and lightning

- Riddler: Suprisingly, faster than Angstron! Actually , playable! Still need some love on screen resolution, as the text doesnt fit all in the screen. Gourgeous!

- Angstron 2: droid hunter – tested only level 2 ( the best thing I have in terms of finishing, with some few textures in place, one moving enemy and some good lightning). Not the fastest thing on earth, but playable. Will need some more usability thinking…

From now on, Im just aiming for two more plataforms: OpenMoko and Google’s NativeClient. First is fairly obvious, as it seems the most neutral plataform (while I dont like its UI at all. I guess I will always be a Maemo fanboy) , while I’ve never tried compiling anything for it and only ran it once, booting on my A1200 via USB and loading the system from the MicroSD.

On the other hand NativeClient will probably be available for Android (I hope so!) and thus, its a good veichle for this “java-only” phone.  Even if it dont make into Android, NativeClient is a very cool plataform to support.

And now, some screenshots!

Mid Feb 09 Report

I just realised how screwed up I am! I “released” Riddler about 6 months ago and consistently looked at it for most of this time (but still I dont consider Riddler a finished product, as I consider Angstron) and never got it:

a HUGE typo in the game logo!

I dont know I missed that for so long. But thats it. these last two days I had a really HARD work to adapt the menu system I wrote about a year ago (back in Toronto) to work with vector graphics and parsing its contents from a XML (very similar to WML). Maybe its time to ditch all the art, and maybe even change the game name. The game itself doesnt contain any riddle! More on that later.

Now, for something completely diferent

You probably heard it before: ” Never optimize it early. Always make sure it works from end-to-end first, and then optimize it”. I just saw it on a book Im reading (again):  “Data structures and program design in C++” by Kruse and Ryba. Its a nice book. kind of a encounter of the old school and the new tendencies from late 90s. Kind of a entry-level art programming book. You would rather read this before reading Cormen or Knuth ( Kruse->Cormen->Knuth).

But about this lemma, I have a counter-argument when we’re dealing with open source software.  Optimizing it early attracts attendion and helps gathering momentum to the project. And every possible consequence to the Linus Law. And goes in acordance with “release it early and release it often”. Others will come and fill the gaps on functionality and fix bugs. The important thing is to show something compeling.

Of course, dont take my work to the last extremes. As my wise teacher , Vinod Rebello ,from college once said in class: “there’s always a trade-off”.  Developers might get frustrated by the lack of functionality or maybe readable code. Indeed, Im very surprised on how people could actually read the Linux Kernel code.  Its very annoying! But thing is: Linus released a very 386-optimized UNIX-like kernel and that attracted atention. Plan carefully your releases, even when releasing often. Repetitive and irrelevant releases might also get away with help. I learned this the hard way…

As a last note:

From the last post, I said I was about to test World of Goo. Well…

HOLY SHIT!!!111 Too bad I cant buy it from Brazil. This game is AWESOME! I dont remember playing a Linux game so well finished. Unreal Tournament 2004? not even close! I felt like playing some fancy video game in a last generation game console.

Other game taking my time is Warzone 2100 – a former closed source comercial game made open source and ported to linux. The game is simple, but very inteligent (well, not its unit IA)  and very adictive!

BZK_Vacuum2 for PocketPC – finally!

Thats right! I finally got it working!

And with minimal code changes!

Thanks for the CeGCC project for making this possible!

One thing worth of note:

Its extremelly slow (without any -O at compiling time and with gx.dll, on my iPaq 3660)

I must also add that the game menu is not very QVGA friendly. you cant really see the menu. Only part of the Angstron logo.

This is actually a unfair comparission…with the Nokia 770. The build running on the iPaq was compiled with -O3 and the Nokia is running a -O2 build. The Nokia not only has a complete Linux OS, but also a lot higher resolution and sound. I didnt expected the iPaq to perform so slowly, but its quite proportional to their Quake versions. I probably have to rework the way BZK run on such plataforms…