For the last couple of weeks I’ve been trying to come up with a good semi-automatic resource-loading framework for Plasmacore. For each revision I added a new feature or two to Slag; I ended up not truly needing most of them but they’re good features nonetheless. Here’s a quick overview of the new features – mostly by example.
Some odds and ends:
ITEM: We finished up Wyrmhunter for the iPhone a week ago and submitted it to Apple. They haven’t gotten around to approving it yet, but we’re hopeful it’ll be soon.
ITEM: One of the last major things was a revamp of my dynamic texture sheet management system. With its already limited drawing speed, the best bet for the iPhone is to place all images on one big texture (or several), queue up a bunch of triangles as different images are drawn, and then render everything at once. Even better is if you don’t have to lay things out yourself but can have Plasmacore do it for you as you dynamically load and unload images.
I just finished implementing an automatic texture sheet system for iPhone Plasmacore. By default it automatically places image textures onto a single 1024×1024 texture sheet, creating additional sheets if you run out of room. In addition I’ve transparently buffered all drawing calls, so drawing 50 images will just store up 100 triangles and then render them all at once later.
There’s significant speed-up over my previous implementation, but you’ll still have to be careful. The results:
Looking good for modestly complex games!
I’ve been doing some initial drawing tests on the iPhone with so-so results.
Turns out it uses a graphics chip that renders different tile sections of the screen in parallel. I couldn’t find any info on how big the tiles are offhand.
Here are my very informal results. [Clarification: I'm drawing tile/sprite images as a series of individual calls, each with its own 2D transform]
In 1/60th of a second, the iPhone can draw about:
24 textured polygons in the same spot, quarter-screen size or less.
OR 75 spaced-out polys (32×32 in this case)
OR 6 full-screen polys.
Notes:
- This is with a tight drawing-only loop. Logic & sound adds a bit of overhead – not an excessive amount but then again every bit hurts.
- Things that didn’t significantly improve the speed: turning off texturing, turning off back-buffer clear, turning off alpha blending, using texture formats with fewer bytes per pixel.
In light of this I’m gonna tweak Plasmacore for iPhone so that it’s CYOB (Clear Your Own Backbuffer). Not to save time clearing the backbuffer, but to allow you to get tricky (if you want) and only redraw altered portions of the screen. The good news is that Plasmacore (as usual) will still update() at 60fps no matter how slow the draw() is going, so things might get a little rougher but they won’t get slower.
A final tip will be to avoid drawing font-based text – use prerendered words!
I’ve been encountering some programming situations lately that cried out for some aspect-oriented features that weren’t in Slag – until tonight!
I just programmed this up for a friend who’s wrestling with good ol’ dynamic allocation issues in C++. It’s a “smart pointer” class that takes all the hard work out of managing dynamic memory. You can find this kind of stuff elsewhere on the net too, but here’s my take:
iPhoneCore (Plasmacore for iPhone) is nearing completion!
Item 1: I had an interesting issue today. I’d just got my graphics all drawing when I noticed that my bitmap text was blurry.
Using a trick I’d learned in DirectX, I first tried subtracting 0.5 from each drawing coordinate to compensate for center-of-texel sampling like you have to do in DX. The text was instantly crisp. However:
I then thought I’d see if lines & points needed a 0.5 adjustment, so I drew some lines on the edges of the screen. This graphics test worked fine on the simulator, but on the actual iPhone another problem appeared: floating point error was messing up pixel precision! If I drew lines in screen columns 0, 1, 2, 3, and 319, then line 0 wouldn’t show up, lines 1 & 2 would both be in column 1, column2 would be skipped, and columns 3 and 319 would be fine.
http://www.gamasutra.com/php-bin/news_index.php?story=22093
“We are always going to be dealing with a succession of low-level, non-critical, non-fatal failures that we can then kind of attenuate and make less frequent and make less severe,” the Far Cry 2 developer continues.
“The only way that I can think of at this stage to kind of manage that problem is to embrace it and say, ‘Great. Let’s make sure that we’re prototyping things. Let’s make sure that we’re putting stuff into the game as fast as possible so that we can see if we’re even on the right path with it.’”
While giving a presentation the other day, someone asked me why Slag had so many primitive types. I’d never really thought about it before – I just started out with equivalents of Java’s 8 types as a baseline and added two more I was keen on (unsigned 8-bit Byte and Ternary types).
I’m a better coder than when I woke up this morning, even if I don’t have anything substantive (like an improved virtual machine) to show for it. For example, I now know:
It’s all Joe Eager’s fault (I kid, I kid). Joe mentioned something about threaded code this morning, and soon enough one thing led to another and I was making proof-of-concept virtual machines to test out threaded code with local label jumps – this in contrast to my current “one big switch” architecture and my old threaded code with function pointers.
