Figured I’d post this on the blog seeing as it’s been posted on AG and elsewhere.

Yes, we have finally released our binaries to the general public! Figured I’d post this on the blog seeing as it’s been posted on AG and elsewhere. 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:

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

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.

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

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.