Tangent Basis as a Quaternion

Have not done perf testing on this much yet, but if you want to save some memory and bandwidth at the cost of a bit of maths try packing your normal+tangent basis into a quaternion instead. It might be a good option vs 8-bit normals. Can even compress the quat into 3 components too if you assume dot(q,q)=1 by negating the quaternion if w is negative which should work fine if its normalized. I suspect this could be a win for static geometry.

Color Coding Makefile Output

Quick useful tidbit... color coding makefile output...

NO_COLOR=\x1b[0m

OK_COLOR=\x1b[32;01m

ERROR_COLOR=\x1b[31;01m

WARN_COLOR=\x1b[33;01m

OK_STRING=$(OK_COLOR)[OK]$(NO_COLOR)

ERROR_STRING=$(ERROR_COLOR)[ERRORS]$(NO_COLOR)

WARN_STRING=$(WARN_COLOR)[WARNINGS]$(NO_COLOR)

You can then echo out $(OK_STRING), $(ERROR_STRING) or $(WARN_STRING) depending on if errors were encountered. Errors are Red, Warnings are Yellow, Success is Green. If you want to know what the goofy strings like "\x1b[32;01m" actually mean, well it really should be obvious, duh! But in case you can't decode that enigma of a color coding scheme you can read about it here.

The only tricky bit then is just conditionally echoing the right string. Personaly I found the easiest way is to use temporary files to determine if the build was a success or had errors/warnings . But maybe there is a cleaner solution that doesn't require temp files?

@$(ECHO) -n compiling debug foo.cpp...

@$(CXX) $(CFLAGS) -c foo.cpp -o $@ 2> temp.log || touch temp.errors

@if test -e temp.errors; then $(ECHO) "$(ERROR_STRING)" && $(CAT) temp.log; elif test -s temp.log; then $(ECHO) "$(WARN_STRING)" && $(CAT) temp.log; else $(ECHO) "$(OK_STRING)"; fi;

@$(RM) -f temp.errors temp.log

For those that don't like writing makefiles explicitly, XPJ currently supports this color coding mechanism and leaves the OK/ERROR/WARN strings defined in the user specified platform file so you can alter the colors or disable them entirely.

Eye Candy: GTC Demos

Here are some videos of the tech demos used during the GPU Technology Conference Keynote this year which were all simulated and rendered live in real-time. Our goal was to take the bits of tech we were each working on and produce a small demo of it to give the audience a taste. All the demos were presented in 3D Stereo and looked amazing. So, in order of appearance...

- Simon Green made an excellent demo of fluid dynamics.

- Sarah Tariq made a pretty kick ass demo showing off the turbulence (sorry for the really poor video, a better one will be posted soon I am sure).

- And I made a demo showcasing physical destruction with some comedic relief.

stb_truetype: my experiments

(Blogger scaled the image down slightly so click to enlarge)

Recently I discovered that Sean Barrett has put up on his website a nice little True Type font rasterizer. The keyword here being "little", compared to FreeType its microscopic with less than 1600 lines of source code in a single file. FreeType on the other hand is about 6.5MB of just source code... I have worked on games with less source code! So the possibility of tossing out that much bloat is really appealing to me.

Anyways upon finding this I quickly tossed it into my hobby project game engine to compare performance/memory/quality to FreeType with the assumption that it is probably faster, probably thrashes memory less and quality is probably roughly the same. Here are my discoveries:

Performance
This was a big shocker to me... FreeType was a good 3 times faster than stb_truetype at rasterizing a font of about 350 characters at height=14 pixels 8ms vs 26ms... thats almost double a single frame's budget! Granted usually you rasterize fonts once during loading and if you only have 1 or 2 fonts this is probably a non-issue, but if you have lots of fonts and supporting asian localizations this could potentially add seconds to your load time and that might be a deal breaker if you are already barely squeezing into TRC load time requirements. If you are dynamically caching fonts (like because you support rich text or something) this could be make it quite difficult to keep performance up. Luckily in my situation though I am pre-baking my fonts in my tools chain not at load time so performance isn't quite a deal breaker but I would prefer not pre-bake if performance was good enough. One thing to note is that in stb_truetype I was able to set it up to rasterize directly into locked texture memory whereas FreeType has no such API so I have to rasterize and then blit into texture memory so in a way FreeType was given a small handicap already.

Memory
Because I rasterize glyphs one by one the peak memory consumption for both FreeType and stb_truetype is quite low (just a few KB). But the number of allocator calls for both is quite high. Oddly enough again stb_truetype hammers on the allocator more making ~8,000 allocations versus FreeType's ~3,000 for the same font. Neither particularly makes me happy as a runtime solution. But the good news here is that while I would not want to touch FreeType's source code with a 10 foot pole, looking around in stb_truetype's source I believe I could stick in a relatively small fixed size pool and make stb_truetype run without any allocations of its own. So there is actually quite a bit of hope here.

Quality
Quality of stb_truetype isn't terrible but its not great either. FreeType comes off much cleaner and more closely matches the way Windows rasterize the same font. stb_truetype always comes off a bit bolder than it should be, a bit blurrier and a few artifacts like some characters being 50% transparent. Overall I think quality is probably acceptable for games and tools, but I wouldn't be shocked to have a few artists complain about it looking different than it does in Windows.

Mikko Mononen brought up www.codinghorror.com/blog/archives/000884.html. I am not so sure yet if the differences are within the same threshold or not, but I suppose its possible the quality is no more different than OSX vs Windows (which, btw I think fonts look better in OSX).

Final Verdict
I am not quite ready to toss out FreeType yet, but I am awfully tempted. I think all the issues with stb_truetype can be resolved without too much effort so I fully expect to be giving FreeType the boot eventually.

So I might try this blogging thing again

So I decided I might try this blogging thing that all the cool kids are doing again, but this time instead of trying to ramble on about my day to day life which is not particularly interesting I figured I would use this as an outlet for my ramblings on technology, algorithms and random bits of code.