It's hard to argue that the landscape is an integral part of most computer games in open spaces. The traditional method of realizing the change in the relief of the surrounding surface player is the following - take the mesh, which is a plane and for each primitive in this grid, we make a displacement along the normal to this plane by a value specific for this primitive. In simple words, we have a single-channel texture of 256 by 256 pixels and a grid plane. For each primitive from its coordinates on the plane, we take the value from the texture. Now we simply move the coordinates of the primitive along the normal to the plane by the resulting value (Fig. 1)


Pic.1 map of heights + plane = terrain

Why does this work? If we imagine that the player is on the surface of a sphere, and the radius of this sphere is extremely large in relation to the size of the player, then the curvature of the surface can be neglected and a plane can be used. But what if we do not neglect the fact that we are on the sphere? I would like to share my experience of constructing such landscapes with the reader in this article.

On November 23, 2011 id Software supported its own tradition and published the source code of its previous engine.

This time, it's time idTech4 , which was used in Prey, in Quake 4 and, of course, in Doom 3. In just a few hours more than 400 forks of the repository on GitHub were created, people began to explore the internal mechanisms of the game or port it to other platforms. I also decided to participate and created a Intel version for Mac OS X , which John Carmack kindly advertised .

From the point of view of cleanliness and comments, this is the best release of the id Software code since the code base Doom iPhone (which was released later, and therefore commented better). I highly recommend that everyone learn this engine, collect it and experiment.

Here are my notes about what I understood. As usual, I cleaned them, I hope they save someone a couple of hours and encourage someone to study the code to improve their programming skills.

The meeting of the ISO WG21 C ++ Committee, which was held in Toronto from 10 to 15 July, ended today. Soon we will surely be waiting for detailed report from WP21 , and today the respected public is offered a post- "Warming up" with a discussion of the most interesting.

The results of the meeting are as follows: C ++ standard 17 is completed and will be published at the next meeting in November this year; the standard C ++ 20 has already acquired the first serious features - concepts ( concepts ), explicit generic lambda functions (explicit explicit lambdas < / i>) - and this is just the beginning.

The possibilities of the new C ++ standard 17 have been discussed more than once, about innovations written on Habr , conducted reports at conferences , so I will not bring them here again. It's no secret that the key feature of this release of C ++ was carrying the most "delicious" options into an uncertain future. Well, now we can say with certainty that many of the long-awaited "features" have moved to C ++ 20. The course taken for the stdlib extension has not gone away, so a much larger and rich set of functions can be expected from C ++ 20.

Nowadays a lot of projects are opening their source code and letting those who are interested in the development of it edit the code. OpenJDK is no exception, programmers PVS-Studio have found a lot of interesting errors that are worth paying attention to.

OpenJDK (Open Java Development Kit) - a project for the creation and implementation of Java (Java SE) platform, which is now free and open source. The project was started in 2006, by the Sun company. The project uses multiple languages- C, C++, and Java. We are interested in the source code written in C and C++. Let's take the 9th version of OpenJDK. The code of this implementation of Java platform is available at the Mercurial repository.

During verification, the analyzer found different errors in the project including: copy-paste, bugs in the operation precedence, errors in logical expressions and in pointer handling and other bugs, which are described in detail in this article.

It's always amusing to check a project which is used and maintained by a large number of people. The better and more accurate the code is, the more safely and effectively the program will work. Those bugs we found, are another proof of the usefulness of an analyzer, as it allows the detection of such errors which would otherwise be hard to detect doing simple code review.

CppCat is a static code analyzer integrating into the Visual Studio 2010-2013 environment. The analyzer is designed for regular use and allows detecting a large number of various errors and typos in programs written in C and C++. For the purpose of popularizing it, we've decided to launch a student-support program granting free licenses to every higher school student who will contact and ask us about that. You just need to send us a photo of your student card or transcript.

The authors of the PVS-Studio analyzer invite you to test your attentiveness.

Code analyzers never get tired and can find errors a human's eye cannot easily notice. We have picked a few code fragments with errors revealed by PVS-Studio, all the fragments taken from well-known open-source projects.

We invite you to take part in a competition against code analyzers to test your agility by trying to find the errors by yourself. You will be offered 15 randomly selected tasks. Every correct answer earns you one score if you give it within 60 seconds. The code fragments are short and 60 seconds is a fair limit.

Let's examine a couple of examples with errors for you to understand how to give the answer.

It is common practice not to like Windows. But, as a rule, phrase: “I haven't read the book but still condemn it” describes this situation well. Despite the tendency of not like Windows, there are still some things that are implemented well. I’d like to tell you about one of them.

I’ll review the embedded into OS implementation of the lock-free stack and its performance comparison with the cross-platform analogues.

The implementation of non-blocking stack on the basis of a singly linked list (Interlocked Singly Linked Lists, SList), has been available in WinAPI for quite a while. Operations on such list initializing and stack primitives over it have been implemented. Without going into details of implementing the SLists, the Microsoft just say that they use some non-blocking algorithm in order to implement atomic synchronization, increase performance and get rid of lock problems.

I'm currently experiencing a strong cognitive dissonance, and it won't let me go. You see, I visit various programmers' forums and see topics where people discuss noble ideas about how to write super-reliable classes; somebody tells he has his project built with the switches -Wall -Wextra -pedantic -Weffc++, and so on. But, God, where are all these scientific and technological achievements? Why do I come across most silly mistakes again and again? Perhaps something is wrong with me?

Some of our users run static analysis only occasionally. They find new errors in their code and, feeling glad about this, willingly renew PVS-Studio licenses. I should feel glad too, shouldn't I? But I feel sad - because you get only 10-20% of the tool's efficiency when using it in such a way, while you could obtain at least 80-90% if you used it otherwise. In this post I will tell you about the most common mistake among users of static code analysis tools.

We thought of checking the Boost library long ago but were not sure if we would collect enough results to write an article. However, the wish remained. We tried to do that twice but gave up each time because we didn't know how to replace a compiler call with a PVS-Studio.exe call. Now we've got us new arms, and the third attempt has been successful. So, are there any bugs to be found in Boost?