soon, on your regular java phone

Right now, this is very slow and mostly unplayable. Its a matter of time for me get this running well in a regular java phone. There is no storage control, as I still dont know how to handle persistence on JME – the map must be exported to java code (by MonoBED2) and compiled into the application. The entire level is being rendered and there is no texture, 3D object, anti-portals or visibility processing at the time. But again, this is a matter of time.

Angstron 2 level 2 running (WGA screenshot resized  and horizontally flipped in GIMP – Im lazy) …

…and its micro edition counterpart.

MonoBED2 test level (again, resized in GIMP)…

…and its micro-edition counterpart.

The weird colours are MonoBED2’s fault, and are happening with regular BZK too.Let me remind you MonoBED2 is a still in construction level editor.

More to come later. Im still a bit busy in the next weeks.

Angstron Micro Edition updated

Finally got some time to get this up and running again

grab it now!

http://batterypoweredgames.blogspot.com/2009/11/angstron-micro-edition-v11.html

Indie game development using ubuntu desktop Linux

In the past years, indie game development went from sitting on dark basement, staring a black and white screen, fiddling cryptic messages to decode the VGA registers in order to achieve the maximum performance to sitting on a dark basement while staring to gorgeous GNOME or KDE screen while tossing the maximum perfomance from your GPU with no sweat. (Of course , some of us still love that darn pretty black screen)

From this dark ages to current days, linux game developement went from an adventure to some serious play, as the tools matured and CG companies took linux more seriously as a development plataform.

This article intends to present the reader with some good options on linux game development, while analysing the reasons of this linux-gamedevelopment-takeoff.

the dark ages
Picture this: You have a prety console screen on your machine. Whats your gaming options? None, you might answer. You cant be more wrong that this.

Before XServers were commonplace, there were already a struggling game development community. Most of them came from the existant BSD community and saw a good potential with that “fast and lightweight UNIX” that linux was (today, both Linux and BSD seen to be in the same level) and then we got our share of console games, like dopewars and other console classics.

Needless to say, developing this games was more challeging than playing them, as they didnt have the tools available today. But these dark ages wouldnt last long.

The golden age of unix graphics evolution
Since the start of the modern computing industry, UNIX was the standard defacto for serious applications and before the macintosh take-over, UNIX was the absolute king for computer graphics.

Then it came. The graphical revolution for the UNIX workstation. First, it was a indutry or office thing only, but then, we gradually , got a XServer running on our machines.

But still, coding a game is XLib can lead to a suicide. How we got such great games like Planet Penguin Racer or Super Tux?

The main reason should be two invetions here:
OpenGL and SDL.

OpenGL opened a new world in computer graphics. Being mostly a Silicon Graphics thing, it was for sure a UNIX-friedly thing. Of course, after passing the hurdles of getting a X window with OpenGL content. With OpenGL we could finally get our Quake after a hard work day.

And while OpenGL did great things for 3D graphics, It carried unessessary weight to 2D Game Development. And the developer had two options: use the unacelerated but closer to other 2D APIs XLib or to go with the (sometimes) acelerated but unatural OpenGL; Some of them ran to GTK and other toolkits, but most got lost on this. And then came this man, Sam Lantinga unify our battlecries.

Sam Lantinga had to port a Macintosh emulator to windows and linux…But hey, coding a graphical system for every Operating System sounds a crazy thing. And it is. He had a simple but dauting ideia: write a abstraction layer, called SDL, and the rest is history : He got Doom ported to SDL is 3 days!

Now we can use SDL in a huge variety of plataforms, ranging from mobile devices (more about this below), Video Game Consoles , and lots of mainstream and obscure operating systems.

With SDL, developers could actually go through the “create window for OpenGL” novella in less than 10 lines of code.And binding for other languages spring every month or so. I bet he didnt saw that coming.
The Java monster

The hearts of millions of programmers (those include even John Carmack) were touched with this promisse: “Now we can write or own AAA game for all plataforms”. Unfortunatly , it took somewhat for the idea to catch on for real. What the java applets really were able to do was a little below that. But still, as Sun released their JDK for Linux, it was quickly possible to write java applets on a linux box and see them running on Macs and windows boxes.

Basically , this was a time for small arcade clones and advergames. And for several startups funded for advergames, the linux +  java applets were the killer combo. Most of the technical staff of those came from those tech geeks using linux since college.

But still, the premier time for smooth java game development was yet to come, and we will return to this later.

Take it in your pocket
If mobile is the name of the game, you’re lucky. Mobile development under UNIX have been strong since the beginning , with J2ME mostly, and now, more recently, with Linux Mobile.

With J2ME , there are plenty of possibilities -Some more mature, like NetBeans and sun WTK, and some brand new, like Nokia’s WidSet. Linux is being taken seriously by the big players, as most inovations in terms of design comes from freedom fighters, like us. The only possible downside of the approach might be the plethora of proprietary protocols mobile phones use to comunicate with a computer through the data cables. Be sure to take a phone that speaks “Mass Storage Device” to the computer.

Recently , we have seen some companies going with linux for their mobile OSes. We all gain with that: this mobile linux is not that diferent from our desktop machine and most SDKs use technologies broadly available. Its like playing with your childhood friend’s child.

One Common point when dealing with mobile game development is the use of Simple DirectMedia Layer. Most mobile distros allow SDL apps to run with privileged speeds. The biggest distros here are: QTopia, from Trolltech (the guys that gave  us libqt), EZX (QTopia based), from Motorola (some warnings apply here, as it doesnt run native applications right out-of-the-box), and mostly Maemo (the one yours humble writer like the most to code on its day-to-day), from Nokia and finally OpenMoko, that is a joint effort to produce a distro for mobile phones.

Also worth mentioning that Ubuntu Mobile is to become a great mobile OS, incorporating the UI from Maemo. Looks very promissing.

The dawn of the desktop

As Linux evolved from the last decade, we could stop worrying about or desktop and could concentrate on producing something. This is a byproduct of projects like Ubuntu, that aims to bring more focus to the developers, putting them to do their best were they excel.

There are also smaller efforts on some countries, like Brazil, to use Linux as a medium of knowledge broadcast, creating social projects that called for more average-joe-friendly desktops. Those are fertile field for Linux gaming.

Also, there are other companies using linux for notebooks (but this distinguish from mobile linux, as there is a full linux machine experience), like ASUSTEK with its EeePC and OLPC (the last one making big bets on educational gaming),each being too big use case to cover here.

Name your monster

Now that you cant wait more to get yout hands dirty, I will show you some good options to develop your own games.

Desktop:
emacs (or your favorite text editor) & g++ :
Thats right! chances are that the exact machine your are using to read this text is capable of game development. Althrough the experience can be somewhat spartan, its perfectly possible. Except for a few moments I ran for some better tools, I went this way to develop my own 3D mobile game engine (www.sf.net/projects/bzk).

Mobile:
If you’re going for java, make sure you take NetBeans, as it have a very strong mobile support. Dont forget your “mobility pack” for the chosen mobile device proile.

If not, you’re gearing towards linux mobile, good and bad news:
The good: most of your existent desktop code will work out of the box.
the bad: you will, probably (as most mobile devices use ARM processors, incompatible with our x86 machines) need to recompile it with some exoteric SDK. And this will depend on the target plataform. Some are easy, some are not. Make sure to also research whats the best settings for your workstation – sometimes, virtualization can be a viable option.

One good advice might be using SDL. I can attest this, as  I do most of my development on my desktop enviroment and when I feel the need, I just switch to the mobile SDK (in my case, Maemo SDK under Scratchbox), recompile, generate a debian ARM package and test it on device (Nokia N770). This can save you valuable debugging time.

Art:
With the arts departament, the best tools (but now the only ones) to use is Gimp and Blender for graphics (with the advantage of running also on Windows, for that goofy friend of yours that still uses Windows) and Audacity for sound (GNU Sound being another viable option). Rose Garden got some fame to be good, if you can get over the JACK nightmare, when producing music (if you cant use Rose Garden, just invite that friend of yours to play their songs, but make sure to turn of the vocal’s mic )

Conclusion:
With so many options, anyone would wonder why are you still reading this instead of producing your next Quake 5. Now , GET BUSY!

Aventuras em EZX – o começo

É isso ai amigos, resolvi investir em mais uma plataforma mobile: EZX. Mas e porque? Bem, Maemo e EeePC são muito legais, mas não tem muita penetração por aqui. Quero tentar fazer algo mais popular. Mas não abandonei elas – vou me esforçar pra lançar a BZK rodando bem nas 3.

Pra quem mora no Brasil , é o que roda nos telefones motorola como o A1200 (meu caso).

Vou comentar agora como tweekar o telefone (testado apenas com A1200i – firmware da claro) pra começar os trabalhos. Não sei da legalidade destes procedimentos. Não assumo QUALQUER responsabilidade sobre o conteúdo deste artigo (graças a deus não temos DMCA).

programas essências (sem link de download porque não quero me comprometer e porque to com preguiça):

-Antes de começarmos, faça um backup da pasta .system do seu cartão de memória. Não ta achando? Ative em seu sistema operacional a opção para ver arquivos ocultos. No Ubuntu basta ir no menu ver e escolher a opção “ver arquivos ocultos”.

- SmartAssist (tentei o MPKG, mas pelo visto o firmware dos telefones distribuidos pela claro não vai muito bem com ele). Ele é o primeiro passo ,para instalar aplicações nativas. Tanto que ele vem como uma pasta .system pra vc sobre-escrever a do seu cartão de memória.

- eKonsole (este foi um cadinho mais complicado de achar): O que será de nós sem um console? será util para testarmos os primeiros passos com o SDK.

- MyStuff – um gerenciador de arquivos alternativo ao padrão. Esse mostra as coisas de verdade.

- EZXSysInfo – um “painel de controle” muito util para você ver as quantas anda seu device, e pra vc saber o tamanho do estrago que teu programa fez ;-p

Boa caçada no google!

No próximo artigo, vamos setar um SDK básico que vai permitir desenvolver aplicações de console.

E pra vc saber oq vem por ai:

Announcing Angstron ME

Angstron has a new brother: Angstron ME (Micro Edition)

of course, for Java Micro Edition. Yes, it will run on any MIDP 1.0 compliant phone!

***UPDATE -  final version here : http://batterypoweredgames.blogspot.com/2009/11/angstron-micro-edition-v11.html

This project is just a simpler version of angstron, with no fancy arenas or anything like that – everything will be wireframe! (think of Battlezone meets Tron).

Screenshot:

Yes, this screenshot is not from the finished game. By now, Im just testing how to move the camera as the player’s vehicle moves around the arena. But the hardest part is done. We have 3D =-)

check it out: http://mosh.nokia.com/content/401C014534D2654FE040050AEE047652

Unfortunatly, I will have to put everything on halt. Its getting too near my final tests and I have a lot to study.

See you soon, my friends

(kudos for Ivan and TK)

BZK updates

its been a lot since my last post. Lots of news to tell:

- the render is FINALLY (after two years!) ready!!!!! bring some champagne!!! Now its time to juice it the most we can

This also means that some shelved levels I did for Angstron will spring very soon.

NOTE: there’s a limitation on the rendering semantics. I will fix/explain/”block from conbed” later. For now, make sure you enclosed the level in order to prevent the sectors to connect to the master sector. This is a ambiguity on the rendering system that Im working right now

- The MonoBED editor (until now, my pet project and a well hidden project) is finally exporting some XML. Soon we will be able to export some very optimized BZK maps without those limitations of voxels , like fixed sector size. Voxel will still have its use, specially for games like Angstron, but for some shooters, better to use a more neatty arrangement.

- newbie_x11 got me surprised again: he’s working a game engine full of physics and good OpenGL powered graphics. the fun fact is that he’s using a good deal of BZK components. Some of them with some adaptations that will be incorporated to the mainstream code. (with some adaptations, in the name of flexibility) – http://newbie-x11.blogspot.com/2007/10/prepare-seu-processador-fisica-chegou.html (pt_BR)

- after some good deal of bug fixed that got the render working, I fixed the coodernate system and thus, I got the Angstron’s AI working better

- A College mate got me a good tip for configuring my Dell Latitude 120L’s LCD Painel:

get this on your /etc/X11/xorg.conf:

Section “Monitor”
Identifier “Monitor Genérico”
Option “DPMS”
DisplaySize 338 212 # 1280×860 96dpi
Gamma 0.77 0.64 0.501
EndSection

replace “Monitor Genérico” with “Generic Monitor” if you use EN_GB or EN_US instead of PT_BR.

- Opera mini 4 Beta 2 is out and its almost like the Opera Mobile I had on the N-Gage. It renders the full page and sports a virtual mouse. Its like browsing on a computer

now the not so good news:

- my Cassiopeia A-11 finally is going to retire: one of its touchscreen sensors finally gave up. It still works, but the touchscreen is worthless. Im going to keep it. Its gona be useful when porting BZK to WinCE. (no, I dont plan to run full blown 3D games on it, but I guess I can run the engine core without graphics on it). Im going to buy some new handheld computer. Im still analysing the options but Im very inclinated to PalmOS handhelds. They integrate with Ubuntu very well.

- Im giving up MaemoWizard development. Its current release works well, but there are already some better projects. But the Mono version project is up and it will hildonize stuff too. (I guess).

gosh, I hate posting very mixed posts like this…It become a tag’s hell. (almost all the tags were filled…)

Nokia Tech Days – Rio – 2007

2 days ago I went to the Forum Nokia event Nokia Tech Days.

Yeah. Forum Nokia rocks as website itself. Even more with such a event.

From start. It was FAR away from home. I slept on my granma’s house, get there faster, but it still took me 3 hours to get there. That was the hard part.

After getting there, I soon noticed what most people praised about the event (aside from its technical excellence): the food. It was great! And there were lots of food. They kept us nicelly fed.

And now, What I was expecting: the speeches.

Lots of technical insights on Nokia plataform, mostly Symbian C++. I felt like “hey…I should have seen this 3 years ago”.

(For those who dont know, I used to make N-Gage homebrew games) . Some palestrants also mentioned Maemo, but only briefly (one of them had a N800 there! I saw it for a moment! live!).

For some, the moment was just like a “developers! developers! developers!” dacing sessions. But I felt (specially on the Browser speech) that Nokia really cares about open source: “take a look at the source. Not only to help improving it or to find bugs. But also to learn how to write one. To learn how to write a XML parser, for example”.This, for me, was the highlight of the event.

Other message that i got is “lets have some sucess TOGETHER”. And it was not just a ceremonial phrase. I could talk later to Jure Sustersic (who seemed very nervous during the speech. Later, I became nervous to have a chat with him in english. My spoken english really suck) and he seemed very cheerful to know that im working with SDL in Maemo and wanted to know the possibilities of running my game engine on Series60 and he replied that he was working (I dont know how officially) with SDL too and the results were great.

The last great surprise aside from the food and the great technical information was to finally meet personally Ivan (yeah…one of the Corporate drones. the one who wrote about java on XGL here) . We indeed took a picture.

In this picture, you can see us just after we were hired as highly ranked nokia executives left the hotel and were about to take our bus’es home.

(sorry. I coudn’t resist the joke. The credentials had the nokia name )

update:

just to debunk an old myth that arised at the conference – Series60 emulation DOES WORK under linux, using wine. (at least with SDK 1.2 for Symbian 6.1 – Borland Edition)

I got this picture using Slax LiveCD kill bill edition some time ago. just to remember: ZERO CONFIGURATION for this to work. even Vacuum1 worked nicely

(yeah…its not the blue thingy. I changed the emulator skin twice. Shame the N-Gage QD skin didn’t worked. It looked so cool!)

Como usar Java com XGL/Beryl ou XGL/Compiz

Eu tive um problema com meu Beryl (mas parece acontecer com Compiz também) em que o Java (no caso, eu testando com o NetBeans) não exibia nada nas janelas, elas ficavam totalmente em branco. Pesquisei na Internet e encontrei um workaround muito simples para isso:

Basta adicionar em seu .bashrc ou .bash_profile (eles se localizam em seu home):

export AWT_TOOLKIT=MToolkit

Pronto! Adicionando apenas esta linha você já poderá usar os programas em Java normalmente.
O que a linha acima faz é, através do comando ‘export’, definir a variavel de ambiente AWT_TOOLKIT para que o Java utilize o Toolkit Motif para suas aplicações, que pelo o que foi notado, ele não apresenta o problema das “janelas invisíveis”.

Espero que tenha ajudado!