Tuesday, May 21, 2019

Is the fifty-move rule in chess the correct amount?

In chess, pretty much universally, the so-called "fifty-move rule" is applied: If at least 50 moves (ie. 100 half-moves, ie. both players have made 50 moves) have been made without a pawn move and without a capture, either player can declare the game as drawn. (In other words, applying the rule is optional.)

(If the 50th or any subsequent move is checkmate, then it takes precedence over the draw. A player cannot afterwards avoid being checkmated by retroactively trying to claim draw, if a checkmating move was allowed to be made. Curiously there have been cases of chess engines that have been incorrectly programmed to think that the 50-move draw takes precedence over the checkmate, and have lost a drawn game in this manner.)

While applying the rule is technically optional, FIDE quite recently (in 2014) introduced an additional (lesser known) rule for their tournaments that if 75 moves are made without a pawn move and without a capture, the game is drawn automatically (a referee may apply this rule if he sees this happening, and the game is ended regardless of what the players want.)

The 50-move rule might sound like a relatively recent invention, but actually it has a surprisingly long history. It was first introduced into chess by Ruy Lopez all the way back in the 1560's. While other numbers of moves were also suggested, 50 became the de facto standard quite quickly.

As you might imagine, this rule, and the exact number of moves, has been quite contentious over the centuries. After all, 50 is a completely arbitrary number that's not really based on anything. It was originally, and for many centuries, just a nice round number that's "big enough" for the vast majority of known endgames. There's really no reason why it couldn't be 45, or 60, or some other arbitrary number that's likewise "big enough".

With centuries of accumulated chess knowledge, unsurprisingly people started to eventually find endgames with forced wins that took longer than 50 moves. This felt unfair: A player could win the game, but since it took more than 50 moves (without a pawn move or a capture), he could not. Instead, the game would be declared draw, because of this rather arbitrary rule with its arbitrary number.

The rule was attempted to be patched several times. For example in 1928 FIDE amended the rule to state that if a known endgame position required more than 50 moves to a forced win, then the rule would be extended to 100 moves.

Since only a handful of endgame positions requiring more than 50 moves were known at the time, this was considered enough. However, over the decades, and especially after computers were used to analyze positions, more and more such positions were found, some requiring a lot more than 50 moves. (The current record known, as of writing this, is 545 moves to a forced win with optimal play from both players, without a pawn move or a capture.)

Since it became clearer and clearer that the number of such positions was innumerable, and the maximum amount of moves was likewise really large, FIDE decided in 2001 to restore the 50-move rule to be just 50 moves, period, for any position.

Does this rule make sense, given that there are so many positions where a game would be "incorrectly" declared a draw, even though one of the players would have a theoretical forced mate and thus victory? Does it make sense for the number of moves to be that completely arbitrary 50? (Why 50 and not some other amount?)

Rather obviously, the rule exists for practical reasons, especially in tournaments. A game cannot be allowed, for very practical reasons, to continue indefinitely. (While the three-fold repetition rule would stop certain repetitive patterns from going on forever, it's not enough to stop a game from continuing for hundreds and hundreds, perhaps even thousands of moves, without the same position ever repeating three times.) Chess tournaments have an allotted time to be organized, for practical reasons, and a single game just cannot continue for days.

One could argue that chess clocks are for that purpose. This can indeed be the case, but on the other hand, there are tournament formats where each player gets additional time for each move, so theoretically the game could continue indefinitely. (There may also be smaller tournaments, eg. for school students, that don't use clocks at all.)

If we agree that some limit has to be put on games that just don't progress in any meaningful way ("progress" being measured by irreversible moves, ie. pawn moves and captures), then 50 moves is not an unreasonable amount. It's plenty enough for like 99.99% of (pawnless) endgame positions that happen in real life practical games. Engames that are theoretical wins in more than 50 moves (without pawn moves and captures) are extraordinarily rare, especially in actual realistic games.

Given that it's impossible to even prove for most positions whether they are forced wins, and given that the vast majority of players would usually not even know how to win for certain (the likelihood that they will make a mistake and make the game an actual draw, or even a loss for them, is quite high), I think it's completely reasonable to just ignore those extraordinarily rare circumstances, and not try to apply patch after patch to the rule. Starting to list all the exceptions to the rule (which was attempted by FIDE at one point) would be an endless wild goose chase.

I think the 50-move rule makes practical sense, and the number 50 is acceptable, given how rare the exceptions are. It has more practical value than the astronomically rare games where it "wrongly" makes a won game a draw.

Friday, May 10, 2019

Sonic Forces: A surprising gem of a game

I have to admit I have never been a fan of any of the Sonic games. No, not even the first three ones. (I once got to actually try them on an actual Sega Genesis. I was not hooked in the least. Sorry, but that's just how it is.)

The Sonic franchise kept dormant for a while, but eventually new more modern games were made. The general consensus has always been that these new installments have been between mediocre and absolutely horrendous, with only maybe one or two exceptions (and even those have generally not got much praise).

A couple of years ago a new game was released: Sonic Forces. I actually saw a few reaction and "let's play" videos (although I mostly just skimmed through them), and it didn't look all that interesting to me. Perhaps the character creation was slightly interesting, but otherwise it looked like a relatively boring repetitive game.

Some time ago I had a lack of something to play on the Nintendo Switch, and a friend lent me his copy of Sonic Forces. I wasn't particularly excited about it, but decided to try it anyway, because I had nothing better to play while traveling. I was expecting (and I even expressed this to him) to perhaps play the game for half an hour, maybe an hour at most, and get bored of it.

So I started playing it... and playing it... and playing it. I played it at home in docked mode... and kept playing it. And I continued to play it the next day.

To my own surprise, I found myself playing it to the end. It's not an extraordinarily long game (less than 10 hours for a first-time playthrough), but even more to my surprise I wouldn't have actually minded if it had been a bit longer.

It was actually a pretty fun game to play. It's not the best game in existence, but believe me, I have played much, much worse games than this. It was surprisingly addictive, enticing and fun. My experience was surprisingly positive.

I'm fully of the opinion that this is an underappreciated gem. It's not a masterpiece, but it doesn't have to be. It was fun and entertaining, and may I even say cute, and that's all that matters. It might not be for everybody, but it just hit the right buttons for me, at least. I liked it.

Sunday, July 8, 2018

Which to buy for gaming, a TV or a monitor?

Nowadays, to the average consumer there seems to be little to no difference between a TV and a computer display monitor. They look the same, they use the same technologies, they use the same resolutions and refresh rates, they have HDMI input... The only difference seems to be physical size. When computer display monitors, even 4k ones, have typical diagonal sizes of about 24-32 inches, TVs tend to have diagonal sizes of 40, 50 and even more inches.

If you are purchasing a new display primarily for gaming, even (or especially) if it's console gaming, which kind of display should you purchase? After all, a huge 50-inch 4k TV sounds enormously cooler for gaming, especially for console gaming, than some tiny 27-inch 4k display. And with the prices of both types of display coming down by the month, the TVs aren't necessarily even any more expensive than the computer displays. (Indeed, you can already find both decent 4k TVs and decent 4k monitors in the ballpark of 500€, sometimes even less.)

So what is the difference between these two types of display, besides physical size? Does it make any difference?

There indeed is one relatively crucial difference. And it's something that TVs very rarely advertise in their technical specifications: Response time.

Response time is the average time that it takes for a pixel to change its color.

With computer monitors, modern TN panels have extraordinarily fast response times, down to 1 millisecond, sometimes even less. On the other hand TN panels have horrible viewing angles, especially vertically. IPS and VA/AMVA panels (which are becoming more and more commonplace, also with TVs) have significantly better viewing angles, and their response time is typically 4 milliseconds, sometimes less (and sometimes more, depending on how cheap the display is).

TVs, on the other hand, have typical response times in the 10-12 millisecond range. That's almost four times the response time of a modern IPS computer display.

The side-effect of a slower pixel response time is ghosting. The pixels are simply slow to change colors, and thus moving details leave a faint "trace" behind. With 10ms it's really subtle, and especially with lower framerates (such as 30 fps, which is your typical movie framerate) it's almost unnoticeable. However, with higher framerates, like 60 and above, and very fast-paced movement it can become visible.

With a 4 ms response time ghosting is essentially unnoticeable (unless you go much higher than 60 fps, which most IPS panels do not yet support). With a TN panel with 1 ms response time there's quite literally no ghosting, even if you go to extremely high framerates, such as 144 Hz.

There may be another drawback in using a TV for gaming: Latency.

Most TVs post-process the image they receive in various ways, and this post-processing may introduce a delay in displaying the picture. This delay may range from 1 to half a dozen frames. The longer this delay is, the more laggy and slow to respond the game will feel.

Some/many TVs will offer a so-called "game mode", which will make it eschew using any post-processing and display the image as quickly as possible. This may fix the latency (or reduce it significantly, eg. to just 1 frame) and should always be used when playing a video game.

Needless to say, computer displays do not have this kind of latency (other than the minimum amount introduced by vsync, but this is not the fault of the display per se.)

Thursday, May 31, 2018

The role of the graphics card driver in real-time rendering

Common computer wisdom accentuates the importance of having the graphics card driver for your computer always up to date. Updates to this driver can fix bugs and misbehavior in games, and sometimes even make games run faster.

However, have you ever wondered why that is, especially in the case of the latter? Shouldn't it be the graphics card itself (in addition to your other hardware) that solely determines how fast a game runs? Why does the graphics card driver sometimes have such a great impact on the rendering speed of a video game? What role does it play in the whole process, and why is it so crucial?

On a more fundamental level, what exactly does a graphics card driver do?

(Note that the explanation below is a simplification, perhaps even an oversimplification. But it is so for the sake of brevity and clarity, even if it might not be technically 100% accurate in every single detail.)

Most typically, a program like a video game uses a graphical application program interface definition like DirectX, OpenGL, or Vulkan. These are not program libraries per se, but rather they are API specifications. In essence, what this means that the program will have code to make certain system function calls for different types of tasks related to rendering, such as loading a bunch of vertices into the graphics card memory, or compiling a fragment shader.

The implementations of these functions will be provided either by the running operating system (eg. Windows), or the graphics driver. Essentially, what's happening eg. in the case of DirectX, is this:


The program executable binary will have metadata that tells to the operating system "I need to call these system functions from these locations within myself". When the operating system loads the binary in order to be run, it modifies it in order to redirect those calls to the appropriate system implementation.

If the graphics card driver provides an implementation for a specific function, it will direct the program binary to call that. In some cases the implementation is not in the driver, and thus a kind of default implementation is provided by the DirectX runtime, which the operating system is running. (Sometimes if a graphics driver doesn't provide an implementation for something, the DirectX runtime essentially needs to emulate that feature. This is why there needs to be a DirectX library in the system at all.) With some implementations the DirectX implementation may call the implementation in the graphics driver.

So it ends up like this:


For most functions, the graphics driver needs to provide an implementation because only it knows how exactly to interact with the graphics card hardware, and what kind of data it needs.

For example, the graphics card driver has a compiler implementation that compiles vertex and fragment shaders into the machine code that the graphics card uses.

In the case of DirectX and Vulkan (and some other APIs, like Metal), the original shader source code is compiled into a hardware-independent intermediate bytecode form, when the program binary itself is being built. At runtime this intermediate form is sent to the graphics driver, which produces from it the actual machine code used by the graphics card.

In the case of OpenGL, and its shading language (glsl), OpenGL doesn't specify any such intermediate form, and the graphics card driver literally has a compiler implementation that takes the original glsl source code in textual form and compiles it into machine code.

This explains why the graphics card driver has such an important role in the entire process, and also why it has such a big impact in the performance of games. Oftentimes graphics card manufacturers will publish an updated driver that's specifically optimized for a particular new video game, and will make it run measurably faster (eg. several frames per second faster than with the old driver).

How? What they do is that they examine what kind of calls the game is doing, and with what kind of data. For example, they may notice that the game is doing a lot of calls with certain data in a certain way, and that if the graphics driver reorganizes that data in a certain manner, it makes it more efficient for the graphics card hardware to handle (without changing the behavior).

Likewise they may notice that the game uses certain types of shader code quite a lot and heavily, and may notice that the shader compiler can optimize that code to shave off a few clock cycles (again without changing its behavior), which may end up speeding up the overall rendering by several frames per second.

Tuesday, May 15, 2018

How many times can the same position repeat in chess?

Most official chess tournaments have a so-called "three-fold repetition" rule, which in short means that if the same board position is repeated three times, the game can be declared as draw. (In human tournaments declaring it as draw is optional and up to the players, even though many tournaments have an additional rule that says that if the same position repeats five times, the tournament referee can declare it a draw. In computer chess tournaments three-fold repetition is invariably declared a draw automatically.)

So the answer appears to be pretty obvious: Three times, duh.

Except it's actually not that simple. You see, there are additional rules with respect to what is considered the "same board position". Even though all the pieces might be on the exact same squares as in a previous position, for the purposes of this rule it might not be considered the "same position".

For starters, castling rights are taken into consideration when defining whether a position is the same as a previous one. Even if all the pieces are on the same squares as before, if however now one of the players has lost the castling right to either side, which he had in that previous position, it will be considered a different position.

So, how many times can the same arrangement of pieces repeat in this light? (We don't need to worry about how realistic in actual games this is. We are just pondering what the theoretical absolute maximum is.)

So, this is theoretically possible: Both players have castling rights to both sides. The same position repeats twice. Then one of the players loses one of these castling rights, after which the same position repeats an additional two times. And so on with the remaining three castling rights. Then, after the last one, the position can repeat a third time, and it will be draw.

So 2 initial times + 2 for each lost castling right (ie. times 4) + 1 final time = 11 times?

Nope! There are more conditions we haven't touched! You see, the rule also states that it has to be the same player to play, in order for it to be considered the "same" position, in the context of this rule.

Thus, we can actually repeat each of the above positions twice, except for the very last one, as long as it's the other player's turn each second time. (The last one can't be repeated with the other player having the turn, because the last one already makes it a draw immediately.)

Thus 21 times?

Still no! There's still one additional rule: Having en-passant right vs. not having it is considered yet another aspect that makes the position different.

How many times can we repeat the same position with en-passant? Only once. This is because this condition requires a pawn move, and can't be repeated with all pieces ending up on the same squares. Thus we have to start the whole sequence with having a player have en-passant right, after which it's lost, and we can proceed with the rest of the sequence above.

So the final answer is 22 times.

Wednesday, May 2, 2018

Indirect protection in chess

Consider the following position:


Black has just played the bishop from f5 to c2, attacking the a4 pawn.

Seemingly there is no way to protect that pawn. It's gone, and we simply have to accept this loss, which is rather significant in this part of the game, with this few pieces left. A pawn advantage at this stage is extremely important, but we just lost it.

Or did we?

There is a way to protect the pawn from being captured, but it's a rather sneaky indirect way of protection. Play the knight to b7!


How does this protect the pawn? The knight isn't directly protecting it. However, it is protecting it indirectly. If the bishop were to now capture the a4 pawn, we can fork the king and the bishop, and gain the bishop:


The a4 pawn cannot be captured. We could later protect the pawn directly by moving the knight to c5, but as long as the black king remains at d7, there is no hurry. If black moves something else, we can afford to likewise do something else. If the black king moves anywhere, we can then play the knight to c5, safely protecting the a4 pawn directly.

This is one of the tactical aspects of chess that can be difficult for many beginners to see and learn to read.

Thursday, January 18, 2018

The en passant rule causes problems to beginners

Some time around the 15th century, a new rule was added to chess: A pawn in its initial position (ie. 2nd rank if white, 7th rank if black) can advance one or two squares. Previously it could only advance one square. This change was made to allow a game to develop faster.

This new rule added one negative side-effect, though: It allows a white pawn to evade capture by an black pawn that's on the 4th rank, in an adjacent file (and vice-versa with a black pawn evading capture by a white pawn on the 5th rank), by advancing two squares. In order to combat this, an additional rule was added: The so-called en passant rule. In this situation, during the next move the pawn on the 4th rank (5th if reversed situation) is allowed to capture that pawn that just advanced as if it had advanced only one square. (This is the only situation in chess where capturing doesn't put the capturing piece on the same square as the captured one.)

The en passant rule feels a bit of a kludge, or a rule patch. It introduces a type of capture that's completely unique, and unlike any other capture in the game. It also is unusual in that the option to make this capture is only temporary, which is also quite unique, and unlike any of the other rules of the game (with castling rights being the only other rule that somewhat resembles this.) The fact that it was introduced to "fix" a problem in another recently-introduced rule makes it feel even more of a kludge.

It's also a relatively obscure rule for beginners. A surprising amount of beginner players have actually never heard of this rule, nor know of its existence. If somebody makes the move against them, they will often call foul, and even accuse the other player of cheating. If they are playing against a computer, and the computer makes the move, they often think that it's a bug in the program (or that the program is cheating somehow).

Sometimes even after they have been explained the rule, some such players keep feeling like it's somehow "cheating", or "unfair", or doesn't make much sense. I once read a comment by someone who seriously thought that this rule wasn't actually part of "normal" chess, that nobody actually uses it, and that computers using it is just semi-cheating, and that computer games should have an option to turn the rule off, like in "real" games of chess. (Apparently this guy had always played chess with people who agreed that the rule shouldn't be used, and got somehow the impression that it's so everywhere with everybody, or at least most people.)

The en passant rule, however, adds a surprising amount of tactical depth to the game. It doesn't happen very often, but when it does, it can be quite powerful. Just the threat of en passant capture can affect the tactics of the situation significantly (even if the capture itself never actualizes). The people who originally came up with the rule in the 15th century might not have been aware of how tactically deep the rule is, and thus it might be serendipitous, but it really adds a lot to the game.

Just having a pawn on the 5th rank (or 4th if playing black), if well protected, and depending on the situation, can be a great asset, precisely because it might be stopping both opponent pawns in the adjacent files from advancing.

One of my own games had this kind of situation (I'm not especially strong, just about 1450 elo on chess.com, but I still like this situation as illustrative):


That pawn on e5 had been a thorn in my opponent's side for the majority of the game, hindering the advancement of the d-pawn. This position is still relatively even, even though I'm now sure to capture the d-pawn. My opponent, perhaps because of time pressure or just weakness, tried desperately to save it, and advanced it two squares, no doubt hoping that I didn't know about en passant, or didn't notice the possibility.


Of course I did notice. Advancing the d-pawn is a bad mistake, and I proceeded to easily win the game with my two connected passed pawns.