![[info]](http://l-stat.livejournal.com/img/userinfo.gif?v=91.6){kind=small}
windwalkr
Sep. 20th, 2010
10:28 pm - corporate site
We finally organised a corporate site: http://www.typhoonsystems.com.au/
It's ironic that as a technology group, we haven't needed a formal site earlier.
Oct. 14th, 2009
09:16 am - will.i.am
Rocked up to the recent Will.i.am set at Zuri in the valley. The venue's decent - although the kitchen was stupidly understaffed to the point where everyone was waiting 1-2 hrs for meals. The meal quality was acceptable but not excellent. Eat elsewhere unless you've got a group and are willing to drink & chat for hours while waiting.
Will.i.am himself turned up late in the evening for his set and I've gotta say he made the night more than worthwhile. I think I enjoyed his set more than I enjoyed the regular B.E.P. music - and I like the B.E.P. music. If you get a chance to see him in person, DO IT. Apl.de.ap and Taboo turned up just to hang out and look cool.
Much enjoyment, A+++ would buy again.
Someone put some photos of the event online here: http://www.inthemix.com.au/photos29/090
bouncyMay. 27th, 2009
10:00 am - canadia
Heading to Canada for a week, work-related. Will be my first visit there; it's going to be fairly hectic but should be fun. Unfortunately, since it's a short work visit only, I can't bring Trammy with me :~(
'course, that gives her a good excuse to throw a party in my absence ;p
Apr. 14th, 2009
10:27 am - Canberra
Canberra was unexpected. I've never really paid any attention to our capital - I've only seen a few images of the parliament house and heard that it's a planned city. This left me with the impression that it was somewhat like central Washington, which is not remotely correct.
On approach to the city, the maps show that Canberra doesn't have many streets. This gave me the impression that it was a lot smaller than I'd expected. This isn't entirely correct either.
The city gives me the distinct feel that it was built to represent stereotypical Australia. On many of the major roads, you could be forgiven for thinking that you were on a highway traveling through the Australian countryside. There is a huge amount of empty space between everything - it's like the architects took a typical small Australian city and just stretched it out, allowing that everything would return to normal density once the population increased. It's very pretty, in a typical ozzy "dry and barren" kind of way. Lots of grass and boulders and stunted trees.
Apr. 7th, 2009
11:35 pm - Away - family matters
I'm going on a road trip to Canberra, probably drop through Sydney and newcastle briefly. Won't be in any one place for very long, but will be away from brisbane for a bit. Will have my mobile with me so phone or email if anyone needs anything while I'm away.
Apr. 1st, 2009
01:55 pm - new mac
I've ordered a new mac, a trusty sidekick in my quest to take over the world. Admittedly, it's probably the cheapest computer I've ever purchased, although I nearly brought the price back to normal by spending on software ;p
* A baseline mac mini with 4GB RAM (~$1300)
* A family edition of iLife (~$150)
* A copy of Photoshop (~$1400)
* A DVI-to-ADC adapter (~$200)
* The ability to use the iPhone Dev Tools on my Cinema Display.. priceless.
Kind of sad that Photoshop (which I need for very trivial tasks only, but for which there is little in the way of alternatives) costs more than the computer.
Mar. 28th, 2009
04:47 pm - iPhone PNG idiocy
Apple, in their infinite wisdom, deliberately corrupt any PNG files located in your application bundle when compiling for the iPhone. A technical discussion of the changes made can be found here but suffice to say that the end result is no longer a valid PNG file, though it is still readable by Apple's custom PNG codec.
Thankfully, you can turn this behavior off by adding the following option to your target settings:
IPHONE_OPTIMIZE_OPTIONS=-skip-PNGs
Feb. 27th, 2009
11:02 pm - epic thread
It seems that the power of threading should not be underrated. Initial performance results for a double-buffered test (display one texture at maximum rate while loading the other) give the following numbers. (Keep in mind that I'm still seeing 20fps variations in the idle frame rate with no solid cause.)
* 256x256 Blit only: 48fps
* upload 256x256 texture while blitting: 54fps while uploading 21 textures per second.
* upload 512x512 texture while blitting: 36fps while uploading 8 textures per second.
* upload 1024x1024 texture while blitting: 27fps while uploading 2 textures per second.
So it looks like we're seeing a fixed time spent per data size uploaded, and also an reduction in average frame rate based on the size of the texture (I have no data as yet on whether this takes the form of a single pause per upload, or an ongoing penalty across the duration of the upload - i'd prefer the second but the first is more likely.)
It's obvious that this is allowing the subload and the blit to run in parallel, but I'm uncertain whether that means that the GPU has something like a separate DMA engine and pixel pipe, or whether it means that subloading is actually being performed on the CPU while the rendering occurs on the GPU. If it's the CPU (and that would be my guess) then having the subload thread running could really eat into the CPU time available for gameplay. Whether this is a problem depends on the game. It does mean that in a real game, the texture loads will take longer to complete.
It's also interesting that I didn't do anything to "warm" the textures after subloading them. I've previously noticed a significant penalty for the first use of a texture, which I'm not seeing here. My reading of that is that a swizzle penalty applies on the first use after creating a texture, but that subloading to an existing texture pays the swizzle cost up-front.
This does raise the interesting question of how best to make use of the background loading facility for the atlas system. Some possible approaches here:
* Loading two copies of the entire atlas so that I can double-buffer - this seems very wasteful, as it would double both memory usage and effective loading times.
* Keep the atlas broken into a small number of smaller textures. This means that only one of the textures needs to be doubled at a time. Not ideal, but possible.
* Upload to an unused portion of the same texture that I am blitting from (single buffer approach.) I'm not really sure whether this will work, or whether it will crash or force an unwanted lock. I'll need to read up and see if anyone has comments one way or the other.
edit: As usual, nobody seems to talk about this online, but it appears to crash the iphone. Guess that rules out this approach.
* Some fancy scheme involving render-to-texture. Assuming that this is fast (it should be) then it may actually be advantageous in a number of ways. It's still the last thing I want to try - quite a bit of additional work is needed for this approach, and I'd prefer to get a simpler technique working first.
04:52 pm
I still have some testing of the more advanced features (background texture loading, VBOs, etc) to go, but here are some interim results:
* Idle framerates vary wildly. I've seen 60fps (the full refresh rate) and also numbers such as 40fps from the same code on a different run. Perhaps the system is doing background work or in some form of power-saving mode? This is not a major issue except that it brings into question the accuracy of other benchmarking on the device.
* 10 render calls of 100 polys each gives around 59fps.
* 10 render calls of 200 polys each gives around 47fps.
* 10 render calls of 400 polys each gives around 48fps.
* 10 render calls of 500 polys each gives around 36fps.
* 40 render calls of 100 polys each gives around 50fps.
* 400 render calls of 10 polys each gives around 23fps.
* Texture size significantly impacts load times, but does not appear to affect render times.
Note that these tests are designed to measure polygon rates, and use tiny non-overlapped polys. I'll be testing fill rate and overdraw performance later.
So far, it's looking like you should expect around 30fps for a 3D game, and should look to draw no more than 4000 polys, split into no more than 40 draw calls.
It's reasonable to expect that uploading the geometry for each request introduces a delay, which may mean that VBOs could give higher polygon rates by avoiding the upload cost. I'll look into testing this after I make further progress with the texture tests.
Feb. 26th, 2009
11:07 am - Benchmarks
It's taken me longer than I expected to get any reasonable benchmarks. I'm finally starting to see some useful numbers and it doesn't paint a pretty picture.
* Manipulating a texture is slooow.
* Uploading a small texture part is much faster than uploading an entire texture, but it's still slooow.
* Creating and deleting textures, rather than updating them, is really slooow.
* Using an atlas is less important than "they" claim.
* Drawing every polygon with its own texture is still a bad move.
I'll post some actual performance numbers soon, a little more testing is required. I also need to attempt the texture upload on a secondary thread to see whether I can hide the slooow from the user.
Navigate: (Previous 10 Entries)
