Blog

It has been a while since our last development update, so here it goes, a small roundup where 0.7 is now and where it is going. It has been a long year since the release of 0.6, but also a lot progress has been made. Apart from work on the game itself, we built a new, completely in-house-developed website platform with a blazing-fast forum. This stole some precious development time from the game, but we consider it a time well spent.

There are also boring and time-consuming tasks that users will never directly see but take enormous amount of time and boring engineering to set up, such as our cross-compile buildbot platform. Vic hopefully blogs about this later to give you a little peak to the dark side of Warsow development.

Without further ado, here is where we are now in terms of 0.7 development:

Engine improvements and map optimizations

Like Vic already blogged here and here, engine has gained some notable improvements on rendering speed. Not just small tunings, but with more than double performance on good hardware. In addition to VBO improvements which were released with 0.62 and upcoming GPU skinning, there are tons of miscellaneous improvements all over the engine, but here are a few that I can remember right off the bat:

* Toukka optimized image loading functions, which ended up giving noticeable boost when loading hundreds of textures.
* A bit more modern m_raw for Linux, using Xinput2.
* Models also use VBO's now.
* Alt+entering between fullscreen and windowed mode is now instant in Windows (no vid_restart required).
* Considerably faster map loading times. Just to make this clear: this won't make your ten-year-old Celeron perform any better, but with recent hardware, improvements are gigantic. Video of map loading times in 0.7:



Not all 0.7 optimizations come from the code, though. Sometime during the development phase we began wondering about bad performance in some maps, even when they are not any more complex than maps that run just fine. Especially FPS drops at wbomb3 bridge were puzzling - of course this point forces the engine to render a relatively large area at once, but the drops were still a lot bigger than they should have been.

In the end we discovered that all the dropping originated from q3map2 bug with using solid flag with map models. q3map2 clips solid models with really nasty algorithm which generates overly complex clippings for the models and makes collision detection go crazy. Interestingly, the biggest source of stuttering at wbomb3 bridge turned out to be the wooden crates. Terrain still remains flagged as solid model, because manually clipping the terrain is next to impossible, so the FPS gain could, in theory, be improved even further. So here's a friendly tip to mappers: never ever make your map models solid.

Here's the horror shot of collision detection traces happening at wbomb3 bridge in 0.6 version:





Over 13 000 traces? Really? Now here's the same scene from 0.7 optimized version, giving a little more sensible amount of collision tracing:





Effective FPS improvement on my machine (both stock medium profile) after map optimizations:





While this collision problem was a major problem, there was a lot of room for improvement in almost every map, detailing, caulking, boring minor stuff mappers haven't bothered to do while making the map, so I went through all maps and optimized the roughest edges out of them. By average, I'd estimate bomb maps got at least 10% to 30% better FPS only by .map tuning.

Gameplay improvements

I remember this feature was requested back in 0.6, but somehow it got lost and forgotten. I have finally got this done, teammate indicators for teammates out of view (cg_showteammates):





Even bigger change in gameplay, however, will be the implementation of octagon hitboxes. What is an octagon, and what's the difference?





Currently hitbox area is a rectangle, and the important bit is to note that it does not rotate. Basically this means slight collisions with other players can be pretty annoying when ever so slightly colliding with another player and losing all your speed in the progress. Also, when shooting from 45 degree angles, hitboxes appear bigger than from 0, 90 or 180 degree angles. With octagon hitboxes not only the hit area has much more constant size from all angles, but collisions with other players (and map itself) are now much smoother an experience.

r_drawflat and r_lighting_grayscale

Now here are two awesome new features crafted by (like majority of the engine stuff) Vic. Those who are familiar with ezQuake engine might have seen this feature already in QuakeWorld, and yes, it was inspired by ezQuake. In short, r_drawflat lets you define your own custom wall and ceiling/floor colors. r_lighting_grayscale lets you make all the colors grayscale, effectively removing all colored lights from the map.

Here's an example with basic r_drawflat in its default configuration (with medium profile):





For comparison, here's the same scene with r_lighting_grayscale enabled:





Totally whackos can go for LSD colors:





This is my personal favourite though, combining white environment with outlines:





Mapping

Apart from optimizations, maps have also received little makeovers all over to keep the look modern. And yes, wbomb6 aka depot (old downtown) is coming to 0.7. Here are a few shots from the final version:

















And some assorted map improvements:













New wca3 in progress:





New wdm11, wdm16 and wdm17. Public test releases of all of these have been played on servers already, so nothing new for active players:













.. and finally, a work in progress -wdm6 shot from kimza:





Global statistics

Yes, that's still coming. Nothing new to report regarding it though - it's mostly done for server and client side of things. Thankfully, clownFart is helping me with the web side of statistics, so eventually that'll come together too. For more information regarding global stats, read Toukka's post here.

New UI

This is where things get grim. Yes, it is coming (and required for statistics stuff and other goodness). No, it is not ready. And yes, it will eventually be ready. But at the moment it is the biggest thing dragging in 0.7 development. Eventually we'll get around the (technical) problems we're having, so just be patient :-)

That's it for now. Enjoy.

Ugh, finally! New website and new forum! Hugs to milkflow for the layout <3

After few weeks of intense development we finally got this thing ready. Everything is self-developed from scratch, so excuse us, there might be few bugs left. Please report any bugs you find!

As I'm totally burned out from doing this site and forum for last few weeks, I'm not gonna write too long post about it, but to note few things:

* Private messages have also been imported from the old forum, but there is no ui to access or send pm's yet. PM features will follow sometime within couple upcoming weeks.

* New wiki will be set up sometime during next couple weeks. Yes, it's still slow and crappy currently. Sorry.

Have fun.

Hello!  Here is a short teaser on our brand-new UI that we are working on.
Not giving you much details at the moment, but let me just tell you that we are going to use this html version as is (hint hint).

If you want to see this finished and want/can help out or know someone how can, see this post!

Welcome back to the second installation of engine adventures! This time I'll talk about the changes I've introduced to the model rendering in the next version of the game. If you don't like technical details, you may just skip to the end of this blog post :)

The first major change is that we've switched the model format we use for skeletal animation: SKM/SKP is gone, IQM is in. The reasons are quite simple: SKM isn't used anywhere outside Warsow, it's an obscure and barely supported tools and exporters wise format. IQM aims to be the universally accepted format for all relevant Quake-based engines so the chances it's not going to become obsolete in the near future are higher than those for SKM. By the way, the SKM/SKM to IQE exporter was part of the 0.62 release..

One thing I noticed while speccing bomb matches in 0.6x is that framerates dropped considerably with several player models in sight. Clearly something had to be done about that. Two things came to mind: performing skeletal animation on GPU and avoiding multipass shaders for our player skins. Moreover, both approaches required GLSL programming, could be implemented independently and would complement each other nicely.

Non GLSL path could also be optimized using an approach called matrix palette skinning, which is done on CPU. It allows performing only one matrix multiplication per vertex, irregardless of the number of affecting bones. In case you didn't know, each vertex in a skeletal model has 1 or more influencing bones attached to it. Both SKM and IQM pose a limit of influencing bones at 4. Each influence is basically a matrix and a influencing factor (weight), ranging from 0 to 1. Skeletal animation basically boils done to transforming these matrices and then applying the result to vertices. In short, matrix palette skinning allows combining these influencing matrices beforehand and not transforming the vertex by each influence individually, saving the CPU power.

For the GPU skinning dual quaternions technique could be used. eihrul (the author and maintainer of the IQM format) helped me enormously to implement both approaches, patiently answering my questions on the IRC and providing me with clues and code. Thank you, Lee!

Perhaps the least mathematically intriguing part of my optimizations and the most torturing one was writing a specialized GLSL shader that would allow to render all of our player models in a single pass, no matter what skin. That required painstakingly analyzing, grouping and templating of all of the shaders we use for player skins and then writing and debugging the aforementioned GLSL program, which wasn't a terribly exciting experience, but I won't go into further details on that.

All the changes I described here took a couple of months of on and off work to implement and debug.

Now what's the outcome in terms of framerates a reader might ask? Here are screenshots of 0.62 and 0.7 running the same scene with 20 animated bigvic models with default skins (fps counter is in the upper right corner).

Note that both screenshots were taken with model outlines enabled, so that doubled the number of models actually rendered.

Good morning War§ow!
I’m here to give you a long-waited status on the upcoming feature to War§ow, which tracks match-history and statistics and will also derive players skills to allow creating skillmatched games in the future.

Before that, I’ll introduce myself. you can call me toukka. I’m a new member to the team, officially began my quest in the beginning of current year, brought into the team to work on the stats-tracking/matchmaking-system. I’m the author of currently defunct Pig Browser that got good response and popularity among War§ow’s duel-scene, thank you for that.

Breaking few common misconceptions.
Generally speaking we are not enforcing anyone to login to play War§ow. Only if you want your statistics to be saved to your own profile. Matchresults will show bare information on players who hasn’t logged in, unless in the case there is no logged-in players in the game, nothing will be recorded.

We are giving servers the possibility to restrict themselves to accept only players who have logged-in (that is why I wrote ‘generally’ above). This feature could be used on e.g. cup servers.

This will not be a list of ‘Who’s the best player’. There will be lists putting players to order in certain tasks and fields, but we are not taking a stance in saying who’s who.

What it does?
We will gather statistics on players gaming and calculate skillratings separate for each gametype.
Records will be gathered only from servers that are enabled and registered for matchmaking.
Server administrators need to register their servers to be able to host matchmaking-enabled games, registration will be done by personally contacting War§ow team. We are most likely going to contact major server admins ourselves.

Players use their warsow.net accounts to login, which happens in-game. Once again, logging-in is not mandatory unless the server itself has limited clients to logged-in-only!
If there is a game with both players that has or hasn’t logged in, the players that hasn’t logged-in will have basic frags/deaths/points recorded. If there is no players that have logged in, nothing will be recorded.

Warsow.net will have additional section to view these statistics, match-histories, leaderboards etc.., all kinds of fun stuff. Website-side will be handled by crizis, so I’ll let him do the talking on that if he will.

Statistics stored include your basic frags/deaths/points, weapon-specific accuracies, damages and frags, game-awards achieved and for at least some gametypes we will record all frags, who did against whom, when and with what weapon. There will also be career achievements, dont directly confuse these with the awards you get in-game. You ‘achieve’ these by completing different tasks through your games.

Skillratings will be calculated strictly on the ordering of players by points, not the absolute amount of points, frags, accuracy or anything like that. Algorithm is loosely based on both Elo and Trueskill, featuring a decay in the ‘confidence’ of the skillrating. I have prepared a small description of the algorithm that I may or may not release in the future.

Back to the future.
Matchmaking. Above text didn’t give you any details about matchmaking, and that is because it isn’t happening yet. We built the backbones of the system that will record all about your gaming and calculate skillratings which will allow us to bring matchmaking-mechanisms in the future.
There is also the possibility of setting up official cup/ladder-system, but this is yet so far away that I wont write more than that.
We are most likely going to experiment with ‘advanced features’ through the website and not ingame, one primary reason being that it’s much easier to experiment and develop that way.

We are in the midst of preparing our first full tests of the system and are very excited about this and hope you will enjoy these features when we get them released.

I've been tempted to write a blog post about the engine work I'm doing for Warsow for quite a while but never got to actually doing it until now. Hopefully this blog post is going to be only the first part in the series..

One of the major things I implemented for 0.6 was support for static vertex buffer objects (VBO) for world geometry. What do VBO's do? They allow storing geometry and other accompanying useful data to be stored in video card's memory so when things need to be rendered no huge memory transfers need to be done, you just pass the VBO's index to GPU instead. Nice and simple.

Some of the maps benefited from the feature quite noticeably, exhibiting a x2-x3 boost in performance in scenes with small player counts. But some of the maps seemed to be little affected by the feature or weren't affected at all. One such example was the new wdm5. The so-so performance in some of the scenes was then attributed to high polygon counts and portalmaps, although VBO's exist precisely to combat high polygon counts among other things.

The thing slipped into the final version of 0.6 but I kept on returning to it in my mind, it was obvious something was going very wrong there. Finally one day I decided to take a stab at it and started profiling the map. My initial assumption was that VBO's weren't created for the majority of surfaces so huge memory transfers were still occurring, drastically slowing everything down. As it turned out, I was wrong. Almost everything in the map was packed into VBO's just fine, no obvious bugs popped up. I added a few more counters to r_speeds 1 output to see if there were any hints there, one thing I noticed was a high VBO count in the scene you can see in the screenshot above. Each VBO requires a separate call to the driver to be rendered but since it's all static data, in theory it shouldn't hurt the performance. I didn't pay much attention to that odd thing back then and it kinda slipped my mind.

Around the same crizis was working on his criziswdm3 map. He added areaportals to the doors at my suggestion, to improve performance in the YA room. While it did help indeed, the YA room was still suffering from really weird performance drops. The newly introduced r_speeds 1 counters revealed that at performance worsened considerably at higher VBO counts. The counter was fluctuating from the values of 10 to 400, depending on the view position and angle. But hey, that room is really simple, how can anything there need 400 VBO's?! I then started looking for clues and suddenly everything came into place. rgbgen lightingDiffuse. That little sucker had been initially introduced to get more or less realistic lighting and gloss on statically compiled map models like viciious statue and moving bmodels. It had been assumed that models wouldn't be split into smaller parts. But somehow the feature started to be (mis-)used by the designers for smaller details: handrails, ramps, lamps and so on. To make things even worse, all these little bits were split by q3map2 into meshes with lower polygon counts, each part requiring its own VBO.

I then hacked lightingDiffuse surfaces to be batched into vertex buffer objects and that brought performance to the levels expected. The hack broke the gloss lighting on such surfaces quite noticeably, but the performance gains were so huge that I didn't care. I mean most of the players turn the more expensive gfx features off and who really cares about glossy handrails except maybe a few guys? I then "fixed" the gloss by introducing static lighting direction in the GLSL shader.

I was planning to keep the improvement "secret" for Warsow 0.7 but crizis persuaded me into backporting it to 0.6 branch and releasing 0.62, so players wouldn't have to suffer while waiting for the next big installment of the game. And so I did!

While most of the ongoing work is happening on the 0.7 development branch, we took the time to port some of the changes and make a new point release of 0.6, fixing some of the outstanding performance issues. The autoupdate for servers will soon follow, although it won't bring any VBO fixes to clients, the later will have to download the new .exe/binary files elsewhere. Anyway, here's the 0.62 changelog:

Engine/game:
- Changed gunblade selfdamage to 100% and knockback to 78.
- Simplified rendering of 'rgbgen lightingDiffuse' shaders, which allowed to merge them into larger vertex buffer objects at load time to improve performance.
- Sped up culling of simple planar shadows to improve performance.
- Take map area visibility into account when creating vertex buffer objects for surfaces.

Bugfixes:
- Particle entities spawned too many dynamic lights with them.
- Fixed occasional disco lights on wbomb2.
- Fixed a nasty bug in q1 bsp loader that could potentially crash clients.

Download the update now!

I've been lately busy trying to optimize the engine we're currently using for Warsow - Qfusion. After months of unsuccessfull attempts at bringing its performance at least on par with our open source rivals, we've collectively decided that the next version of Warsow will use the CRX engine, the same engine that powers Alien Arena. Alien Arena devs "spent countless hours optimizing the engine to bring it to the point to where it’s one of the smoothest, fastest rendering open sourced engines in existence" and we are sure the effect of Warsow joining the CRX family will be mutually positive.
Here's a WIP screenshot of the optimized CRX engine running wdm5.

Three months have passed since 0.6 release, so it's time for a maintainance release already! 0.61 fixes bunch of bugs like lag spike when changing song, WarsowTV disconnects, mysterious crash in wdm1 and few other maps and a lot more. Also lots of small polishing, like removing stuttering/lag when clicking 'join game' in the UI.

Unfortunately this update can't be fully shipped through autoupdate as new client binaries are needed for several of these fixes.

If you have 0.6 installed, you only to need download the update zip (27 MB) and overwrite the files in your current installation.

Enjoy!

[color=#000000;]Check the changelog here![/color]