Blog

Chade the Chapes in ChexNA

Tuesday November 18, 2008

Shaders are the CG bomb! Or at least that's what would be said about them in the 1980s if the people in the 1980s had shaders. Although debugging HLSL is about as much fun as Russian roulette, the effects that can be achieved are really great. The screen shots page has been updated to show my latest results.

Implementation of the game part of the game is basically at square one. Up next I'm going to be making a small portion of the interface and trying to enable the game to actually do some station building. The idea is pretty simple, the main challenge will be getting the user interaction features more stable. Right now hover states behave rather unpredictably.

I'm Tired

Saturday November 9, 2008

Well the end of the semester is fast approaching and I'm no where near as finished as I would like to be. The good news however is that I've just finished up work on a kick a$$ design and implementation for the "Command Module" part of the station. It is really looking good and represents a lot of work and new knowledge of C# and XNA. It is about 85% done right now, but I should probably call it quits and move on to something else. The other modules will be simplified "rough" models and no textures for now. Now that I know I can make them look good I won't worry so much about actually doing sp.

Another achievement was I finally figured out how to distort my space dome texture so that it does not distort when mapped onto a sphere. Or at least I think I figured it out. It still looks a little weird at the poles but I'm pretty sure my distortion function is accurate. Please note that the screen shots I have up do not show these changes yet though.

I've made several updates to the site worth checking out:

Now if you'll excuse me it is 7 a.m. and I am tired.

I put the "In" in Interface

Saturday October 22, 2008

Hey oh! Interface ahoy (and it works pretty well too!) Actually it is just the framework at this point, but I have delveoped a lot of new classes including:

  • Display Container (which acts as a transformation node)
  • Sprite2d
  • SpriteSequence
  • SimpleButton
  • TextField
  • InputTextField
  • Number Roller
  • TilePattern
  • and soon a scrollable area...

There are also some abstract classes that enable common interface capabilities such as mouse over, mouse out click and rendering for their sub-classes. My class structure is fairly sophisticated but not very consistent. For example, all interface elements inherit from the InterfaceItem class which has properties like size, name, parent container, and transformation. In some instances when I'm making a component that is composed of several sub components (such as a text input field). I make the new class extend one of those subcomponent classes, in other cases I have the new component just extend the interface item class and then add all the subcomponents as properties of the new class. It is a little vague to me what would be more approriate. Anyway, you're probablly pretty bored of this stuff by now. Just trust me when I say, that it is at least a fairly robust implementation.

One of the demands of creating the interface framework was the ability to mask out areas of an element. For example scrollable areas and input text fields. This prompted me to start learning about pixel shaders for 2D rendering. It was a little more complicated than I anticipated but the required steps made sense once I finished. The process requires that you first render the basic content (sprites and text) to a Texture2D object that is the size of the whole viewport. Then you take the resulting Texture2D object and pass that into a custom pixel shader. My masking shader works on any interface elemnt by looking at each pixel coordinate and backwards transforming it by the objects transformation matrix to see if it lies inside the masking rectangle. It works pretty well although it doesn't do any anti-aliasing. I could also modify it to work with a masking texture rather than limiting it to a simple rectangle.

I also wrote a drop shadow / glow effect shader that of course works well for text objects. I was a little surprised that I had to compile the drop shadow shader using pixel shader 3.0. The shader is (to me) not that complex, but apparently pixel shader 2.0 and lower are pretty limited on the number of memory registers. The fact that a neighborhood blurring operation is involved requires at least one for loop and works better with a nested loop. I'm thinking that the nested loops is what it has a hard time handling.

Houston, we have a game concept!

Saturday October 4, 2008

I've finally made some progress on the game concept. Actually, I've made a lot of progress on the concept. The ideas have been coalescing in my mind for several weeks, even months, now and finally I was able to vomit them out onto a website. Well not vomitted so much as placed delicately onto a website. I used an open-source program called Dia to create a visual map of the game. I think it was a good plan because it shows the interrelationships and interdependencies of the elements of the game fairly clearly. There are still plenty of unironed details to the game, but for the most part I think what is left out is self explanatory.

Next week I'll get back to work on programming the framework. My first goal will be to finish up a 2D interface component to the framework. I've got a decent start on it but I need to introduce some GUI elements such as buttons, tabs and most likely scroll bars. I'm modeling the 2D framework off of what I know which is Flash and Actionscript. I think this will make switching between the two languages a much smoother transition.

I've found that I am incredibly frustrated by other inferior IDEs and programming languages after working with C# and Game Studio. It seems to me that just the autosuggest capabilities of the Microsoft IDE cut my programming time down by about 33%. I really hope that all systems will evolve to this caliber that I have come to appreciate and expect.

Why am I writing a blog at 4:30 a.m.?

Tuesday September 28, 2008

Well it was worth it to stay up this late. This week I've put together quite a few new elements. Included among this weeks developments are: a 2D and 3D (billboarded) sprite class, an animation controller class, an abstract light class and its derived directional light class, and a rendered item class. The rendered item class handles model shaders and shader properties. Eventually I'll improve it so that it also holds a list of active lights that are illuminating the model. Just a few minutes ago I finally solved a problem I was having with billboarded sprites. I was having difficulty where the billboards would not always be facing the camera. I finally realized that I was not doing the transformations correctly. I don't think my solution is ideal but it should work for now, and by finding a solution I know that I at least understand the problem. I'll post the code on my code snippets page so that people can see the funky algorithm I'm using.

In addition to all this I've been looking at some example XNA shaders. I think I get the idea of it pretty well even though I haven't actually tried writing one from scratch yet. Check out the screen shots to see what I've been doing visually with the game so far. It is looking a lot beter now that I have pixel shader light calculations and some flare.

Once again I've gotten too caught up in the programming to do much about the actual game design or planning. I have however come to a decision about what the game is representing. I've decided to set the game on Earth (or at least close to it) in the near future as the construction of a second International Space Station is beggining construction. Perhaps it should be called Beta Station, Station B or ISS2 or something...

Seeing as it is set in the near future I can introduce some new technology that doesn't exist at present but might someday soon. Specifically I'm thinking about methods of getting supplies and people too and from the station using something other than a space craft. On the other hand giving the player more limited resources introduces a more interesting level of challenge.

Next week my goal is to start designing the interface. By doing it so it forces me to make some decisions about what the capabilites, goals and experiences will be a part of the game.

OMGWTFBBQ, It's A Blog

Tuesday September 23, 2008

Howdy! So yes I've decided to make a game. Why you ask? Why not I say! My progress is coming along very steadily right now despite the desparate hours I've poured into the code. I'm a little worried that I'm working too close to the project right now. What I mean is, I'm coding an entire extended framework without having written down an of the big picture. I have no doubt that the work I have so far will prove very useful, however, I'm concerned that I'll make an oversite in the system that will debilitate my game design later on. Fortunatley, this website is an ideal venue to start doing that. My plan is to fill in the Concept and Design section of this website with my plan of action pretty soon.

In any case, I've already learned a ton about C# and XNA which is really my main goal for the class. It almost seems impossible that I knew nothing about either topic at the beginning of the semester. Whether or not I'll make the deadline at the end of the year is tough to say. I made a conscious decision at the start not to take any short cuts, in order to learn the tools and how to manipulate them at the most primitive levels. So far that has meant progress is much slower than what I would like. All in all, I think it is worth the effort though.

I ran into some difficult - albeit interesting - problems this week. The main one being getting all my geometry all to render in the scene at real scale. I didn't actually succeed. The problem (which I was expecting to encouter) comes from the fact that computers can't make extremley accurate math calculations using floating point decimal representations. When the objects in the scene are transformed into the camera's projective space the matrix flatens all the content onto the image plane. The graphics card knows when one thing is front of another because of the information stored in the depth buffer, which allows the 3D surfaces to occlude each other when appropriate.

The problem is that the depth buffer isn't really able to differentiate between something that is really far away and something that is really, REALLY far away. As a result, objects like the moon would flicker and flash in and out of existence in front of the background sphere. My solution was pretty simple. I turned the depth buffer off when I'm render objects that are far away. First, I draw the background plate, then the moon and then the earth. Then I draw the objects that are closer to the camera, like the space station itself.