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.)
Sunday, July 8, 2018
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.
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.
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.
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.
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.
Subscribe to:
Posts (Atom)