090208 / iPhone

previous | next

Rough calculations of iPhone peek ability breaks down as follows as far as I can tell (actuals will be a ways under these),

1. 480x320 screen.
2. 412 MHz (for older model).
3. or about 89 clock cycles per screen pixel at 30Hz.
4. 450-590 Ktri/sec (range of texture+color to smooth shaded).
5. or about 15 Ktri/frame at 30Hz.
6. 24 Mtex/sec (fill).
7. or about 5x overdraw at 30Hz.

In order to better judge what the iPhone is able to do, I'm porting a very old version of the Atom engine to it. The engine still has the tree structured l-system, but since the iPhone doesn't have enough overdraw capacity, I'm changing all the primitives to opaque triangles (ie real geometry) to better work with the TBDR of the PowerVR MBX. Removes the need for sorting, but I'm not sure if the 16-bit Z-buffer is going to work out here. Seems as if the iPhone does software vertex work, so with any luck having 100% fully dynamic geometry won't be a problem. Got the backend (drawing junk) working today (tested on the simulator), everything gets done in a single draw call (ideal batch performance, which is rather important on the PowerVR MBX!).

So the plan is attempt a simple iPhone flying game with an older Atom engine, and with gameplay a like the PS3 Flower game. Difference from other iPhone apps, is that I'm going to compromise everything to try to go for some real view distances (ie awesome LOD), instead of the puny stuff in most iPhone apps. Really not sure if this is going to work or not ... going to have to get a iPod Touch to test with!

ATI OpenGL 3.0 Drivers Out

Looks like I missed this news, but ATI now has OpenGL 3.0 Catalyst 9.1 Drivers for Windows/Mac/Linux. Awesome!

Atom PC/Mac/Linux Updates

Not much so say here right now, work has been busy and live has got in the way, so I haven't had the time.

I've been looking to better solve the GPU side display traversal problems. Problem is mostly that I can only expand and contract the view tree by one node per frame. This leaves holes when things move which I have to fill in during a image space post process. I tried doing visibility checks where I moved the position of nodes ahead in time by a function of their size. The idea was the if a node will take 5 frames to produce pixel sized children, that I would move that node ahead 5 frames in time in estimated position. This worked a little, but not enough to solve the problem.

However I have a new untested idea for GPU side display traversal, which should both reduce me need for vector scatter (ie point drawing in OpenGL3/DX10) by 7x, and should solve the motion hole filling problem. The idea involves doing a reprojection of the previous nodes, then a mipmap style reduction to choose nodes which are in the most need of hole fill expansion, followed by a mipmap style expansion to expand the nodes most in need of hole filling. This should enable me to have a variable amount of tree expansion per frame with a fixed cost!

I've got one other really wacky idea which involves doing the above, but trading the vector scatter for a stable fluids advection style gather. I don't think it would work, but if it did, the algorithm would no longer need to draw points at all, and would be fully general (ie easy to do fast in CUDA).