今天调了好长时间的光线，还是有错误，郁闷。

有点想放弃 rika 引擎了，开始查 Unity，翻 ZBrush。无意间碰到这个 miku blender model　就导进来看看，居然一次就通过了，相机和模型都正确渲染，有点出乎意料。

想了想，决定还是继续弄吧，不过进度确实太慢了。

Haskell language only benefits programmers / researchers who write in it, not necessarily the end users or even library users, in particular, me.

I tried to use darcs, it's too slow.

I tried yi, it's too slow. It's amazing how a text editor can be that slow.

I could not use Happstack, I didn't understand its type.

I still can not use iteratee, since based on my skill, I can't justify the roi.

I don't understand most of the blog posts on planet haskell.

Something's not right.

Well I know I'm stupid, but maybe a language this smart is not helping at all.

My stupid deferred shading algorithm seems to come together piece by piece, need to fix some non trivial bugs in the math lib to get it to work.

I really like the idea of deferred shading, it's an example of wholesale / data driven algorithm. Just love it.

Finally ported to OpenGL ES 2.0. It's a shader oriented renderer now.

The only difference between a desktop GLUT version and an OES embedded version is:

precision mediump float;

in fragment shader, otherwise the shader won't compile, no idea why.

Something is wrong with the current IORef implementation on iPhone. I decided not to invest further since tackling both graphics and sound synthesizing is a bit too much work.

I'm re-implementing the rika's rendering engine such that it's 100% OpenGL ES 2.0 and not backward compatible. The reason is that OpenGL ES 2.0 is a completely different interface than 1.1, keeping a separate rendering path is too much trouble.

I was able to implement the matrix and associated transformations in Haskell, the way ES 2.0 / GL 3.1 works is that there's no push / pop matrix anymore, perspective or frustum to setup projection matrix are also gone. The programmer is responsible to tell the graphics card which transformation matrix to use. It's actually more flexible than that, you can send arbitrary matrices to the graphics card (technically through uniform), and then in shader code utilize these matrices, one of them could be used as a model view matrix, another as projection matrix. Other variables could be passed as well, which could hold lighting position and material properties.

I wish someone could tell me these before.

Flashback, I wasn't able to take the computer graphics course in collage, it was a tough decision though: I had to pick an elective course either in music or programing since they are offered at the same time slot. I chose a music course, and never regretted it. But still this desire for computer graphics just kept haunting me, it's like this frikken awesome girlfriend I can never have. Finally enough is enough, I'll do it.

Anyway, for the audio part, I'll probably stick with OpenAL for simple playback and maybe pick up some Open Sound Control (OSC) code to interface it with some real synth. Still in control, yep, ... i hope.

There's no problem running nana (the Eutperea no TH port) on a simulator, but I just can't get it to run on a device.

It looks like a problem with IORef, but I had no problem with it before. It might be that the buffer is just too short, or that the remoteIO is running on a separate thread, I don't know yet.

Or is the IORef overhead be too large? Can it be solved by a faster CPU? I'm using a second generation iPod Touch, which is about twice as slow as the latest iPhone 3GS.

Anyway, I found a way to freeze an iPod touch though (restart required), just use remoteIO with IORef ...