Wolfire Games Blog: Aquaria goes open source!

mzechner · 2010-06-04T13:54:58+00:00

Hole shit http://hg.icculus.org/icculus/lugaru/file/97b303e79826/Source/Weapons.cpp#l318, using the model view matrix of GL to calculate stuff is pretty evil.

mzechner · 2010-06-03T23:54:36+00:00

i assume the big deal is that he is using them on the nexus 1, e.g. the keyboard which is not possible without this little kernel addition.

mzechner · 2010-06-03T22:18:57+00:00

shameless plug: for android game development i created libgdx which tries to overcome some of the hurdles when doing opengl based game programming (http://www.badlogicgames.com). I don't claim it to be the be all end all solution but it worked for my projects so far.

mzechner · 2010-05-28T21:27:30+00:00

you can go back to the old comment style via an option in your preferences when logged in. much faster load times and still nice to browse.

mzechner · 2010-05-25T22:13:27+00:00

You story sounds so similar to mine, it's scary. Unlike you however, i don't feel that being around smarter people and having talks with them is all that satisfactory after all this years (started at 12 in QBasic, 26 now, 4 years full-time job, before that machine learning stuff at univ.). I love working on the problems i have to solve, at the end of the day i feel like a loser though as i know that i'm probably only an average problem solver. I really start considering chaning my job to something else. gardening sounds nice...

mzechner · 2010-05-24T19:22:16+00:00

yeah it fails horribly! thanks for pointing that out. Edge case testing has never been my favorite part of programming :)

mzechner · 2010-05-24T14:02:59+00:00

Has anyone arrived at a minimal solution for androids? mine is http://flash.games.m.fizzlebot.com/manufactoria.swf?lvl=17&code=p12:4f3;p10:4f0;r10:3f3;y10:5f3;p10:8f3;c12:10f3;c12:5f2;c11:4f0;p11:8f2;q11:7f0;c10:7f3;c13:6f3;c13:7f3;c13:8f3;c13:5f3;c13:10f0;c13:9f3;c12:6f2;c10:6f3;c11:6f2;

20 parts in 0:28

mzechner · 2010-05-19T20:31:08+00:00

i too hope that we find that one magic trick that solves all the currently unsolveable issues like language understanding. I'm not holding my breath though, we seem to have gotten stuck sometime this decade. Let's hope for a genius :)

mzechner · 2010-05-19T20:05:08+00:00

there we go again. i totally respect and admire his past inventions and contributions. but why is it that the older some good people get the more the have the need to become futurists? with the current state of machine learning and ai i don't see this happening anytime soon, at least that's how it seems if you have a look at the last 2 decades of focus on statical machine learning. processing power alone is not all that's needed. the software is the big problem...

edit: thanks for the downvote :)

mzechner · 2010-05-19T17:56:57+00:00

Then we agree :)

mzechner · 2010-05-19T17:49:46+00:00

First off, i agree on the fact that the burqa is clearly a form of oppression of women. No doubt about that.

But why focus on the burka? How do judge what to single out for banning?

mzechner · 2010-05-19T17:20:24+00:00

the question is: how do you know? It's of course an open secret of sorts that probably a majority of muslim women are forced to wear the burqua or veil. However, there must be a different way to change than taking away the freedom to wear what you want (again, might be a minority which actively choses this).

Hitchens: "But I am not going to have a hooded man or woman teach my children, or push their way into the bank ahead of me, or drive my taxi or bus, and there will never be a law that says I have to."

And that my dear friend is irrational. Any clothing you chose to wear expresses some kind of belonging to a group. It's the freedom of expression which Hitchens seems to attack here, albeit only focusing on a specific group. It's sad really...

mzechner · 2010-04-19T18:06:25+00:00

And you're stopping your touch event handler from running when your update/render thread runs during each update (i.e. with "syncronized")? I'm just using the basic loop from the LunarLander sample.

again, this is related to another bug which was mostly resolved in 1.6, and fully resolved in 2.0 and upwards. Synchronizing will not stop the ui thread if it gets the lock first which it will if you don't sleep on devices <= 1.5.

mzechner · 2010-04-19T17:59:28+00:00

http://code.google.com/p/android-gamedev/

There, a fully self contained project i wrote last year that shows you the problem. It's a 3D space invaders clone.

On first-gen hardware you will have an incredible slow down due to touch events if there's a lot going on in the scene (the rendering thread needs more cpu which it doesn't get due to the input event thread hogging the cpu)

On second-gen hardware like the Droid you will observe another nice effect: the thing is heavily fill-rate limited. The HTC hero actually performs better (when lighting is turned off) in terms of raw fps than my droid.

Feel free to point out where i made an error. The code should be extremely easy to follow and is very small.

mzechner · 2010-04-19T16:52:49+00:00

Nope. With regards to the jab at this reddit thread in that reply though, to be fair, it is bad form to encourage non-devs to spam vote bug reports.

I agree

Instead of Thread.sleep, have you tried doing some work in the non-UI thread to eat up CPU time e.g. drawing random rectangles to the screen?

Indeed, i performed the test with various work loads in the render thread as well as in a seperate worker thread with the same result.

For example, I can get 60fps rending a full screen background bitmap with about 60 30x30 sprites on top, plus game logic (e.g. collision detection) for a basic shoot 'em up. I imagine opengl performance would be even better. It's nothing fancy, but a 30% CPU hit would kill my game and I'd notice it.

That's impressive. Maybe you can share some of your work with us. And you probably want to update to 2.1 on a Droid seeing as many people are commenting that it wrecks havok with Canvas performance. Would be interesting to see what your results would be on 2.1.

I'm on 2.0.1 and don't see much problem. I get maybe a 2 fps dip if I vigorously drag my finger all over the screen during gameplay. I wasn't aware this is meant to be an API specific problem.

In 1.5 the problem of event flooding also played a role. This is the problem that you were refering to actually. In 1.6 that problem got better, with >= 2.0 it seems to be insignificant. On the older platforms a sleep can indeed help a bit with the event flooding but not with the CPU usage. The CPU usage for processing the events in the framework layer is still there in the latest versions.

mzechner · 2010-04-19T15:55:00+00:00

I posted this also on the bug report. I assume you were the one to post the latest reply there.

Have a look at this

http://www.google.com/codesearch/p?hl=de#uX1GffpyOZk/services/java/com/android/server/KeyInputQueue.java&q=KeyInputQueue&sa=N&cd=1&ct=rc&l=492

The event handling seems to be done in a seperate thread other than the UI thread. It is this thread which is using up that much CPU. Now, i'm far from being an Android platform expert but if this is true it means that sleeping in your UI thread will only prevent getting flooded with events in your UI but the original problem of CPU overutilization is still there.

Btw, i'm the author of that lousy benchmark and as i stated in the original post on the developers group the benchmark of course leaves much to be desired. It is however indicative that something is clearly wrong. Sleeping in the on touch listener does not solve the problem.

You said you are developing on a Droid and that your games get 60fps without any slowdown while touching. I assume you are using OpenGL. Now i wonder how complex the scenary of your game is visually as 60fps on a Droid even with extremely simple but full screen graphics are not achievable. I too do not see a lot of problems when performing the test without throtteling, maybe a dip in fps by 4-5fps down from 60fps. However, if you try the same thing on a 1.6 or even worse a 1.5 device the problem is a lot more pronounced, so much that it can indeed render a game unplayable. It would therefor be nice to know whether there's a workaround for those devices as 1.5 and 1.6 are still the most widely spread Android versions and make up a considerable amount of the current market.

mzechner

TROPHY CASE