Hey all, it’s me again. True to my word I’m updating the blog with recent SVN updates!

Anti-aliasing (again)

If you saw the last blog post you’ll see that anti-aliasing was hard to implement as a ConVar… well we  cracked it! Anti-aliasing is now available in several modes (MSAA 2x through 16x and CSAA 8x through 16x):

Note: in the screenshot above you can only see MSAA modes, this is because the graphics card of whoever took the screenshot doesn’t support any CSAA modes.

But anti-aliasing isn’t totally fixed. DirectX is crying…

Direct3D9: (ERROR) :MultiSampleType between DepthStencil Buffer and RenderTarget must match.

when bloom or another screen-space effect is enabled (or render targets). I’ll post another blog entry when we completely fix this.

Screenshots

Whilst flicking through the issue tracker, I found a bug that Logan posted several months ago, which seemed very easy to fix (don’t know why I couldn’t do it earlier). Basically he wanted PNG or JPG screenshot support in the engine, which seems simple, right? Well it is. D3DXSaveSurfaceToFile does this for us, however the only slight issue was that this function requires an absolute path. Therefore I had to mess around with filesystem to get the absolute path to <launcher dir>/<mod>/screenshots. There are now 7 file formats to save screenshots in (woohoo!):

Model decompiler

We all know about CannonFodder’s MDLDecompiler, which is very useful for decompiling V44 models and using our studiomdl to compile them into V37, but decompiling V37 models is currently impossible. So I set about coding my own, which seemed very useful at first thanks to this brilliant VDC article. However, I’m currently failing to export triangles correctly (as well as the skeleton). Hopefully more updates on this soon.

Conclusion

Things which I don’t have time to write up:

• Ben is in the process of fixing the tracker;
• Not much more!

This has been a lot shorter than the previous article, but fear not, more updates Pat’s Steam clone, Soda soon! Peace out.

I don’t think I’ve introduced myself on here before, but I’m Saul Rennison and I’m a programmer for Axel Project. I’ve been very busy over the past few weeks and months polishing the UI and other front-end things as the engine is now solid and I’ve implemented everything I wanted (server plugins being one of them). When I can, I post images of my progress in the images folder.

I hope to make a habit of posting behind-the-scenes progress of what the team is working on, I believe as it stands, it looks like the project may even be dead to outsiders. I don’t believe that “no news is good news”. Anyway, here’s a quick overview of what I’ve been working on:

UI transparency

This actually went through two phases. Initially everything was transparent, but this seemed a little “over-the-top”:

As you can see in the “Advanced video options” dialog, the text is relatively hard to read when placed above a panel with text on it. So to fix this, I only made the window panel transparent, as shown here:

Transparency only took a few lines changes to implement, although it looks very nice.

Loading dialog

If you’re familiar with the leak, you’ll see that there is absolutely no loading dialog at all. There is code for the loading dialog in the GameUI interface, albeit old and somewhat dead (unused parameters), although it is relatively easy to fixup. There is no code for it in the engine, however this was easy to implement, too. Like the above, this also went through several stages. The final product is personally more intuitive than the retail loading dialog and uses less screen space:

The singleplayer loading dialog is even simpler, with only ever one progress bar and only has the literal percentage in the middle of it:

Batch compiling

Yesterday I was trying to expand our old BAT file compiling system and failed miserably. I don’t dislike BAT files, I just dislike it’s extensibility and I don’t think it’s suited for Axel’s compiling needs. I knew Pat had a SCONS system in the pipeline, which also employs Python, but I thought I’d try tackling the issue myself (Pat is a very busy man after all). I tried to design the front-end with non-savvy users in mind. By this I mean suit it for members of the team who don’t know that to compile in Debug mode they’d have to use build axelproject -Tgame,HL2 -B Debug, without sacrificing power. After several hours coding, primarily trying to get myself back into Python again (looking over the code I realised I had used ; at the end of some lines), I finished it. Here is a screenshot of the compiler as it stands (with pretty colours!):

This is simpler than the leak compile system for a number of reasons:

• Saves echoing the entire compile log to console, even when there are no compile errors;
• Compile errors print in the console and halt the compile process (can be disabled);
• Has 1 BAT file proxy instead of 20, where the user can input which game, build mode and settings they wish to use;

Anti-aliasing

This is proving to be a bit of a bummer. In the leak engine, anti-aliasing is enabled via -mat_antialias # on the command-line. However this method is impractical (and impossible) to use in something like an Options dialog. I’m currently working on this (have been for a couple of days now), but I’m trying to find a solid way of enabling super sampling. At the moment it is working on Pat’s machine, but not mine. The difference is negligible in the screenshots below, so click on them for a better look, and flick between windows/tabs to really spot the difference:

Chapter dialog

If any of you have played singleplayer Half-Life 2, Episode: 1, etc, then you will have noticed the beautiful New Game dialog they all use. Pat had previously committed a semi-working replica to the SVN several months ago, although never finished it (typical ). This is a pretty vital feature for the release so I decided to implement it fully. For those of you interested, here is a full overview on its internal workings:

• GameUI parses a KeyValues file named chapters/chapters.txt, which holds which map each chapter corresponds to;
• It then loads the images for each chapter, located in materials/vgui/chapters/chapter#.vtf;
• Checks to see if the chapter has been unlocked, if so it enables the button to play it;

As in retail, there is a ConVar which controls how many chapters have been unlocked, called sv_unlocked_chapters. Luckily for me the code for it is in the Source SDK, so it wasn’t hard to replicate. Enough talking, here it is:

Other

There’s stuff that I’ve missed off, but don’t really have enough time to write up every single one:

• Server plugins: replicating the current Source engine’s server-side extensibility;
• Many exploit fixes: all public Source Engine exploits have been fixed;
• Shader updates: wrapped lighting on models;
• Advanced Video dialog;
• Fixed up majority of localization;
• Multiplayer is in a semi-playable state;
• Background maps;
• Much more I can’t remember;

Conclusion

Please take into account that this is only the work of the previous month and much more work and effort has been put into fixing bugs and adding new features, not to mention many members have been inactive over the holiday season.

Peace out.

We have made quite a lot of progress in the past few weeks since we announced our release. We started off with a monster-sized todo list and now we have a not-so large todo list. However, we have decided to delay the release for a month or so, to allow ourselves a little more breathing room.

To avoid making serious mistakes, we are now working towards a mid-late January release. This will mean that the overall release will be much better in terms of quality. This will also mean that there will be a bigger variety of content available in this patch.

In the meantime, check out our image gallery, and keep watching this space!

It seems that some issues which I, and the rest of the team, thought had been removed long, long ago (when we removed fire64, and some other russians from the team) have come back to the surface. So I feel that we must explain ourselves before we release. I am of course referring to the latest post on Junk’s blog.

The post says that raynorpat used code that was leaked from Team GabeN way back in 2006/2007. This is actually quite wrong. The code was added by the said russian members before he even joined the team in mid 2008 (they had been using his Source3 code before)

However, the current members on the team during the period the code was in our repository (myself, raynorpat and Superbird) did not attempt to remove it until our code was leaked in March. And for that, we apologize.

Also, to add to this, we started scratch from a fresh copy of hl2_src.rar in July, and there is no Source3 code in our current revision.

It’s been about 9 months since we changed our name, and a lot of work has gone into fixing up our code and such.

So, we’ve decided that we’re going to release our binaries as a patch for the leak, as a christmas gift

The release will most likely contain the fixed e3 presentation, along with the bins themselves. I may decide to add a few of my testmaps just for laughs.

Our current feature set is as follows:

• Full V37 model support;
• Full V18-20 VBSP support;
• Fixed shaders (including bloom);
• Retail chapter dialog;
• Background map support;
• JPG/PNG screenshot support;
• Post processing effects;

This will purely be a binary patch for the anon leak, with a few of our own maps. It is not the final, finished product which we will be releasing at another date.

That’s all for now, and we look forward to releasing

Visit our (small but growing) image gallery here!

Currently, we’ve got a few pictures demonstrating shaders, but we’ll have some more stuff up like model renders and actual map screenshots.

/ynh

If you can do any of the following decently:

• Map
• Model
• Skin

Then we’re looking for you. Go to the application page and write us an application! We will ask for previous work, so gather up those old source files

/ynh