Omg. I have become a total slacker the last couple of days, no updates here :( I didn't had much time over christmas to code, but I read some more of my Rapid Development book (abi/blog/PermaLink.aspx?guid=42bdcd49-2490-4f60-af1c-3ff54c1be1d1">see last post) and it is still interessting and insightful. Yesterday I still was in vacation land and had to force myself to get back to coding ^^

I also reconsidered some choices I made and came to the conclusion that this project was originally started to make a quick little game with DirectX9 in c# and also to write a new base engine for upcoming DirectX9 projects. I did obviously spend too much time researching shaders (DirectX9 fx high shader language) and saw last week there is no way to implement that nicely in 2 weeks (when the game is running with all the other parts finished I will reconsider implementing shaders). For the engine part of the deal this is still great work and I have a lot of base classes for any shader effect development ready, but for the "quick little game" Lost Squadron part it is not looking so good. It is a conflict of interests because finishing up something quickly does not work hand in hand with researching and implementing new techniques. For this project I think it is better to focus on developing a solid base engine, next project will be planed much straighter.

Yesterday I collected a lot of effect graphics and sounds and made some new ones. I got now a nice collection of effects with graphics and some funny sounds for the effect engine and made a couple of effect types (parameters, testing, etc.), but when adding more and more effects it became very obvious that this would be a great think for scripts. Instead of hating myself later for not using scripts right away, I just went crazy and implemented the whole effect system in LUA scripts and can add new effects there without changing any code of the engine. I did the base code for that a month ago (check out LUA.NET for doing that in c#) and have read the great book Programming in Lua by Roberto Ierusalimschy.

LUA links in case you are interessted:

• The Programming Language LUA The online version of the book by Roberto I. is also available there for free.
• LUA.NET for implementing Lua in .NET Sadly the LUA IL project isn't public yet, but LUA lib is ok too.
• LUnit Unit Testing with LUA.
• QDE THE IDE for LUA development!
• LuaLite Syntax highlighting support for Visual Studio, but does only work for VS2003.
• Lua-users.org Everything else you need for your LUA development

The effect engine needs still some testing and I haven't worked with lunit yet (will do that tomorrow), everything should be up and running tomorrow and I will post a new screenshot with some nice effects then. The rest of the base classes except wayfinding and enemy ai is also pretty much complete, so I hope I can finish up a small demo till New Years Eve (driving around, shooting at some stupid enemies).

Sorry for no screenshot today and sorry for the long pause. Fabian is ill (my intern helping me out a bit with Lost Squadron), hope you get better till next week :) Tomorrow the LUA effect engine should work and I will post a screenshot of the actual gameplay finally (I want to kill some stuff).

Yes! Finally I got back to the game code after all this Editor and Shader coding and run into some problems when rendering some models with transparency. First of all the models had to be rendered from back to front, but even then the models with multiple alpha layers were completly messed up. So I had to split up the alpha layers to multiple meshes and tryed to render them back to front, but DirectX tries to render per materials and not per meshes, so that didn't work easily. I had another idea to just test the alpha values for 50% alpha and then skip writing to the frame buffer and that didn't work either (framebuffer is full of false pixels anyway). Instead of banging my head into the wall I just steped back and thought about needing this feature at all and no, there is no need for that in this game: I can just delete or don't use anything with multiple alpha layers. For example the palm had 3 layers of palm leaves, but I killed 2 of them and no everything is working perfectly (I still have to sort objects and to render first solid, then alpha materials, but thats pretty fast). I'm happy I got this solved The Editor was also improved a bit and everything needed for a full mission can be set there. As you can see on the screenshot there are a couple of new features for the map: Roads, some more neutral objects and some enemy units. Shadows and shaders would be nice too, but there is no time for that right now. Maybe I will be able to put that into the engine next week. Moving around with the tank and aim and shoot on stuff should work tomorrow. Effects and AI won't be complete till christmas, there will be most likely only a couple of standard effects. Also collision detection is another big issue.

Day 12: Lots of dummy objects (especially the red car), but lighting works, loading maps from editor works and roads are going to work soon too ^^ Also a lot of gameplay classes done today. More objects will be made and imported soon to improve the game feeling.

Well, this shader stuff is really annoying. I got a new shader for the landscape in a test app working and implemented some test textures there. But when changing the light to a spotlight I ran into many problems, not so easy as I thought. At least I know now how to pass all that vertex buffer data to the vertex shader, but for a ground shader with works nice with all the lights there is still some work to do and I don't have the time for that. So I will skip now all the normal mapping stuff until later when the game is complete. For meshes normal maps are working (at least with directional light), maybe I will use some of that.

Anyways, time is running out, I wrote down all the weapons, powerups and enemies today and created some classes for that, but there is nothing finished yet, so no screenie today. Sorry. Worked the last couple of hours on shader stuff anyway and I told myself it I don't get it working today, I will leave shaders out and add them maybe later.

I was working still on the Editor today, not that much editor features were missing, but a lot of other stuff eat up a lot of development time. Drawing lines for example is really bad in DirectX, either you just draw some primitives and get slow when drawing a lot of them and have a lot of overhead each time setting all states (and recovering from some crazy states the caller might have left, nothing is working as espected) or you use this stupid Line class wrapper thing, which will cut your framerate by the factor 2 or 3 (really great, no wonder noone uses it). Or you can just draw stuff with vertex buffers, but thats also very annoying because you have to create the vertex buffer and handle all that vertex creation, and also obviously not the right approach for a single line. So I ended up writing a nice LineManager class, which collects all lines draw each frame and put them in a vertex buffer and because the lines are only changed when some big change happens, the vertex buffer can stay the same for a long time and thats really fast. Everthing gets rendered at the end of the frame (used for on screen controls and other stuff anyways). Same thing for filled boxes, color blending effects, etc. lots of helper classes. The texture blending (as you can see in the image) was also not a piece of cake, but the blending over 5x5 vertices is now a nice technique. The textures are not really fitting good together, when you just put them besides each other, but with this blending technique it looks really good (or maybe I'm just to tired to tell anymore ^^). Another bonus is my new vertex format, which is compatible with a test shader I wrote 2 days ago (which didn't run correctly back then, I only managed to do some basic stuff). Seems like some arguments where missing and the vertex shader wasn't complaining, but crashing some time later (after couple of calls, not really funny to debug). There isn't much time left, so maybe some features might have to be put on hold because I really want to finish the base game this week (just 1-2 missions, only basic features to see if its really as much fun as I imagine). If its playable a small demo or some sort of beta-version will be available before chrismas this week. Anyways, till new-year the game and the final demo-version should be finished, lets see. Maybe in the next couple of days things can be done more quickly because all the base classes and the complete framework are now completed.

Day 10: Yup, yesterday no screen, I was too tired. The editor is now finished, only setting objects and the roads is missing, but that should be easy. All the other sub menus and UI is now complete too, even the multiplayer stuff has a UI now waiting for implementation (dunno if there is enough time this week for that, would be nice though). Time for some gameplay this week

Today was Editor-Day. Our intern Fabian helped my out a little with the map file and we implemented all the UI controls for the Editor, all of them are working now, at least on the UI side. The Map Editor itself will be finished tomorrow, still a lot of smaller things to do before everything can run smoothly. The UI needed also some improvements, so I made completly new graphics for them and updated all UI controls and added some we needed for the Editor. All this little things, like writing UI code, writing smaller classes for the ground textures, the road logic, neutral objects and the enemy units can really keep someone busy. I still hope the basic engine for this game can be finished this week, so we got next week to make some cool missions and the advanced stuff (shooting, effects, multiplayer). About all this shader stuff from the last couple of days: I managed to get some basic shaders to work, which is really nice now, but still no clue how to implement all that spotlight normal mapping with alpha blended textures. Maybe I will just use some sort of directional light for the bump effects (or maybe a point light if I can pull that off, but then all the lighting calculation has to be done inside the shader as well, uhh complicated).

Day 8: Half-time, 1 week has gone by for this project. This is a image of the editor, you can easily create new maps or change existing maps with this nice tool :)

Day 5: A boring ground texture. You might guess there is still a lot missing and yeah, you are right! At least a lot of things are happening in the background: 6 different high-detail ground textures with normal map support are implemented into the engine right now, all the map, menu and game base classes are working now. Let's see what will be finished tomorrow. The shaders and the light effects are not implemented yet, so everything is at 100% brightness and normal mapping isn't working yet (but it will soon ^^).

Yep, thats right, I started implementing shader support and programming a normal mapping shader for the ground textures. You might ask, why the hell do you do this for a 14-day project? Well, I'm crazy, that's why I finished up testing some shader effects and writing a fx file with normal maps and multiple lights, but I didn't manage to get that into the engine today. Tomorrow I will try to import some objects, test out all that normal mapping and will play around with lights and light effects (dunno if a night mission with a lot of lights isn't total overkill and if I should stick with a simple directional light and maybe 1-2 point lights for the tanks).

There was also a noticeable delay when loading all ground textures (6 512x512 textures with 6 512x512 normal map textures and some other smaller textures), and thats not nice when debugging and testing out everything every few seconds. So I converted all textures from .jpg, .png, etc. to .dds format and used compressed formats like dxt1 and dxt5. Now the loading is lighting fast and I guess when not using the retail DX9 runtime the delay will not even be noticeable (remember, over 10mb of pixel data are loaded here).

For models I will see how long I can stick with .X files. Usually a format like this will make me angry after using it a couple of days because it does not support some little things and is most likely not extensible and I end up writing my own format (which can't obviously not happen in the short timeframe of this project).

It is also important to use the proper tools for DDS files, normal map generation and writing fx shaders (or other formats, but I like fx), which are:

• FxComposer by NVIDIA too for testing out .fx effect files and writing your own
• RenderMonkey by ATI is a really cool tool to try out shaders and test stuff, making shaders is not a piece of cake, even with all this tools around there is a lot of testing and modifying going on even if you got some nice shaders working.
• NVIDIA_Photoshop_Plugins for saving DDS files and making normal maps from heightmaps or textures
• DDSViewer by NVIDIA for viewing DDS as thumbnails, but thats not really helping that much (because windows thumbnails just suck). The DXViewer or so by the DXSDK is also really useless because its so user unfriendly. Also ACDSEE, IrfanView and Google Image viewer (Picasa Photo Organizer) and any other Pic-View program I tried do not support DDS files and don't even have plugins for that. But I found another viewer, which pretty much can't do anything but converting and displaying every format ever invented called: Konvertor. This thing is really crazy, don't ever try to read the full list of supported file formats (its 840 or so). Well, navigating suxx with this tool, but at least you can quickly display DDS files and zoom around. Konvertor has also another really nice feature: When you right-click on a file you will see a small preview, thats really one of the coolest thing I ever saw in a popup-menu Sad thing is: For DDS files this does not work, only .bmp, .jpg, etc. files previews are generated, grr!
• There are also a lot of other tools involved when saving stuff in 3D Studio Max, Maya, etc., but I won't get into that. Has nothing to do with programming ^^

I also underestimated all the classes I had to create for just rendering the landscape, there are of course still a lot of things missing as you can see on the screenshot. The basic layout for all the menu and game classes is now more or less complete and I'm pretty happy with it. Everything is still very easy to maintain and I got a good overview of the classes. The game has to be filled up with a lot of objects, roads, enemies, etc. in the next days. Hopefully all of this and the basic game engine and gameplay will be finished by the end of this week, so we have next week to test and balance the game, make some cool missions and bugfix the hell out of it (well, the engine is only a couple of days old now and only tested by me and my unit testing stuff).

Btw: VS2005 will get REALLY slow when you have a lot of files opened and try to compile or work on some older file. I think some part of the auto-recovery of files when crashing is not really optimzied. Anyways, when you close all documents and open only a couple (lets say no more than 10-20), VS will responde quickly again. Little annoying, but I'm now much better of knowing that ^^

I also registered the domain www.LostSquadronGame.com, which will be the official site for Lost Squadron. But when its up and running it will just link to this site until we got some finished page (which is not planed before chrismas, but as I know our graphic guy Leif, he can't help himself and will make a page design when I'm not looking).

Well, there is no screenshot today for several reasons. First of all I hadn't much time to program today because I visited my grandparents (brithday and stuff) and then was visiting my parents (all this family crap ^^). And secondly I was developing via remote today and for graphics this can be a pain in the ass because everything is so slow (software rendering with remote desktop suxx (slow and no effects are working) and hardware rendering with vnc will never display whats going on ^^), so I have finished some base classes and all the Sound and Music classes required later on. I also started writing my own UI handling, the DirectX9 utility toolkit seems to be a bit of an overkill for my little game.

I promise, there won't be any more days without screenshots.

Day 1: Finished loading textures, displaying text, game loop, imported lot of useful classes from older projects, tryed out dds and x file formats, etc. but we still got a boring black window. I promise tomorrow there will be something more fancy

Hey now! Today I started the game and engine of a new smaller game project I will hopefully finish till chrismas. Our intern at exDream Ivo will help me out with some models and textures, other than that its only me ^^ The game will be called Lost Squadron and is a kind of an advanced shoot'n'up game, you drive around with a tank (and later on other vehicles) and blow up stuff (this might get you an impression on how I feel right now ^^)

I will use DirectX9 with c# for my first time (used only OpenGL before), but I already know how to program with DirectX (worked with DirectX in my c++ times) and I am pretty aware of some uncool factors when DirectX just returns a stupid error code -420529345 without any reference and no documentation about this (maybe when you search long enough you will find out that this translated to "some error occurred" or "some of the freaking 100 parameters you passed is invalid", like that tells you anything useful).
Don't believe me? Then just try to load a texture or create a empty texture. If any parameter is wrong, the file does not exists or the color of the sky is not an exact RGB value, the app crashes (an exception is thrown with an error message that tells you nothing). DirectX won't tell you whats going on, just that you have to try out for half an hour to find the correct combination (or you might find out that just some file was missing).

I always woundered why nobody bothered to tell Mircosoft that this is bullshit, any robust framework needs to handle that way better, you can't assume everyone passes only 100% correct stuff to you.

Whatever, maybe it's normal to be pissed, when dealing with this again after 2-3 years of OpenGL development (in OpenGL on the other hand you will sometimes not give you any error message at all, which can also be annoying).

To top that of I fought several hours to get DirectX9 native debugging enabled with VS2005, which resulted always in an IDE look up and crashes if any native exceptions occur (if nothing goes wrong or you use the release builds it works, but hell, I want to debug the freaking DirectX stuff). Anyways, I'm back to VS2003 for this project and had also to rewrite all my generics code back to work with VS2003 and .NET 1.1 (well, I had to do that anyways because this game should not require .NET 2.0).
Later I found out that any project (including all the c# tutorial and example files) will crash when quitting in debug version them because some memory is not freed properly. I just deactivated any Direct3D memory exceptions (with DxDiag) and now finally I can work without all this stupid exceptions (maybe it has something to do with bad graphic drivers or a corrupt dx version) ...

Well that aside, DirectX9 has a lot of good stuff. I really like the way you can now implement easily user interface graphics, buttons, textboxes, etc.

This game is not about writing some ugly spagetti code as fast as possible in this 14 days. I will try to produce the base code for my new engine and just develop the game to check out its basic features.
The engine will use a lot of Unit Testing, base classed for all the grunt work and also a lot of error handling and generalization.

I thought about using some existing engine for this smaller project, but I don't the way most engines just focus on first person shooter development and I also want to use my base classes I am comfortable with.

Hey everyone. I've been busy doing some smaller projects and finishing up some things. I just posted an article on www.CodeProject.com: Writing a CodeRush plugin: Commenter will help you to comment your code and make it easier to navigate through your code. The program, including an installer and the complete sourcecode can be downloaded there. If you got any questions about this, please ask them there. If you just want to download the tool or the sourcecode, you can do it also here: CR_Commenter Installer, CR_Commenter Sourcecode. Remember you will need CodeRush to use this plugin. We also have now a nice idea for a nice little game we might release just before chrismas. Last year we made www.EuroVernichter.de just before chrismas. I've also updated abi/blog/PermaLink.aspx?guid=f44ddbad-ea76-478a-a091-241fd9c8b209">My Bookmarks and the Blogroll.

Click here to download CR_Commenter.zip v1.7 And here is the sourcecode for CR_Commenter v1.7 Older versions: v1.4 (VS2003 support), v1.5, v1.5 source

History

• Initial version: 2004-12-08 (v1.0)
  Initial version supports commenting, adding header block and basic XML generation. Wrote the CodeProject article.

• First Update: 2004-12-12 (v1.1)
  Lots of smaller improvements (more generated comments, click on auto generated comments to jump to function, etc.), very stable now!

• Second Update: 2004-12-17 (v1.2)
  New version 2004-12-17 with some minor bug fixes (wrong comments, etc.)

• Third Update: 2005-04-04 (v1.3)
  Several new features and some bug fixes, see TODO list. Supports now newest CodeRush version, auto XML comments work now for non-public methods too and will produce better comments. Also added better support for non c# files like fx, cpp, h, etc. If CodeRush does not parse them, Commenter will do it and still generate nice comments and the header section!

• Another Update: 2005-10-27 (v1.4)
  Basically I was annoyed of some old bugs like namespace commenting (which produces a compiler warning in vs2005) or auto-commenting of initialized variables inside methods with xml (again, a compiler warning, but this happend only if all commenting features were turned on). I fixed those things and added a couple of cool new features:
  • Fixed: No more Xml Generation of namespace sections or for variables in methods.
  • Fixed: All sections are updated, the first one is not skipped anymore.
  • Fixed: Using directives section generation works now fine with multiple lines for a single using statement.
  • Fixed: Structs, enums and switch statements to now correctly generate comments and xml comments.
  • New feature: Added a bunch of keywords to translate abbrivations to full names. This one is very cool, it makes the Commenter look smart because it will automatically generate meaningful comments for methods and parameters. For example "xPos" becomes "X coordinate position" or "bmp" becomes "Bitmap", "descNum" becomes "Description number", etc.
  • Also made some of the choices smarter where to generate which xml parameters, e.g. variables and classes do not longer use the return xml comment.

• And another update: 2005-12-28 (v1.5)
• First version for VS2005 and using .NET 2.0 now for supporting generics and anoynmous delegates (more useful comments now inside of anoynmous functions and code blocks defined there).
• Fixed again: No xml generation inside of methods (recent CodeRush version changed its behaviour somehow). Check is now performed inside the recursive method, this fixes all older issues too.
• When commenter is disabled the globol hotkeys don't work anymore now.
• Version number in options and a link to check if any new updates are available
• Hotkey for generating comments and XML: Ctrl+1. Saves you typing '}' and doesn't require you to go to the last line of a block all the time.
• If using defines in the using statements the surrounding region is now generated properly. Also adds automatically the #if DEBUG and #endif statements (which I use to exclude NUnit from the release build) around using NUnit.Framework, which is often generated by adding the namespace automatically or using some template.

• Update to support C# 3.0/LinQ May 2006 CTP: 2006-06-08 (v1.6)
• Added add namespace feature to support C# 3.0 (CTP May) in VS 2005.
• Added action hint effects for commenting, regions and namespace adding.
• Improved options screen a little, added more hotkeys and help
• More hotkeys available, Ctrl+1, Ctrl+2, Ctrl+3, Ctrl+F9, Ctrl+.
  
  
• Added some features and fixed some old bugs: 2006-08-06 (v1.7)
• Bugfix: Long comment lines got now properly cut off (doesn't go over 80 anymore)
• Bugfix: Fixed autogenerating header when user modified or shortened it
• New feature: Generating comments will not longer expand any collapsed regions, at whichever file position we are. This means if you generate comments for a whole file, all collapsed regions will be collapsed again after everything was modified.
• New feature: Parameter comment generating works now always, no matter if you add or remove parameters. This is a quite useful feature, even refactoring parameters is supported (moving, removing, adding stuff).
• New feature: Autosorting feature for using directives, also fixed couple of using issues.
• Improved hotkeys a little:
• Ctrl+1: Does perform the same action as closing a block with '}', but can be used anywhere inside a method or class.
• Ctrl+2 or Ctrl+.: Adds a namespace for the current word at the cursor. Used to support automatically adding a namespace in C# 3.0
• Ctrl+3: Autogenerate region around the current block (method, property, constructor, etc.), for selections use Ctrl+R.
• Ctrl+4: Toggle collapsing and expanding current selection.
• Ctrl+5: Toggle collapsing and expanding everything at top level (also supports sub regions).
• Ctrl+6 or Ctrl+F9: Update all comments and xml blocks for the whole file.