Blog for Trent "mittens" Polack at GarageGames.com

Tuesday Sep 6 4:23

Trent "mittens" Polack — 2005-09-06T04:23:39+00:00

Summary of my work on HDR rendering in the Torque Shader Engine.

The lack of a comprehensive update in a few days may make a few of you disoriented in your travels, speech, and general being, but I promise, I had good cause. Kind of. Well, not really. But I bring pictures to compensate. Them pixels arrayed in an organized fashion represent the little room that I call home in a very slightly off-campus house with ten other people (all but two of whom I know on a friendly or friendly-ish basis). It's a pretty nice place, actually, and words cannot describe the level of peace that I've reached with just the knowledge that I no longer live in the dorms.

Lately I've been working a lot more with the Torque Shader Engine and, specifically, I've been working on a bloom effect (yay pixel shaders). At first I took the basic "fake bloom" route that every single game within the last two years has both used and abused in a very, very common way. Some games even go so far (or, rather, not nearly far enough) as to just apply a general brightening filter to the entire screen buffer and the end result is primarily an effect that really does nothing more than wash or smudge the clarity of the scene. As of right now the only game I'm aware of that does real HDR (high-dynamic range) is Far Cry, which implemented the HDR effects in a post-release patch (1.3, if my memory serves me). The actual shaders that are primarily responsible for the effect in Far Cry appear to be straight from the DirectX 9.0 SDK "HDRLighting" sample, though the HardOCP article linked would have me believe that it is based entirely on methods presented by OpenEXR (which the SDK gives no reference to). So, either way, the effect exists in Far Cry. And it's pretty.

Before I start showing all the pretty screenshots, let me show a kind of "before" picture set (in the GUI one, focus on the building, not the GUI) that shows what the game looked during a prepubescent period.

[image]http://polycat.net/gallery/albums/earlytorquetests/roughgui_72505.thumb.j... [image]http://polycat.net/gallery/albums/earlytorquetests/gun_testing.thumb.jpg[...

With that said, I was led down a similar path in my work lately. First I decided upon a "fake bloom" method that used similar techniques as mentioned above, but with fairly "hacked" calculations. This produced some of the following screenshots:

[image]http://polycat.net/gallery/albums/earlytorquetests/hackbloom.thumb.jpg[/i... [image]http://polycat.net/gallery/albums/earlytorquetests/hackbloom2.thumb.jpg[/...

I was very unhappy with the overall "look" of the final scene after I had worked with the fake bloom effect. The very, very overly done bloom in the above screenshots is partially to blame on the actual blurring shader that I was using, but the hacked bloom calculations were also just missing something that I couldn't put my finger on. So, after another few hours of work, I was able to figure out how to get the HDR rendering working without too much trouble, and produced these screenshots (with a slightly different blurring algorithm for the shader employed).

[image]http://polycat.net/gallery/albums/earlytorquetests/hdrbloom_blurtype1_1.t... [image]http://polycat.net/gallery/albums/earlytorquetests/hdrbloom_blurtype1_2.t...

The overall look in the above screenshots was what I was going for, as the final produced images just felt a lot more vibrant than anything I had produced before, but this time I would say that the final effect was actually too subtle. I wanted the final effect to be subtle in screenshots (which can never really show this kind of effect very well), but not so subtle as to be really easy to overlook. I then took another solid five-six hours just trying to perfect the blur shaders, and eventually I ended up with an effect that I thought was pretty damn good. The following screenshots are pretty close to the current version I'm working with, though I ended up reducing the area of the blur (which is a separable gaussian blur) by a few pixels since I felt these screenshots were just a bit too overdone.

[image]http://polycat.net/gallery/albums/earlytorquetests/hdrbloom_blurtype2_1.t... [image]http://polycat.net/gallery/albums/earlytorquetests/hdrbloom_blurtype2_2.t...

As of now, I have plans to make the system far more configurable than it currently is, as well as making the HDR bloom adaptive based on the player's exposure to varying environments with their own level of average brightness in a given scene. I'll work on this a bit more, but for now I have to work on a DDS loader.

Monday Aug 8 8:22

Trent "mittens" Polack — 2005-08-08T08:22:20+00:00

The GUI is finally done (for the most part). At last I can move on to something a bit more... Non-GUI.

I've spent the last two weeks of my time with Torque doing nothing except tweaking the GUI that I plan to use for my upcoming projects, and tonight I can finally say that I'm done with the damn thing. I created every image completely from scratch, which I'm still proud of, then tweaked and re-drew every texture about three or four times, then tweaked and re-wrote some of the GUI scripts and the inner GUI core code. And it's done.

I would've had this done far sooner, but this weekend has been the first time in the last two-three weeks that I've really devoted to actually coding (I've occasionally opened up VS.NET and tooled around a bit with miscellaneous stuff), and it's been a lot of fun. I've cooked up some fantastic ideas for the game demo I'll be working on to show off all of the things that I plan on adding and changing within Torque, and although it won't be done anytime soon, I should be able to get some fairly impressive screenies up within the next month. No more details for the time being, but it should become apparent fairly soon (in a few weeks, as I have finals coming up) what I'll be aiming for.

And now some screenshots of the GUI. I still have a couple things that I want to change, namely the fact that the chat box's messages are always being displayed, so I want to throw in a bit of code to make the messages fade away over time, but other than that I'd say that the GUI is pretty damn-near finished, in all of it's very Steam-esque glory. I would like to stress that, although visually simmilar, absolutely nothing was copied from the Steam GUI. Not a single pixel, RGB value, or anything else. I did this entirely from my memory of what I liked and disliked about the GUI. Also, the grey color is mostly a placeholder. I'll probably colorize based on the mood of whatever I release. Who knows though. Or maybe I'll skin it with a ridiculously bright, colorful, and overly-large cat-based texture set. WHO KNOWS.

Anyway, here are some nice little screenies. Over the next week, I really want to get a weapon in-game and working, so that's probably what the next update will entail.

[image]http://polycat.net/gallery/albums/guifinal/gui_chatwithinput.thumb.jpg[/i...

Saturday Jul 30 0:02

Trent "mittens" Polack — 2005-07-30T00:02:36+00:00

Editorial: Developer Gas Powered Games has spent 3-4 years developing Dungeon Siege 2, and throughout all that time, very little effort was spent upgrading the graphics engine, and instead GPG (headed by legendary Chris Taylor) focused all their time improving gameplay - something that they should be greatly rewarded for.

2005 is a great year for gamers as a whole, with the release of the highly-touted Xbox 360 headlining the news (and, consequently, the temporally inferior PS3) for the brutes of the gaming crowd and new graphics card technology and big-name game titles for the intellectually elite [Ha.] PC gamers. Far and wide the most important event of 2005 is the release of Gas Powered Games' Dungeon Siege 2, the sequel to the relatively under-appreciated original game of the same name, one of my top titles of all time. It is only through my striking ability of clarity, along with my tendency to avoid any type of "fanboyism" that I can say that the under-appreciation of the original game was quite well-deserved. The game was able to present the user with an absolutely gorgeously organized array of colored pixels for its time but, alas, the game was more of a visual spectacle than a well-designed gameplay-centric phenomenon.

Yeah, it was basically a mildly interactive screensaver. And I say this with love.

Not content to be just another roof housing cheap imitation game developers, Gas Powered Games instantly set to work on making the sequel to their beloved Dungeon Siege franchise (while plotting the mind-blowingly sexy Supreme Commander, of course). I've personally been following the development of Dungeon Siege 2 since the moment it was announced, taking in each newly released screenshot and interview with a bit of my inner-fanboy emerging with every new screenshot pixel or interview letter.

However many years later, and Gas Powered Games makes the announcement I've been waiting for: it went gold. And take a look at those screenshots (Or the ones from my DS2 gallery)... Wait, what has Gas Powered Games doing doing all these years? What the hell? This game isn't new. What the hell. They didn't change anything. What the hell!

What you've been absorbing is the best example of a game being released where the development company has all the resources of every other game development company around and uses them to... make a better game? That's right. Almost three-four years in development under the guiding powers of the infamous Chris Taylor (of Total Annihilation fame), Gas Powered Games now prepares to release the sequel to their Dungeon Siege franchise for the video gaming consumption of rabid gamers everywhere. And in these three years in development, the graphics engine was hardly touched at all. Sure the textures are crisper and some shader effects were thrown in, but the graphics engine for Dungeon Siege 2 is essentially the same one we all saw in the first game. This is one of the best instances I've ever seen where a developer has actually decided to divert their focus from the much criticized "graphics over gameplay" path that a lot of developers take, and instead focus almost all of their time trying to make their game world seem more alive through details while simultaneously spending time to make the actual gameplay perfect. Three years in development, and we get what Chris Taylor says "is the closest to perfection I've ever come on any game I've done!" Bold words from a game designer said to revolutionize the real-time strategy genre with Total Annihilation.

And here's where the point comes in: gamers are already up-in-arms about Dungeon Siege 2. And not about the developer's immense focus on detail and gameplay, but rather about the developer's lack of time spent upgrading the graphics engine. Comments I've seen from average gamers across a number of sites chastise Gas Powered Games (though, not directly of course, that would require backbone and thought) for releasing a game in 2005 that looks "so bad," yet go on to complain about the original game being a "screensaver." The nerve of Gas Powered Games! What were they thinking when they were following the ideal that so many critical editorials and articles express their fears that games are becoming so technologically advanced that the gameplay begins to suffer. What on Earth were they thinking in actually spending time trying to perfect their new game's gameplay instead of focusing on visuals?

And there's the beauty of this industry folks: graphics make the game. Despite whatever article on any game development, game review, or game-related website or periodical may say, at the end of the day, a game simply cannot be released these days unless it's using a shader model higher than any graphics card can support, unless it is taking advantage of HDR lighting, lens flares, per-pixel lighting, physically accurate shadows, mega-detailed textures, and super-shiny rough wooden surfaces (because that's totally realistic, dude). Nobody wants to play a visually par game anymore; hell, take a look at Battlefield 2. A ridiculously popular game, yet, it's released months before it should have been so buyers can function as beta testers, and with requirements that alienate anybody without the latest and greatest graphics cards. The video game industry is an industry well-versed in gamer hypocrisy, and the developers acknowledge it when they release games like Battlefield 2, Half-Life 2 (it's not a good game, I'm sorry), and DOOM 3.

If gamers really do mean it when they say that they would rather have a visually sub-par game with excellent gameplay, then let's all put our money where our mouth is. Buy games like Dungeon Siege 2. Reward the developers for releasing a great game and focusing on what really matters to gamers everywhere: the gameplay. I will be buying Dungeon Siege 2 as soon as I possibly can, and not only to support the developer's focus on gameplay, but because I think their laser-like focus and precision during the development of Dungeon Siege 2 has resulted in one of the best action/RPGs in gaming history being released on August 16th, 2005.

Wednesday Jul 20 13:38

Trent "mittens" Polack — 2005-07-20T13:38:23+00:00

Some quick screenshots before I head off to class.

Here are some quick screenshots from my experiments over the last couple days; I'd post more, but I'm off to class, and figured an update was in the cards. Also, the colors are fairly washed out since my screenshot program has a habit of highly compressing JPGs, this will change for future shots.

[image]http://polycat.net/gallery/albums/earlytorquetests/orc_water_terrain.size...

[image]http://polycat.net/gallery/albums/earlytorquetests/orc_in_demobase.sized....

I'll try to get some better shots of the water tonight too, as I'm putting together a small map (using some of the engine's demo resources, since my "art" is an abomination).

Tuesday Jul 19 5:59

Trent "mittens" Polack — 2005-07-19T05:59:58+00:00

A very rough, very basic flow of thoughts about my new game, currently "codenamed" Eulogy as they occurred to me about a week after I had first thought of the idea. The game will be based on the technology in the Torque Shader Engine, and is currently being worked on by me (and me alone).

What follows is a very rough, very basic flow of thoughts about my new game, currently "codenamed" Eulogy as they occurred to me about a week after I had first thought of the idea. The game will be based on the technology in the Torque Shader Engine, and is currently being worked on by me (and me alone).

Basic Game Description
Eulogy (not the game's name; simply the song I was listening to when I thought of the idea) is designed with three things in mind: action, mood, and customization. My basic goal for the project is to have the game play like a classic first-person shooter, where aim is king, not some background roll of a die in the background determining when a player hits and when a player misses his opponent. There will not be any of the manipulation of physics like in Quake or Unreal; no double-jumps, no strafe jumping, etc., this game's mood is dark, and very deliberate, I want the physics of the main player to have its roots in realismthough an arcade-realism for movement. The player will move fairly fast, but have a stamina bar to control the amount a player can "run," which will greatly speed up movement.

While I want the controls to be fluid, the aiming to be fairly tight (though not "this is your cursor, you hit exactly where it's pointing"), and the movement to be fairly speedy, this does not mean I want the game itself to be a mindless bullet-fest. I want combat to be hectic, but still cerebral and thoughtfully-paced, so the player won't be able to aim 100% accurately while running and jumping through a crowd of enemies (which there will be a number of; there will also be a number of ways for the player to thin and demolish this crowd); the aiming will have some kind of inaccuracy system, a bit of statistical inaccuracy thrown in depending on the level of the character as well as the player's proficiency with whatever weapon type he/she is using at the time, but this inaccuracy amount will be minimal, I don't want to the game to be number-based in this respect (the level/proficiency will almost entirely impact damage, as well as what weapons and "techniques" the player can use; more on this later), but I will have level make a very slight impact. The accuracy will also be based on player movement/stability, but mostly on the player's ability to control whatever recoil the gun he is using has.

The game is primarily being billed as an Action/RPG. The pacing of the game, as I have described, will be quick and hectic as well as cerebral and thoughtful. I want the player to feel on edge at all times, but be able to find a "safe spot" at some points in which he can tool around with his current equipment layout (more on this later), as well as tweaking his weapons, and organizing his inventory. The character itself will be level-based, with a few basic stats influencing weapon experience, player speed, strength, "toughness," technical prowess, medicinal knowledge, and whatever else (I will try to keep the number of basic stats limited to about five or six categories, maybe less). Each of these will have a number of skills/feats/talents associated with themweapon experience, for instance, would have subcategories based on types of weapons, whereas medicinal knowledge would have subcategories related to types of "healing" available (painkillers, natural antidotes, etc.).

The weapons themselves will be of a number of designs (the total number of which depends, really, on the number of talents artists I can get my hands on) each with their own unique usage. As the player advances through the game and increases his level, the weapons will start to have more "extra stats, do more damage, as well as the designs themselves starting to "look cooler" through various "mods" being attached to the basic design. I'm going to attempt to make sure that every model in the game has room for in-game component modification. For instance one of the basic rifles in the beginning of the game may still appear in the game later in time, though it will have so many modifications (some strictly for aesthetic appeal, other having actual practical purposes) that it will be an almost completely different weapon. In terms of design, all the weapons in the game will be based on a kind of Diablo/Diablo 2-ish naming scheme; the basic form for item naming will be: <quality level> <elemental type> <basic weapon type> of <type of stat modifiers included> - <# of open mod slots> Mod Slots.

There will be no magic, but perhaps there will be some kind of "energy" system which controls special attacks (just to increase the amount of depth in the combat system).

The mood of the game is dark (not necessarily in lighting, but in atmosphere), hyper-violent, and lonely. The player, for the most part, will be companionless throughout the entire game. The areas, which for the prototype will solely consist of the Settlement, will require a relatively flexible and advanced lighting system which I plan to implement in the game's engine before I do much work on the features of the game itself, which I hope will give me time to find people to work on some content for the game, which will give me a decent library of art to work with when the technical aspects of the engine are complete (overall development schedule for the prototype game will follow these gameplay details).

Settlement (and Basic Story) Details
The Settlement that the player starts off in is basically the "hub" for the early beginning of the game. It is a "city," the name of which taken from the large Settlements formed in the early 22nd century before the Heavenly Reckoning occurred in the 25th century, killing off more than 90% of the world's population in the three weeks following the aftermath of the Reckoning. The humans that did survive the event moved underground, and slowly developed the very necessities of their new civilization with all of the technology and knowledge that the assorted humans had managed to bring down with them. In the player's settlement (the game takes place roughly one-hundred years after the underground settlement, referred to as "The Settlement," had had its first "Unification Feast" after the necessary buildings had been constructed for the new population to begin life anew in), there are roughly 1,500 people living, every citizen being from a range of backgrounds which had originally founded The Settlement over a century ago.

The Settlement itself is anything but a content sub-civilization, but the people all understand the situation they are in (but are certainly willing to do anything to stay alive, no matter what the costs). The buildings are all, essentially, thrown together with whatever the people could find, and have a very rough, very primitive look to most of them. There are a number of buildings, however, which are far more structurally advanced, which had been constructed after the initial necessary dwellings from the supplies that people had brought down with them initially (and from "salvaging runs" into the city they fled from originally).

The player's character's story is dynamic, depending on the choices that the player chooses during player creation. Whether the player starts out as "somebody" (a marine, doctor, etc.) or whether the player has some basic stats and builds up his rank from the actions he performs in the early game is something I have anything but decided at this point.

That's it for now. If you're an artist (either concept, texture, 3D modeler, or level designer), I really, really need your help. Please leave a comment or e-mail me at trentp@gmail.com.

Saturday Jul 16 5:43

Trent "mittens" Polack — 2005-07-16T05:43:08+00:00

Bug hunting in the transfer of starter.fps from Torque Game Engine to the Torque Shader Engine.

I didn't work as much as I had hoped to on porting the "starter.fps" demo from the original Torque Engine to the shader engine. Primarily because of sleep, calc 3 homework, the Auto Assault beta, and the premier of season 2 of Battlestar Galactica... Though I did get a few hours of work in, and here's what I've accomplished (then what I've figured out).

First I was able to get the orc textures to display; the problem was simply that one of the game's scripting files relied on a folder that wasn't there. Here's what the orc looked like after I changed this:

[image]http://polycat.net/gallery/albums/earlytorquetests/orcunshaded.sized.jpg[...

I had to re-enable shader materials to get the orc's material shaders to work correctly, which I disabled for reasons that I'll cover in a moment, but it was certainly worth it when I saw them in action:

[image]http://polycat.net/gallery/albums/earlytorquetests/orcshaded.sized.jpg[/i...

Something about the model still strikes me as being a bit "off," but I'll tweak that a lot more when I get the rest of the demo working correctly. After I had accomplished this "feat" (remember: any victory, despite size, is a big victory when programming), I went back to focusing on fixing the "see-through" interior buildings. The only objects with this problem, which is basically that the buildings have taken a liking to using the skybox textures, are DIF interior files; which are, basically, a Torque equivalent to Quake MAP files... These are the files that Torque uses for its interior maps/components which are managed through a BSP scene management tree (just like the Quake games). I posted a picture of this yesterday, but here's a link to it for a quick recap. Anyway, I disabled the following lines in materials.cs (the demoMaterial function can be found below the commented-out lines):

demoMaterial("MtlPilrFront","interiors");
demoMaterial("MtlPilrBottom","interiors");
demoMaterial("Mtl","interiors");
demoMaterial("F","interiors");
demoMaterial("Wall_filler1_01","interiors");
demoMaterial("Floor_tile01","interiors");
demoMaterial("FlrFiller3_01","interiors");
demoMaterial("WalMtlbase1_01","interiors");
demoMaterial("FlrFiller3_01","interiors");
demoMaterial("Filler_tile1_01","interiors");
demoMaterial("oak1","interiors");
demoMaterial("oak2","interiors");
demoMaterial("oak2_end","interiors");
demoMaterial("thatch","interiors");
demoMaterial("Floor_slate01","interiors");
demoMaterial("WalNoGroove","interiors");
demoMaterial("Wall_block01","interiors");
demoMaterial("stonewall","interiors");
demoMaterial("Wall_panel01","interiors");
demoMaterial("MtlPilrTop","interiors");
demoMaterial("cottage_detail","interiors/hovels");

function demoMaterial(%name,%dir)
{
   %com = "datablock Material(Demo_"@%name@") {"@
      "baseTex[0] = \"~/data/"@%dir@"/"@%name@"\";"@
      "pixelSpecular[0] = false;"@
      "specular[0] = \"1.0 1.0 1.0 0.1\";"@
      "specularPower[0] = 32.0;"@
   "};";
   echo(%com);
   eval(%com);
   addMaterialMapping(%name, "material: Demo_"@%name);
}

Once I disabled these lines, I got the interior/DIF objects to look like this:

[image]http://polycat.net/gallery/albums/earlytorquetests/tseinteriorbug.sized.j...

This image shows that the actual DIF skin is now in-game, but it is fighting with the previous "see-through" skin as before. Also, when I disable the lines above, the shaders on the orc cease to show up, which leads me to believe that the problem with the DIFs is related to materials. In short, the focus on my bug-hunt for this damn thing is getting narrowed down, and I'd expect that I'll figure out what's going on tomorrow. Then I can port over my GUI changes to this, and play around with the shaders.

Also, I'm looking for some help with some art assets for my game (very dark, very moody, kind of a mix of fallout/diablo/quake kind of thing) if anyone is feeling bored. Specifically, I need a bunch of buildings/textures for the prototype level I'm planning for the prototype work I'll be doing on the game. So if you're interested, just comment below. Off to bed.

Friday Jul 15 5:59

Trent "mittens" Polack — 2005-07-15T05:59:28+00:00

I've been spending the last few days with the the Torque Game Engine, and I must say, this is some of the most fun I've had programming in a very long time. Here's a quick run-through of the things I've been playing with over the last few days...

I've been spending the last few days with the the Torque Game Engine, and I must say, this is some of the most fun I've had programming in a very long time. Here's a quick run-through of the things I've been playing with over the last few days. Of note, though, is that I haven't stayed up this late in a while, so I may not be quite as witty (read: less than zero), verbose (no treatise on immersion :(), nor creative as I may [or may not] usually be.

The first thing I did with Torque was, naturally, play around with its terrain editor and particle editor. After about an hour of playing around with the editor, which has a built-in texture blender that can blend up to six 256x256 resolution textures (this 256x256 is a limit which made me angry) and having a lot of fun trying to figure out the particle editor without having so much as a clue as to what the various parameters did, I came up with this image:

[image]http://polycat.net/gallery/albums/earlytorquetests/particle1.sized.jpg[/i...

The particle editor in Torque was surprisingly capable and powerful, though maybe not quite as powerful as the Max Payne 1/2 particle editors, nor as some of the particle engines I've cooked up over the years, but this will certainly do. And it will certainly do better as I update it. One really nice thing is that the editor already has support for a relatively large number of animated textures for the particle sprites (if I remember what I read correctly, it can support up to 5^6 animated textures for particles).

After playing with the particles and terrain, I set up an empty project in VS.NET 2k3 for all the various script files for the project I was working on at the time. It's a fairly large image (height-wise), so I don't want to post it here, but it's there if you want to take a peek at it.

Throughout yesterday and today, I was working with the GUI system to create a slightly more aesthetically-pleasing look for the game's option screen, and though I haven't started work on fine-tuning the rest of the GUIs yet, they do operate off certain parameters/images that I altered while playing with the look of the options window. I still have yet to finish my tweaking of this window, since I had gotten sidetracked, but eventually I'll be adding transparency to every GUI window as well. Here are a couple shots of the options window (left being the original look, middle being a rough draft, the third/final image being the near-current state of the options GUI):

[image]http://polycat.net/gallery/albums/earlytorquetests/originalgui.jpg[/image... [image]http://polycat.net/gallery/albums/earlytorquetests/rough_newgui1.jpg[/ima... [image]http://polycat.net/gallery/albums/earlytorquetests/rough_newgui2.jpg[/ima...

What I got sidetracked with was the build of the Torque Shader Engine (I am now officially near-broke with just enough money to cover the first month's rent of my house for school this fall) that I decided to buy, going against my previous claim that I wanted to upgrade the engine with an entirely unique shader system of my very own (instead I'll just be working on a dynamic lighting and shadow system of my own). This decision came from the fact that I got an actual game idea in my head that I plan to flesh out and create a prototype level for all in the next six months. The screenshot below is the first build of the engine where I finally (only after about an hour of work) got the FPS demo from the first screen in this post working with the TSE:

[image]http://polycat.net/gallery/albums/earlytorquetests/tse_firstbuild.sized.j...

Yeah, it's a bit screwed-up. I may have to fix that.

If I didn't have class tomorrow, I would almost certainly be able to stay up all night just playing with the engine. I'm having an absolute blast with this. Another update tomorrow night.