Friday, June 27, 2014

Screen tearing vs. stuttering

Currently there are two options to play video games: Use vsync, which causes frame rate stuttering if the game renders more slowly than the monitor's refresh rate, or not use vsync, which causes image tearing (unless the game can render at exactly the same framerate as the monitor's refresh rate; which is practically impossible without vsync.)

Frame stuttering happens when the game is constantly jumping between eg. 60Hz and 30Hz frame rate, due to the game actually rendering at something in-between those two, and syncing with the monitor's 60Hz refresh rate. Same thing happens, but even worse, if the rendering speed drops below 30Hz. On the other hand, frame tearing causes annoying horizontal artifacts when the image updates while the screen is refreshing. The position of the tear tends to jump randomly on the screen on each refresh, worsening the effect. (And if the game is actually rendering faster than the monitor's refresh rate, you'll get multiple tears on each refresh.)

The absolutely optimal situation would be, of course, if the game can render at least as fast as the monitor's refresh rate (usually 60Hz nowadays) and you use vsync. This way you get neither problem and the game is smooth and without tearing artifacts. However, this is hard to achieve with modern resource-intensive games, at least if you want to bump up the rendering quality. (Or, alternatively, even with older games if your computer is too slow.)

An even better solution to this problem is coming in the near future, with newer monitors. The idea is that rather than the graphics card having to sync with the monitor, the dependency is reversed. In other words, the monitor syncs with the graphics card. This way the monitor will display each frame immediately when it's ready (regardless of how long it took for the graphics card to render it), and thus you never get screen tearing, and the frame stuttering is minimized (basically being solely up to how fast the graphics card can render the image.) In other words, it will be exactly like playing with vsync turned off, but without the screen tearing. However, we are not still there.

What puzzles me, however, is most people's perception and attitude towards the stuttering vs. tearing dilemma.

Personally, I have hard time even noticing frame stuttering. If I look really closely, I can see it, but if I'm not paying attention then I don't even notice it. Even when I do notice it, it doesn't bother me almost at all, for some reason. Screen tearing, however, annoys me a lot. I just can't stand it. (This is true both in games and movies, if the media player happens to not vsync for some reason.) It annoys me so much that I have hard time playing a game that has no vsync option (fortunately this is very rare.)

However, if you search on the internet, the majority view seems to be the exact opposite: Screen tearing doesn't seem to bother almost anybody, while frame stuttering annoys the hell out of people. (Some people even write comments along the lines of "why do games even offer vsync anymore? It makes games run like crap. Who cares about tearing, it doesn't bother me.")

I don't really understand why I seem to be in a minority with this. I actually have hard time telling if the game is frame-stuttering, but tearing is so glaringly obvious that it's irking to a level that makes it difficult to play such a game.

There also exists a third option, a technique that can alleviate (if not even completely remove) stuttering (even without support for g-sync or the like): Triple buffering.

This technique is most useful if the game runs on average around 60 FPS, maybe a bit higher, but may regularly drop below that critical line from time to time. In basic vsync mode this means that the framerate will likewise regularly drop to 30 FPS, while at times it's at 60 FPS. This may introduce visible stuttering that's exacerbated by the fact that it's intermittent rather than constant.

If the average framerate is slightly over 60 FPS, and the variance in framerates is not enormous from frame to frame, however, triple buffering can get rid of the stuttering completely and make the game run at a constant 60 FPS. It's a simple trick, but can work like magic.

In essence what triple-buffering does is that rather than showing frames immediately when they have been rendered, the game has a "queue" of three frames: The one being currently shown on screen, the next frame (which usually has already been fully rendered), and a third frame being currently rendered. The game waits for vsync and starts showing that second frame, and rendering a new third frame at the end of the "queue".

What this does is that if the rendering temporarily drops below 60 FPS, the display has been given a bit of "leeway" in that it still has a full frame to show, while the game is now rendering the next frame. In other words, essentially, if the rendering speed drops slightly below 60 FPS, the "queue" will now be reduced to just two frames, but that's still enough to maintain 60 FPS as long as the display doesn't "catch up" with the renderer. The 60 FPS display can still be maintained for a time before this happens. As long as the rendering can go back to over 60 FPS soon enough, the rendering rate will be uninterrupted. (If the rendering drops just slightly below 60 FPS, eg. 55 FPS, this can actually keep going on for several seconds before the display catches up with the renderer.) If the rendering goes back to over 60 FPS, the renderer can now start "filling up" the queue once again, and get ahead of the display once again.

This is not just theoretical or extremely niche. It actually works, and it works beautifully. (Of course the game has to support this.)

The downside of this technique is that it introduces a latency of two frames between the input and its effects on screen. However, for normal players this is practically unnoticeable (only pro FPS players and other HC players of their caliber will notice the latency).

Thursday, June 26, 2014

"Get a real job"

Nowadays video sharing sites such as YouTube and have become so big that many people can actually make a living off of the ad revenue of their videos. This is a rather new form of entrepreneurship that was basically impossible in the past. (The closest thing decades ago was to have such a great idea and be so talented and extremely lucky, that you got your own TV show at some TV broadcasting company, but this was exceedingly rare.)

Oftentimes these people will sell merchandise in their videos (eg. books or other stuff), or simply outright ask for support (eg. through Patreon), in order to be able to keep doing the videos. Almost invariably you will see a ton of "get a real job" comments.

This is amazingly annoying to me. (No, I'm not a video producer and this hasn't happened to me. The sheer stupidity of those comments is what annoys me.)

What exactly is this mythical "real job" that these people are talking about? How is an online content producer (most often an entertainer) not a "real job".

Are actors not in a "real job"? How about writers? Directors? Comedians? TV hosts? Are they not in "real jobs"? How do you define "real job" in a manner that includes those but excludes online video content producers?

Is the idea that if you get money directly from your viewers or customers, you are not in a "real job"? Is a "real job" something where the money goes from clients to the worker through a corporation, rather than directly? If you are an actor working for a movie company you are in a "real job", but if you produce and publish the videos yourself, and get your revenue directly, you are not?

In other words, do you need to work for a company, instead of being an independent entrepreneur, in order to have a "real job"?

How does that make any sense? And if it doesn't, then how exactly do you define "real job" in a manner that includes everything else except people making YouTube videos for a living? What is this mythological "real job"? I can't understand.

The people making those comments are the epitome of sheer stupidity.

Wednesday, June 18, 2014

The downside of game engines like Unity

One of the biggest problems in creating a modern computer game is writing the game engine. You may have the best ideas in the world, and the talent to implement them, but if you don't have a game engine you don't have anything. For this reason many companies have developed game engines that they are licensing to developers to ease the menial low-level tasks, allowing them to concentrate on what actually matters, ie. the content. Examples of such game engines include the Unreal Engine, id Tech, CryEngine and Unity.

Especially Unity, with its accompanying IDE, has been designed from the ground up to make it as easy as possible to create 3D (and nowadays also 2D) games. There are wonderful demonstration videos out there where a developer creates a small but decent first-person shooter from scratch (although using some ready-made geometry assets) in something like 5 or 10 minutes.

While this is great, there is, however, a dark side to all this. In a somewhat ironic way, this actually makes it too easy for people to make 3D games, as contradictory as that might sound.

Or rather, it makes it too easy for people to make "games" that might look somewhat decent in screenshots and carefully-crafted trailer videos, but which are actually complete and utter crap that nobody would play even if they were free.

Don't get me wrong, there's nothing wrong in making and distributing these kind of test projects for free. The problem arises when they start selling them for money on distribution platforms like Steam, masquerading them as actual games, for a quick buck.

Valve used to have very strict quality controls on what could and couldn't be distributed through Steam. This caused lots of complaints because many great games couldn't be sold on Steam just because Valve didn't approve them (perhaps due to lack of time, resources, willingness, or other reasons.) To remedy this problem they implemented the "greenlight" system where users could vote for indie games to be published on Steam. Initially Valve still imposed some quality control on what could and couldn't be published even here, but they have basically completely stopped and just automatically allow publication of whatever gets enough votes.

And thus we get complete non-games that are nothing more than test levels made by some beginner Unity user with zero talent, such as "Air Control".

No, it's not a game in any sense of the word, it's in no way fun to play, its quality is completely abysmal, it's full of bugs, and it has zero redeeming qualities. This is just something that a first-time Unity user could come up with to learn to use the platform, to see how the IDE works.

And it's being sold at 6€.

The unfortunate people who are fooled to pay 6€ for this will get nothing more than a few test levels that are complete crap. (And that's if they are lucky enough that the levels will even load properly.)

IDEs like Unity make it easier to make great games, but it also makes it too easy to sell complete crap and fool people into spending money on garbage that has no playable content whatsoever.

Firefox versioning number, take 2

I have complained about this in a past blog post, but man...

Firefox 30.0 just came out and... well, nothing really. The version number has become completely meaningless with this software. Not only does it not tell if this is a major, a minor or a bugfix release, this time the "what's new" page that it loads the first time doesn't even tell what's actually new (at least not clearly.)

This has reached a point where even they themselves don't care much about what has really changed. Or at least they don't care much about telling you. This is completely ridiculous.

It really doesn't make any difference at all whether this is Firefox 30 or Firefox 154. The number means absolutely nothing.

This is rather unique among popular software that has version numbering (or an equivalent naming scheme). For example with most programming language compilers the version number is quite a big deal (especially if it's a major version increment.) The same is true for operating systems, office software suites etc. Especially it's true for other web browsers. With Firefox, however, the version number has lost all meaning.

Why do they do this? It makes no sense.

Tuesday, June 17, 2014

A big reason why conspiracy theorists are assholes

I was watching a Moon hoax conspiracy theory video on YouTube, just for amusement, and because I hadn't watched any in a long time (I have watched quite a lot of them in the past, as well as related websites), and one of the comments to the video made me realize something. The comment was something along the lines of "my childhood is destroyed". My realization was: This is one of the reasons why conspiracy theorists are assholes.

The space program is one of the great achievements of humanity, a marvelous show of technology, progress and human courage, of people willing to go beyond, to surpass all previous limits. The Moon landings are among the greatest achievements of our entire history, and something that we can marvel and admire.

Then the conspiracy theorists come, confuse you and fill your head with all kinds of lies, misleading you into believing falsities. They use all the dirty tactics in the book to mislead you, and are preying on your gullibility and lack of experience on the subject. No matter what they claim, conspiracy theorists couldn't care less about what's true and what's not; the only thing they care is feeding their own desires to be "knowledgeable" and "in the loop", to know all the "secrets" that only very few other people know, and they don't really care if they have to fabricate non-existent "secrets" to fulfill this goal. Many conspiracy theorists might have fooled themselves into believing that they are only seeking the truth, but they are only deluding themselves; they are not seeking the truth, they are only trying to confirm what the want to be true, and they do this by distorting evidence, fabricating evidence, ignoring evidence, all with copious amounts of confirmation bias. They also feel the need to sell these lies to others in order to gain some personal satisfaction at being "smarter" than the average person (even if they would never admit this even to themselves.)

The sad side effect of this is destroyed admiration and awe, and unjustified disillusionment for the people who fall prey to the lies of the conspiracy theorist. As that commenter said, childhood dreams are destroyed. But it's not NASA or any government that's destroying them, it's the lying assholes that are conspiracy theorists.

Monday, June 16, 2014

Jurassic Park: Trespasser

(This is not something that annoys me, but this is my main blog, so... Since I keep doing this, I think I'll have to rename this blog some day.)

I find the computer game Jurassic Park: Trespasser a very interesting case because of its history.

The development of this game started approximately in 1995. This game was intended (and in a few ways resulted to be) way ahead of its time, with innovations and game mechanics that people only could have dreamed of previously.

At that time 3D games were in their infancy. Doom-like games were the trend (Quake hadn't yet been published), and perhaps the most advanced 3D game of the time was Descent, which was extremely innovative (and in itself ahead of its time), as it was one of the first games that allowed complete freedom of movement and orientation (and had other quite advanced features considering the era it was published, such as surprisingly good enemy AI). However, Descent limited the gameplay into extremely narrow corridors inside relatively small levels.

The creators of Jurassic Park: Trespasser, however, had a really ambitious (and in hindsight very unrealistic) goal: What if they made a game that was hyper-realistic? Enormous open levels that could be traversed (almost) freely, depicting natural terrain (an entire island), with everything simulated with a realistic physics simulator, which would allow for the player to do almost anything that the player wanted, with little to no limitation?

Want to go explore that hill over there? Go right ahead. Want to take a rock and throw it at some boxes, knocking them over? Want to take an object, any object, like a stick or a chair, and hit something with it, knocking it over? Heck, want to take a stick and hit yourself with it? Want to take a gun and shoot whatever you want, such as cans, boxes, windows, dinosaurs, or even yourself? Be my guest. The game would allow you to do virtually anything you wanted. It would be like a real-life simulator, located on an isolated island full of dinosaurs.

If you go into water, ripples would be created realistically depending on what you do. Wading in water, throwing objects into the water, hitting the water with an object... all would create realistic ripples accordingly. Sounds would be extremely realistic; for instance, hitting a wooden box with a metal bar would produce a different sound than hitting it with a wooden stick, or hitting a metal box with either object. All sounds would be dynamically mixed depending on the materials of the colliding objects.

The dinosaur AI was also planned to be unprecedented, with the dinosaurs behaving differently depending on the situation, with them having "moods" and so on. (For example a predator dinosaur could have just eaten and thus not care at all about the player, but if the player annoyed it, it could get angry. They could get distracted by other events, such as other dinosaurs, etc.)

Moreover, dinosaurs would move realistically according to the situation and the terrain. They would not simply follow some scripted walking and running animations, but instead they would use full inverse kinematics, thus their body movements dynamically adapting to every possible situation.

There would be no HUD, no crosshair, no life bar, no info at all on screen, just the raw view of what's in front of the player and that's it. As said, like a "real-life simulator".

Nowadays we take wide-open-sandbox games with full-fledged physics engines for granted (and doing a game like described above would be completely possible today, and most modern open-sandbox games in fact are pretty much like that, except usually for the shooting-yourself part), but in the mid-90's this was completely unprecedented and almost unthinkable.

And that was one of the biggest problem that the project faced: The project was indeed pretty unthinkable and unrealistic. The hardware of the mid-90's was not even nearly efficient enough to implement all that was planned (there wasn't even hardware-accelerated 3D graphics yet when the project started), and nobody had ever made a game engine for this kind of game. Nowadays you can get ready-made game engines for almost any type of game, as well as "middle-ware" libraries for almost any type of task required by a game (such as physics simulation), but that was not the case back then. There was no software for what they wanted to do.

They had to implement everything from scratch, and to their credit they created a pretty decent piece of software given the limited time and resources, and poor management, that they had. The game was, in fact, one of the first open-sandbox games in existence, with absolutely enormous levels, way way bigger and more detailed than anything else that had been created back then. (Nowadays it doesn't look very impressive at all because we have been spoiled with open sandbox games that are a million times better, thanks to our supercomputer PC's, but you have to remember that this was the mid-90's, when a non-hardware-accelerated Quake was approximately the best game that existed so far.) Also their physics engine, while full of imperfections, was still way ahead of its time and pretty decently implemented, and something that nobody else had ever tried to cram into a 3D computer game before (at least not anything that advanced.)

I think it's a real pity that their goal was so unrealistic, and because of that the project failed to achieve most of its planned goals, and even what it did achieve was severely lacking. Neither the hardware nor the software was ready for a project of this magnitude. Today this very project, with all of it's original goals, would be perfectly well doable, but this was basically impossible in the mid-90's.

The game was extremely resource-demanding, and even the top-of-the-line gaming PC's of the time had difficult time achieving decent framerates. This is understandable for a game that tried to draw entire landscapes with huge draw distances, but unfortunately if it makes the game lag so much that it becomes almost unplayable, the pretty pictures aren't of much help.

But that was only a minor problem compared to everything else that was wrong with the game. Because of the lack of time and resources they had to cut a lot of features and nerf others. Many features that were kind-of supported by the game engine had to be "locked in" into a fixed setting because it wasn't working otherwise (for example most carried object had to be made weightless because there were still problems with them, and bugs in the dinosaur AI forced them to just fix their "mood" to being fully "angry" all the time, basically cutting that part of the AI completely from the game.)

The dinosaur animations and movements looked stiff and awkward. The planned fully dynamic inverse-kinematics-based body movements didn't realize itself as planned (probably again due to lack of development and fine-tuning time), and the end result looks a lot worse than if they had just gone with the fixed body animations.

While the physics engine was very decent for the time, it still had a lot of problems, and it was left unpolished, and they had to build many kludges around it (such as not allowing dinosaurs to enter buildings, because of bugs in the physics engine.) Sometimes objects move in unrealistic ways, and they often clip through the ground. (Also the physics engine is quite limited in the sense that it can handle only box-shaped objects. This means that all physics objects have a box-shaped hitbox around them.)

The original plan was for the player to be able to manipulate objects with both hands, but this had to be cut to one hand, again because of lack of time and resources. And unfortunately the one-hand handling of objects had to in itself be left unpolished, making it look quite awkward and ridiculous.

As said, I really think it's a pity that they couldn't realize their dream project, and the result of this was a game that felt extremely sub-par, if not even outright bad. But I must give kudos to them for achieving a lot that was thought impossible for the time. (Also, not everything in the game is bad. The story and the voice acting are pretty decent.)

Nowadays, with modern hardware and software, the project is perfectly well doable, and I really wish they would make a remake of the game. If well done, I think it would be fantastic. (There is a fan project that's trying to do exactly this, but it's a one-man project, which in itself sounds to me like a rather unrealistic goal given the size of it. Perhaps in some ironic way fittingly...)

Tuesday, June 3, 2014

Dialog trees in games

Dialog trees are a staple of many adventure games (especially point&click games) and role-playing games, and sometimes they appear in other genres as well.

Most typically a dialog tree is used when the player talks to a non-playable character in the game: Typically a list of sentences will be shown for the player to choose, and the NPC will then respond to it. Especially if there may then be further options based on what you chose (and sometimes based on what the NPC responded), it makes it an actual "tree" (because the conversation path can branch to different directions depending on which option you chose.)

I don't know if and what these may be named, but I would divide such dialog trees broadly into three categories: Trivial exclusive trees, subtler exclusive trees, and fully inclusive trees.

An "exclusive" dialog tree is one where you have to make a choice and it will be "locked in". You can't go back and change it. The other branches will usually be "lost forever" in practice. Typically such choice will have an effect on further events.

A "trivial" exclusive tree is one that's almost stereotypically two-sided, of the type:

NPC: "What should we do with the children in that burning house?"
  1. "Let's go save them!"
  2. "Let them burn! HAHAHAA!"
Often this is done in games where there's some kind of "good karma / bad karma" meter, and which are not very subtle about it.

A much subtler exclusive tree is one where there are more options, most or all of them being morally ambiguous (or overall ambiguous and unclear in how they will affect subsequent events.)

A "fully inclusive tree" is one that has little to no consequence to the subsequent events, and which you are allowed to traverse through. Typically no branch of the tree will ever be "lost forever". (Often these dialog trees are very shallow, consisting mostly or even solely of "sentence choice" - "NPC response" pairs, with no further branches from there, with few exceptions.)

The inclusive trees often feel rather pointless. Most often they are even clearly designed to be traversed in the listed order. You could traverse all the options in some other order but it's usually pointless and, moreover, in some cases it may even result in an unnatural-sounding conversation (because the conversation does not follow a logical progression). They don't seem to play any kind of important gameplay role at all.

Exclusive trees, especially the subtler ones, are supposed to make the game experience more profound, with conversation choices having non-trivial consequences that may be hard to predict (just like in real life.) Doing this naturally is hard to pull off and only few games have any kind of success in this. However, the major problem with them is that they often leave the player wondering what would have happened if they had chosen something else. The "lost forever" nature of this kind of dialog tree can in itself be annoying because the player cannot experience everything that the game has to offer, as the game locks some paths out. (This is supposed to give the game replayability value, but not all gamers want to play the same game through more than once.)

One has to wonder why games still have such dialog trees. Some feel rather pointless, others lock the player out of branching events. Only few games succeed in implementing it in such a manner that it avoids both problems.