Hey there everybody. Today I am introducing a new feature in the ever growing Axel Project, HDR powered bloom. If you were to remember way way back into January, we had Valve’s prototype HDR pipeline working to an extent, but, it was severely handicapped, in that you had to do two passes, one for opaque objects, and the other for transparent objects and didn’t look that great either.

I took it upon myself to research and come up with a new HDR pipeline, which happened to last a very very long time. After removing Valve’s original code, I started from scratch, using several ideas from various web sites (gamedev.net in particular) and publications. We are using two floating point 16-bit buffers to hold downscaled and blurred luminance values, along with a simple “ping-pong” 4 stage shader pass. This culminated into my whipped up prototype which was enhanced to the point of what your about to see:

Test Video:

This video was rendered in-game at 1920×1200 with AA enabled and Fraps turned ON, hence the kinda stuttering effect you may see (Looks downright mouthwatering on my cinema display btw). Everything is configurable by use of console variables (cvars), even the vignette (*cough*Denis*cough*).

I’m also investigating adding some other shader effects in order to differentiate our engine and give us a somewhat “classier” look.

Current Release 2 Status:

Release 2 is charging ahead, with a ton more done to stabilize the engine core done in the past two weeks. We happen to have an August due date, but as everybody knows, could slip away due to “the fabric of TAP time”.

Happy Fourth of July,
Pat

Hi there everyone, it’s been a long month since we’ve all been busy with school/work etc. I will probably be repeating myself with a few of these updates, since we had some issues with the database and whatnot.

GameUI Animations:

Saul added support for retail-like GameUI animations in the menu in March, making the UI a lot sexier. You can view a video of it in action here:

Model Converter & Decompiler:

Recently ynh and Saul managed to get the decompiler to decompile animations properly, the mesh is still somewhat broken, hopefully I will have something more to post on this in the next update. Our model converter is also progressing well, we’re planning to add a GUI and generally finish it off in the coming weeks. Not sure if we’ll release this publicly but it is possible!

Status and future plans:

It seems that some people out there think that the project is dead (you know who you are), this is completely false. Although progress has been slow recently, we are still on track for a summer release of our second patch, which should fix a lot of the issues in the first patch.

Around a month ago, ben5015se left the team due to some internal conflicts that couldn’t be resolved. In his anger, he apparently decided to leak the R1 code. This has not affected our progress, and the current code we have is a lot better than what has been leaked. We would also like to wish Ben luck with his future “project”.

We’re planning to have a few preview maps for you guys to play around with by the time R2 comes around, Pat has been working on something special I’ll reveal next time :)

Yes, we have finally released our binaries to the general public! They are available from this link.

There was a lot more that we wanted to ship in this release. But seeing as we’ve had various problems to deal with over the past month, we would never have been able to release. The maps that I was planning to ship will most likely be released in a later update to the bins.

In the meantime, have fun with these bins. They should help hugely with stability and various other bugs that were problems in anon.

And lastly, I’d like to thank the team for their dedication and hard work this past year. None of this could have been done without you :)

Hi all,

Sorry for the huge delays, I’ve been extremely busy recently (as has the entire team) with IRL matters. But here’s a brief overview of what the team has been up to:

HUD Font support

In retail, many HUD icons use font characters as they are vectorized and don’t look “blocky” at high resolutions. After spending a couple of days playing around with the HUD code, we got it to work. This means the weapon selection HUD looks a lot better, and paves the way for a cleaner CS:S HUD, too.

Multiplayer AI

Ben has been busy getting AI to work in multiplayer, hopefully I’ll have some screenshots for this soon!

Client logos

In the leak engine, there are several exploits related to file uploads, which can result in filling up a server’s hard-drive or even uploading viruses to Windows servers (not good!). Files which clients can upload are now a lot more strict in size, type and location.

Initializing screen

If you’ve used Anon leak, you will have realised the loading screen (before the main menu) is ugly and bland, with a simple “Loading…” on a gray background. This is all performed with GDI, and with GDI it is also possible to draw bitmaps on screen, too. So we read the image data out of the VTF, convert it to a GDI bitmap, stretch it to the window size and paint. Magic!

Congratulations Pat!

Congratulations to our project leader, Pat, who is now the proud father of a baby girl, born on 4th February. During all this, Pat has had the time to build a game distribution network, which will soon be integrated into the engine (hopefully today). More information from the man himself when he has time.

Conclusion

Once again sorry for the late update, I probably won’t be able to make these as regular as I hoped– bi-monthly at the least. Stay tuned for Soda info soon. Peace out!

I don’t know how many people who read this blog (if any) remember ApertureGaming, but it’s been re-opened! Visit http://www.aperturegaming.com

We all look forward to seeing everyone show off their work with the HL2 leak!

/ynh

Hey all! Not much to talk about, but basically a review of what I and the team been doing over the past few days:

Server-side bots

If you’ve ever played Counter-Strike: Source, then you will surely know about server-side bots. These bots are surprisingly good and fun to play with, however this is not the reason we decided to implement them in Axel. As our team lives around the world and none of us have particularily good upload speeds, it’s quite hard to test multiplayer with someone with a ping <100ms. Therefore Pat asked for a test bot framework, “for testing out the engine and net code as well as dm/coop”.

As I know there is bot code in the Source SDK, I took a shot at copy and pasting the bot files over from the EP1 SDK. After a couple of hours fiddling with file includes and changing some functions around, I got the code to compile. However in the game the bots would not move. At all. As I hate copy and pasting code, I decided to scrap that idea and make my own, using the SDK bot as inspiration. If you’ve  been following the blog, you should have noticed the link I put to the bot images directory several days ago. This contained screenshots of some very basic (and bad) bots in a square map. The bot:

  • If further than x units away from the target player:
  • Look at the player’s origin
  • Simulate pressing “forward”
  • If within x units to the player:
  • Move backwards

However the bot had a huge flaw: the player must be in the line of sight of the bot. The bot could, however, climb over objects.

Not being content with the results, I decided to implement the navigation mesh system available in the Episode 1 SDK. I showed a screenshot of the working navigation mesh editor on the blog, too. This was a huge result for me and had taken several grueling hours of porting over EP1 functions and classes, however it paid off. This meant I could now set to work on pathfinding, which I completed today. Take a look at the bot navigating towards me:

Pathfinding

Pathfinding

Although the bot’s pathfinding isn’t perfect, it’s very ‘fixable’.

Alex is back!

After being away for several months (bad internet connection), Alex AKA G0rdan is back on the team. He immediately set to work on bringing proper animations to HL2DM. Hopefully, HL2DM animations will soon look like this (except with proper weapon detection):

Counter-Strike: Source animations

Counter-Strike: Source animations

Upcoming code review

If you’ve ever been part of any mod/project team involving coding, you’ll notice that you get off track and start implementing features while the bugs mount up. YNH decided that enough was enough and we’re going to start a code review. In the bug tracker, there are currently six Immediate urgency issues, and four Urgent. These are the “show stopper” bugs that are delaying release. The majority of these bugs can be easily fixed if all of the team’s programmers put their mind to it… so wish us luck!

Conclusion

For once I’ve managed to wrap up everything the team has been up to in the past week, and I’m hoping to make the “Dev update” blog posts more ritual. Therefore dev updates will now be every Sunday (instead of just randomly). This will hopefully allow me to cover everything, plus I’m usually free on Sundays. Peace out.

Navigation mesh

Navigation mesh

Stay tuned for more!

There’s nothing better than a bot that can follow you and avoid grenades, so I decided to spend a couple of hours today and it (surprisingly) worked very well. Check the bot folder in the images directory to see more!

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):

Anti-aliasing options

Anti-aliasing options

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!):

Snapshot types

Snapshot types

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”:

Old transparency

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:

New transparency

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:

Multiplayer loading dialog

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

Singleplayer loading dialog

Singleplayer loading dialog

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!):

Compile process

Compile process

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:

Before anti-aliasing

Before anti-aliasing

After anti-aliasing

After anti-aliasing

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 :D ). 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:

Chapter dialog

Chapter dialog

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.