Blog for Alex Scarborough at GarageGames.com

Various musings

Alex Scarborough — 2007-08-31T18:53:55+00:00

So... it's been about six months since my last .plan. I've been kinda busy during that time. Also, sorry, no pictures in this, so those of you who only look at my .plans for the shiny can stop reading now.

1) I interned at GG for five months (Late Feb. to late July). I did... stuff. With an engine. And code. Hopefully that isn't giving away too much. It was a lot of fun though and everyone there is essentially awesome. It was a learning experience for everyone involved. I'm a self taught programmer and had never worked in a real team before, so certain things (e.g. style guidelines, "formal" research, meetings, priorities, deadlines) were new. Also, I now hold the record as the youngest GG intern.

2) The Modernization Kit has gone through a few revisions. Right now though, it's on its last legs. I've hit the point where any further work on it would be equivalent to rewriting TGEA. Only crossplatform. For free. I don't have that kind of time on my hands. If anyone thinks they can continue working on it please let me know.

3) OpenGL 3.0 will be released next month. For those of you who don't know, OpenGL 3.0 is completely new. The ARB threw out the old spec and started over from scratch. Based on existing information, what they've created is phenomenal. OpenGL 3.1 will likely be released 3 months after 3.0, and Mt. Evans (Think D3D10, only with a C API and crossplatform) will probably be released 3-5 months after OpenGL 3.0. It's an exciting time to be an OpenGL programmer. I shouldn't go on too much about this. I'll start sounding like a rabid fanboy.

4) I'm currently attending Arizona State University. As a freshman. Or a sophomore. Really depends on who you ask. I'm majoring in Computer Science. I'm currently taking Introduction to Computer Science with Java. I don't want to talk about it.

And... that's six months distilled into a couple hundred words. It's hard to provide actual content when the bulk of your time is under NDA.

Modernization Kit: Now on Windows!

Alex Scarborough — 2007-03-01T07:18:19+00:00

I think the title explains everything, but anyhow, the Modernization Kit now works on Windows. You should check it out if you're into crossplatform shaders, render to texture, and other such shiny things.

<total shameless self promotion>
The Modernization Kit is one of the largest free addons to the Torque Game Engine available. It includes crossplatform support for GLSL, Cg, ARB_vertex_program, ARB_fragment_program, and ATI_text_fragment_shader, as well was crossplatform support for render to texture through framebuffer objects and GL vertex buffer objects.

To demonstrate the uses of this code, the Modernization Kit makes extensive modifications to interior and water rendering, including support for parallax mapping on interiors and reflective/refractive water. The Modernization Kit also features a completely shaderized version of the Dyanmic Range Lighting resource which has little to no impact on framerate in most situations.

The Modernization Kit has been designed to be easy to integrate. All modifications to existing Torque code are clearly marked and all major additions are contained in new files in the ModernzationKit directory. Combined with included project files for VC7, VC8, and XCode, integration into a new or modified copy of TGE is a snap.

It's completely free, so download it today!
</total shameless self promotion>

There's a reason I'm not in marketing you know.

Obligatory image (it's new!)

A couple of personal records

Alex Scarborough — 2007-01-31T06:23:20+00:00

Personal records recently set:

1) Most .plans in a one month period (This makes 3. Hopefully I won't break this record)
2) Longest continuous non-multiplayer gaming session (Alpha Centauri is really addictive)
3) Most code trimmed in a single day (Nearly 2,000 lines, or about 1/4 of the total size of the project).
4) Weirdest bug ever fixed (GCC apparently thinks that it isn't really important to use FrameAllocator before writing to memory that should be assigned by the FrameAllocator).
5) Largest personal project released to the general public (or at least TGE owners).

Ya, about that last one...

You know that thing I've been talking about on an off for a few months now? The shiny thing with the pretty pictures and the reflecting water and funky colors? Something to do with shaders and crossplatform and TGE. You can totally download the source code for that now. Isn't that just, like, awesome?

Now then, the whole "crossplatform" thing didn't quite work out. There is no Windows or Linux version at the moment. If anyone would like to help in porting this over to Windows or Linux (there shouldn't be too much work involved), let me know.

In the meantime, here are some screenshots which asmaloney (Andy) took. As far as I know, Andy is the first person (besides myself) to have integrated this into Torque, and also reported the first bug. Go Andy!

Before:

After:

Before:

After:

Before:

After:

Read a manual today!

Alex Scarborough — 2007-01-27T07:14:35+00:00

In my last .plan (waaay too many of my .plans start this way) I mentioned that I'd like to put up information on my work in a series of blogs, discussing design decisions, how the various components evolved, where there are now, etc. About half way through writing the first one, I decided it was incredibly boring, and figured if anyone wanted to learn stuff about the Modernization Kit, they'd just read the manual.

Here's the manual.

I went through the source, documented just about everything worth documenting (and a lot of things not worth documenting) and ran dOxygen on it. The result is the closest thing the ModernizationKit has to a manual at the moment, so if you want to know more about what it does and how it's structured, this is it.

The rough timeline to release says that I should be locking down the feature set and class list early February, after which it's test test test and getting a Windows port (there's a phrase you don't see too often) underway. The initial public release will be version 0.8, as I still have a few things to add before I'm comfortable calling it 1.0, but I figure that anyone who wants it wanted it six months ago and doesn't care if the code is a travesty against mankind.

In closing, have a picture! I've probably already posted this one, but it's the most recent one I have and the latest build is busted... oops?

If you have any comments, questions, cease and desist letters, whatever, feel free to email me, bug me on AIM, or leave a comment. My email address and AIM screen name are both in my profile.

Old games and new tech

Alex Scarborough — 2007-01-04T06:59:18+00:00

As most of you know, I primarily work with the latest tech (or at least the latest I can work with on my little Radeon 9600), and immensly enjoy working on shaders, render to texture, and other such spiffy things. And, as a Mac user, I focus on OpenGL work, keep up with the latest OpenGL news and such (Long Peaks!), etc. So, what games do I like to play? With an immense interest in the latest and greatest in crossplatform rendering, do I eagerly play the latest games with the prettiest graphics?

Eh, no, not really. In fact, to be perfectly honest, I don't own a game made after, oh, 2003-ish.

My top game at the moment? Who remembers this beauty:

Ya, it's the original Command and Conquer. Someone put it up on GGE, and I got out the old game discs to see if it still worked under Mac OS 10.4.8 (It was written back in the days of 7.5.3). I figured, what, play a couple of levels just to see if it still works, awesome if it does, meh otherwise.

Ya, just a couple of levels, sure. So now I'm about halfway through the GDI campaign...

I miss games like this. The learning curve for Command and Conquer is about 15 minutes. As far as RTSs go, it is dead simple. But it's still incredibly fun and engrossing.

Anyhow, I'm sure you're all more interested in what I'm doing with Torque than what random 12 year old game I'm playing.

Right now, I have three primary goals

1) Get all of the various features in (I'm a feature creep, I need to not feature creep, but the features are so useful they border on/are necessary)

2) Make it crossplatform and consistent. Everything should work on Mac and Windows (maybe Linux if there's anyone with a lot of experience with Linux, Torque, and OpenGL), and the code should follow the same general patterns. For example, at the moment, VBOs are tracked by a linked list, but Shaders are tracked by a Vector. Bad me!

3) Document it until I want to jump off a bridge. Then document it until I do jump off a bridge.

Here's some sample documentation, just to torment you with little morsels of information.

Material system documentation

Detailed method descriptions for mkInterior

I LOVE dOxygen.

Moving on, unless there are any complaints, I'm thinking about running a series on the various components of the "Modernization Kit": what design decisions went into them, what they can do, and other such stuff. Basically just something to help keep my thoughts a bit more organized and keep the community up to date on what I'm hoping to release. I'd put up a .plan once every two weeks or so covering a different area (Shaders, Materials, RTT, etc.).

Also, check out my ImageShack feed. I use ImageShack for just about everything, so any update on documentation, shiny new features, or whatever I happened to find cool will show up in that. You can even go back and see just about everything remotely borderline interesting I've done since September 25, 2005. In all there are over one thousand images, so... have fun.

Here are some of my favorites:

One of the earliest DRL shots. I'm not even sure the resource was released when I took this

Crazy colliding particles

Original Cg water resource on my mac

An early GLSL experiment

Fun with detail textures

This may indicate that there is a bug in the shader

Refraction is pretty

Bloom is not always your friend

Specular highlights and bloom can make a good combination. Also, look at all that refraction

Torque was probably not meant to handle that

Fun with color

It's Illumina!

Torque definitely wasn't meant to handle that

I finally read up a bit on global illumination

And Kork feels pretty

I also read an article on sub surface scattering. Hmm... sorry howie!

Spooky windmill

GUI fun

Procedurally generated normal maps which suck less

On a final note, look what was in the January 2007 edition of MacAddict

Anyone recognize that as Buccaneer?

Restructure, Refactor, Rewrite, Re...

Alex Scarborough — 2006-12-13T06:47:32+00:00

Sorry, not many shiny pictures in this one.

End year two. It doesn't feel like it's been that long...

This is mostly a look back on how the past year has gone, and what I have planned for the (hopefully near) future.

So, first big thing of 2006: Dynamic Range Lighting

Wow, that was a fun resource to release. First a huge thanks to Jeff Raab (my usual partner in crime) for getting the windows version up and running. Next another huge thanks to John Kabus for working with us on the finishing touches, releasing it, and ensuring that we didn't accidentally hurt sales of any products (*cough* TLK *cough*).

In the ultimate irony, I did not own a copy of the TLK when the resource was released, and went a week without being able to access my own resource. Oops. So ya, just so you know John, I bought the TLK entirely to use the DRL resource.

Next action of 2006: Dynamic Range Lighting 2.0 Right, who saw that coming?

I also submitted an IOTD for this resource, which despite all logic actually went up. In addition, it had downloadable precompiled executables for Mac and Windows, and loads of happy documentation. It was more like a miniature free product release than a resource release. Only without as much QA, which lead to a couple of bug fixes that not everyone picked up on. All in all though, it went over pretty well.

And here I drop out of submitting resources. Sorry about that.

Not that I didn't write up some possible resources. I put together a GLSL version of the TGE water upgrade resource (which I believe is the most popular resource ever released, way to go Manoel!). Initially I wanted to break my work up into two resources. One resource would be a very simple integration of GLSL into TGE, making it easier for various objects to load GLSL shaders and generally being cleaner than previous shader integrations (read: I added a couple of dgl functions to load shaders), the other being GLSL water. Manoel believed that a GLSL integration should have lots of solid examples behind it, such as bumpmapped interiors, reflective water, and DRL.

I figured why not, and promptly moved all of the resources over to GLSL.

<insert quiet hush hush stuff I can't talk about>

Sadly the resource was never released.

However, I did work closesly with Jon Jorajuria, Alan James, and Ian Roach on adding these GLSL enhancements to their awesome games. Thanks guys for testing and abusing the code!

The Illumina demo marked the first time the GLSL work I had done was available to the general public in any form.

It sucked. My bad. I hadn't considered that people wouldn't have updated their drivers since 2004/5, nor had the code been extensively tested on cards which don't support shaders. Untested code is buggy code, and damn did it show.

I don't want to talk about that anymore.

Around the same time as the Illumina release I wrote up the OpenGL FAQ and Shader FAQ articles on TDN. Check out the OpenGL one! It got lots of love and includes tons of neat little tips on how to use spiffy OpenGL features like FBOs, VBOs, GLSL, and more!

Please ignore the shader one. It is unloved. Maybe you can give it some love.

Now about here I basically drop out of everything (as far as you know). I resurfaced once a month to post a .plan and, word to the wise, my .plans usually said nothing about how I was really spending my coding time.

Would you like to know what I've really been up to?

The last update of my GLSL code that went out to the few people I was working with was from June 28th. July 1st, I ripped out everything I had done and started over from scratch.

The GLSL code as of June 28th was modelled much like the existing Cg resources. Each object was responsible for tracking its own shader, etc. Happy fun with making sure they all loaded, that shaders were supported, and, best of all, ensuring that they were properly reloaded when our context was destroyed and a new one created. Clearly no way to handle shaders.

From this desire to keep shaders centralized I wrote a shader manager for Torque.
ShaderManager function list (well, half of it, give or take).

The shader manager uses a pure virtual class, Shader (aren't my names so imaginative) to handle all shader management, and all objects which use shaders also deal with the Shader class. Behind the scenes, there are actually four classes which implement shaders, GLSLShader, CGShader, ASMShader, and ATITShader. Each class handles a different kind of shader, and together they allow you to load crossplatform shaders on almost every programmable GPU, from the GeForce 3/Radeon 8500 up to the GeForce 7950/Radeon 1950 (sorry, no 4.0 shaders supported). In addition, as you may note, the shader manager allowed for setting global paramters, which applied to all shaders. What you can't see is that global parameters could be set from script, allowing for easy script control of shaders (yay!), and all global parameters could be saved into a .cs file which could be exec'd on launch to reload and initialize all global parameters (some of this was written entirely for the shader IDE I mentioned in my previous .plans).

But of course, shaders are only part of the equation.

Meet the Modernization Kit!

Remember that resource with spiffy GLSL stuff that I never released? Be glad I never released it. You're looking at the latest incarnation of where that has gone. I am currently going through and moving as much of the code as possible into separate files, and clearly marking all changes for easy merging.

Some things you can glean from that short little file list: Shaders, vertex buffers, a material system, DRL, and some sort of GLSL validation.

Shaders are essentially the shader manager described above, though it is currently being streamlined to work better with the material system.

Vertex buffer objects: They're vertex buffer objects. mkVBOManager.cc contains all the code which manages VBOs, allocates them as needed, and wraps using them.

DRL: DRL is being moved out of scenestate/scenegraph (WHY DID I EVER PUT IT THERE? WHY?!) and into its own class. Because DRL has virtually no reliance on anything Torque specific (getting window size is probably the most Torque specific thing it does), this class will be essentially drag and drop into any OpenGL based engine.

Materials: mkMaterial.cpp. At the moment, the material system is a very basic script interface that allows you to explicitly specify shader fallbacks. It also contains some early code for setting parameters in script on a per material basis, and loading shaders based on a user set shader quality level. It may be expanded to modify other portions of the current rendering state, but this is highly unlikely.

I'm restructuring, refactoring, and rewriting all of this old code, documenting it, expanding it, testing it.

Only one thing left to do when that's all done with.

See you all next month!

Just another month gone by

Alex Scarborough — 2006-11-10T09:07:04+00:00

And another month goes by. I've been using Torque for almost two years now, and I still feel like a noob.

In my last .plan I mentioned a fair number of resources I intended to release when 1.4.2/1.5 came out. I'll get to those, hopefully in the next couple of weeks. I've been too busy moving all of my other code up to 1.5 to work out those resources and such.

On a related note, I am extremely happy that I decided to encapsulate all of my shader code in its own files outside of Torque proper. That made the upgrade much smoother. It also made it easy to put shaders into TGB, not that I'm planning to do anything interesting with that.

It's doing... something. Don't ask me what. It requires a Radeon 9500 to do it though!

Also in my last .plan I discussed creating a Torque based shader IDE. It's come a fair way since then. It actually works now.

Oops, made a typo

It also works with Cg as well.

I said it works. I didn't say it looked pretty.

While I still don't intend to develop this into a serious IDE, I am reevaluating my previous idea of just stopping at being able to write some simple shaders. On one hand, there are plenty of nice shader IDE's out there that are amazingly good at what they do. On the other hand, there isn't a single shader IDE that is crossplatform or supports GLSL and Cg, or supports the OpenGL assembly shaders. Therefore, while I still don't want to create an application that does everything FX Composer or RenderMonkey does, I am considering putting in some more advanced features to help even the playing field a bit, so to speak.

Anyhow, enough serious talk, let's see some shiny pictures!

More here.

All said and told, it wasn't my most active month ever. In large part, that's been because of the 1.5 release, which forced me to go back and look at all of my old code. A pretty decent chunk of it is getting an overhaul to help streamline it, document it, and improve overall readability. In other words, it finally occurred to me to actually document that shader subsystem I wrote.

Oh, and the Cg runtime environment drives me insane. Just wanted to throw that out there. See you all next month!

Shiny pictures and upcoming resources

Alex Scarborough — 2006-09-25T06:57:26+00:00

It's been nearly a month since my last .plan, so seems like a good time for another one. And what a month it's been. Actually, what a week it's been. Illumina released a public demo, which marks the first time my shader work has been available in any form to the general public. Some people liked it, others didn't. Many had outdated drivers. It's definitely a learning experience for everyone involved. On a more personal note, I can't play the Illumina demo because I don't have a PC. So, I have no clue what it really looks like. It'd be great if someone could send me some screenshots or something.

More recently, Alan James put up a .plan showing off some new screenshots of Code Name: Monster Island. To be perfectly honest, I thought that Alan had switched over to TSE. Between the insane detail on that sewer monster, and how stunning the TLK shadows look it just seemed like TSE. Definitely a reminder that while code can improve the look of a game, nothing beats good art.

But what have I been up to? Believe it or not, I have been primarily focussing on backend work. Things that aren't shiny. Things that don't involve rendering at all. Well, mostly. I've done some rendering work.

First of all, I recently acquired GPU Gems, ShaderX3, and ShaderX4 (IGC refund). They're all incredible books, and anyone with an interest in rendering with shaders should seriously consider purchasing them.

Of course, it's hard to have three shiny new books on shaderized rendering, and not try and implement at least one effect. I decided that sub surface scattering was sufficiently shiny, and required very minimal work to get a basic version of it running. Kork got a nice overhaul from

to

Combine that with spherical harmonic lighting...

And then for kicks, do some image post processing

Not bad for an hour or so of work. That sums up my shiny rendering work in the past month though. So, let's look at the backend work I've done. I swear it isn't (too) dull. If it is, just skip to the end of the .plan which discusses those upcoming resources promised in the title. Then come back here and read about the boring backend work because it is the upcoming resources.

Torque's GUI System
has issues. Let's look at this example of a reasonably nice GUI:

Notice that it is instantly obvious that the last scrollbar is inactive. That should be a very simple thing to do. And indeed, Torque's gui system does have a nice setting for an inactive color to use if the control is inactive.

At least, it would be a nice setting if any of the gui controls actually used it. Oh, sure, guiTextEditCtrl uses it somewhat, but that's really about it. guiSliderCtrl? Nope, not at all. That was actually rather irritating, and was also a five minute fix.

Look ma, it's inactive!

After some more tweaking, I was able to get the default gui rendering commands (that maybe 1/2 the guis use) to use the inactive color so long as they are told that the gui is inactive. It isn't complete, but it's a start.

So, here's a shot of the sample GUI above, slightly modified, in Torque.

guiMLTextCtrl
Oh man, where to start on this bad boy. The code is messy and buggy. Things like selecting text in the middle of a line simply don't work. It subtracts 64 from 64, multiplies by 3, adds 1, and wonders why it doesn't get 12. Again, most of the bugs prove to be a simple five minute fix.

How I feel after having to fix setting the cursor position.

With these little bugs fixed, I tackled a somewhat larger task. Something which has been attempted on a couple of occasions is syntax highlighting in GuiMLTextEditCtrl, most notably in the script editor resource. However, using TorqueML to do syntax highlighting is a bad bad thing.

So I wrote a script controlled system for doing syntax highlighting.

Yes that is GLSL. Yes the colors are a little odd. I lifted them directly from Apple's GLSLEditorSample. In the console, I'm about to tell that GuiMLTextCtrl that half3 should be recognized as a GLSLDatatype keyword. No, half3 is not a GLSL datatype. Welcome to the joys of optimizing GLSL for nVidia cards (see those messy #defines at the top of the file? They are the happy dance GLSL developers must go through to make GLSL not suck on the FX series).

Dynamic Range Lighting
There are now, what, four dynamic range lighting resources for TGE? Three of which I've either written or include my code. All of them have one major caveat: they all force a sync point between CPU and GPU. This sync point kills performance, and can cause some decidedly unpleasant issues. TSE's DRL implementation avoids the sync point by not making the DRL effect dependent on any previous frame, which has some downsides of its own.

But hey, we have shaders now. Textures can hold whatever kind of data we want. Why should they be limited to lookup tables and color information?

So, I moved DRL over entirely to the GPU (if it has access to shaders at least). No more sync point. It determines the new tonemap in a shader, writes the scale and bias into a 1x1 texture, and then at every pixel during DRL rendering it grabs the scale and bias from that texture and applies it. This 1) brought a 20-50% FPS boost, which is just plain awesome, and 2) makes it very easy to adjust the DRL effect as a whole. All the CPU does is bind the various shaders and tell the GPU to downsample some textures. Shaders handle everything else.

How does it track data across multiple frames? A cheap hack. It has two 1x1 textures, and simply alternates between them. When writing data to one 1x1 texture, the other is bound and the current DRL info is read from it, modified, then written into the texture.

As a result of this, something happened that I haven't seen in a long long time. Torque became CPU bound again. Time spent in OpenGL went from 60-70% to 30-40%. Surely though, that number can be improved...

glBegin
is the devil. Here's a shot from the OpenGL Profiler, showing the top 3 most time consuming OpenGL calls in Torque.

Look at #1. Look at just how much more time it takes over #2. Look at how each call is, on average, 150 more expensive than #2.

I've begun a quest to completely purge glBegin from Torque. Does anyone want to help me?

TGE Shader Demo
I've been planning to release a demo of my shader work to the general public for some time now. The original plan was to have it ready for IGC. When IGC was cancelled, the demo was backburnered for a while. It's slowly coming back up on the list of things to do though. In fact, you probably noticed that my example gui was a shader parameter editor, and that my example of syntax highlighting was GLSL.

I've dropped the idea of a simple demo to show off what I can do. That's dull, and nothing more than an ego booster. Instead, I'd prefer to see what everyone else can do. Instead of releasing a demo showing off my work, I'm now planning to release a Torque based GLSL shader editor, allowing people to write and test their own GLSL shaders in a real game environment. Furthermore, it will be crossplatform unlike FXComposer or RenderMonkey, allowing Mac and Linux users to get in on the fun as well. It won't be as full featured as FXComposer or RenderMonkey, as the goal is to provide a sandbox, and not a serious shader IDE.

At the moment, I have around 80 example shaders, in addition to four libraries of shader functions, including image manipulation and lighting effects, which GLSL shaders may be linked against. I have also integrated 3Dlabs' GLSLParserTest into Torque, allowing people to check how conformant the GLSL implementation of their driver is with one simple console function.

You know what? Just supporting GLSL is boring. The TGE Shader Demo also currently supports Cg, ARB_vertex_program/ARB_fragment_program, and ATI_text_fragment shader. Admittedly, a fair amount of work still needs to be done to get those up to the same caliber as the GLSL implementation, but it is capable of loading and using shaders in those languages.

But that's all down the line a bit.

Upcoming resources
The gui work I've done will be packaged up into a resource after TGE 1.4.2 is officially released. It's quite handy. Jeff "Reno" Raab is also currently working on an integrated script editor using the syntax highlighting code I've written, so that should pop up within a month or so as well.

In my quest to purge glBegin from Torque, I've rewritten the particle and decal renders to batch rendering (and in the process broke the TLK enhancements to decals and particle emitters). Resources for those in stock TGE will probably go up after TGE 1.4.2 is officially released, with TLK resources shortly afterwards.

I will probably also release a modified DRL resource which purges glBegin. glBegin isn't exactly a major issue when DRL is running, but every little bit helps.

While I'm at all this batching, I should probably fix the precipitation renderer. Another after 1.4.2 is out resource.

And then there's the TGE Shader Demo. Ideally, I'll have that out before then end of this year (maybe later if I have to buy a commercial license to release it since it isn't a game). I'm trying to make it as easy to use as possible, which will probably necessitate a couple more editors, various features, and a lot of gui work. I also need to triple check the 3Dlabs license, seeing as a pretty large chunk of the shader code used in the TGE Shader Demo came straight from various 3Dlabs samples and utilities.

Well, that sums up my month. Or at least what I did with my free time in the past month.

If anyone wants to try out the gui fixes/enhancements or batched renderers before I put them up as resources, just email me and I'll be more than happy to send you what code I have right now. I really could use some feedback on how useable the syntax highlighting is, and if the batched renderers bring any sort of significant performance boost.

Back from a much needed break

Alex Scarborough — 2006-08-27T08:34:02+00:00

As some of you know, I recently returned from a nice (and much needed) three week vacation. By recently, I mean a week ago. Since then I've been quite busy putting together demos of my work, doing more TGE work, and just in general working. In fact, this weekend I'm doing something completely new: not working with Torque at all. It's really about time I learned to pace myself and work somewhat more reasonable hours.

Of course, I'm a workaholic, so I had to find something else to do to fill in the void. I started dumping my OpenGL and shader knowledge into TDN in the hopes that someone will find it useful. The OpenGL FAQ has gotten a lot more attention from me than the shader one at this point, so it's a bit more fleshed out. Oh, and just how important is this TDN warning: "WARNING: This page is 34 kilobytes long; some browsers may have problems editing pages approaching or longer than 32kb. Please consider breaking the page into smaller section" ?

Anyhow, in terms of my Torque work (people seem to like it...), I have been toying with putting together a TGE based sandbox to allow people to mess around with OpenGL shaders. I wouldn't release the C++ source code (there are bits that I did as contract work, and bits that I'd rather keep private at this point), but all of the various shaders would be included. It amounts to about 500k in shaders at the moment, covering everything from basic fixed function emulation, to parallax mapping, to image manipulation and filtering. I'd obviously need to write real documentation for everything if I did this, but if there is enough interest in a GLSL sandbox, I'll put some effort into it. And if you read the OpenGL FAQ you might just find some handy information on implementing GLSL into Torque yourself.

Per usual, a .plan simply isn't a .plan without pictures. Below are some pictures of what I've been working on for the past week. What can I say? I got back, I was bored, and I had a copy of the OpenGL Orange Book.

Highly exaggerated example of hemisphere lighting:

Somewhat more reasonable example of hemisphere lighting:

What follows are all examples of per vertex spherical harmonic lighting (I like spherical harmonic lighting):

In this image, the interior uses the normal from its normal map to do the spherical harmonic lighting calculations on a per pixel basis:

Before anyone asks, I actually don't have any pictures from my vacation. I didn't bother to take a camera.

Has it really been two months?

Alex Scarborough — 2006-07-27T04:58:35+00:00

Wow, has it really been two months since I last posted a .plan? It sure doesn't feel like it. I've been extraordinarily busy as of late. On a completely unrelated note, have you seen Monster Island, Illumina, or Ninjas vs. Pirates? Those games are really looking awesome.

In other news, I've been doing a lot of shader writing lately, and I do mean a lot. I'm currently up to 61 shaders written in four different languages. It's been fun learning all of these different shading languages and working with and around their little quirks. I've actually developed a bit of a liking for writing ASM shaders. I guess it's just knowing exactly what the shader does and exactly how it is going to run, without making any guesses about how the compiler is going to interpret a line of code.

What's been most exciting for me is the level of scalability I've been able to achieve by spending the time to write vendor specific shaders. I coaxed a 50% FPS boost out of my shader water by rewriting the GLSL shader to detect if it is running on an nVidia card and if it is, use the half datatype and Cg standard library whenever possible. I also got parallax mapping working on Radeon 8500/GeForce 3 class hardware, which was rather exciting. It doesn't look quite as nice as it does on SM 2.0 hardware, due to internal precision issues (freaking 9-bit signed format), but it is parallax mapping, and it does look better than normal mapping.

I've also done a few other spiffy things which I intend to roll into TSE at some point. Thankfully, I don't have to learn another language to do it, as Cg and HLSL are pretty much identical. I could probably just drop in the Cg shaders and use them in TSE without any modifications.

Anyhow, a few notes.

1) TLK users with Intel macs: go here and check out the app and code please. I really would like to make it a resource, but I want to be sure that it actually works before I release it.

2) TGB Pro users: I recently submitted a resource that optimizes the TGB particle renderer. A friend of mine, Rob Sandbach, who is making chainWorks, said that he saw an immediate and noticeable FPS boost using it, so hopefully it will help out your project a bit too.

3) All: I created an OpenGL Q&A/FAQ thread. Go there and ask some questions! It's open to pretty much any OpenGL question, so if there's anything you've ever been curious about, now is the time.

And finally, a quick plea for help. Has anyone managed to get Cg working on Intel macs? 1.5 beta 2 is supposed to be universal, but on a friend's MacBook Pro it runs under rosetta.

Hmm... I guess it woud be cruel and unusual to post a .plan about graphics and not have any screenshots. Well, about a month ago, I messed around with some stylized rendering via post-processing to blow off some steam. Here are the results.

Larger version

Larger version

Larger version

Larger version

Larger version

Larger version