Probably everybody who has written C++03 code had the pleasure of using
NULL and stumbling over one pitfall or another. C++11 brought the solution to those issues with
In this series we will be creating a fun top-down shooter style game using C# in the Unity engine.
The series is quite fast paced, and aimed at an audience that is already comfortable with the basics of Unity and C# programming. I hope you enjoy.
Follow me on twitter @SebastianLague
Support my videos on Patreon: http://bit.ly/sebPatreon
A C++ article about persistent graphic settings in UE4:
In comparison to modern consoles there are hundreds and thousands of various PC hardware configurations. Different graphics cards, central processors, memory etc. in all sizes, shapes and colors allow for an endless number of various hardware setups. Some of those are more powerful than others, and not every PC can play the latest game with graphics settings at their maximum level. Typically on the PC platform one can control different aspects of tuning those graphics settings: from the resolution of the monitor, via anti-aliasing techniques, to texture and shadow quality levels. All these settings allow to adapt the game to the actual performance of the hardware in use.
Modern game engines allow to set such things out of the box, and UE4 is no exception. Epic calls this “scalability”, and on top of those things mentioned before in Unreal you can also set quite a few more game and graphics aspects, such as post processing quality, effects quality, material quality, and others.
Well, in UE4 you basically have two main parts to tweak in terms of graphics settings. On one hand that is the so-called video mode, which is basically nothing else than the game screen resolution, as well as whether or not to render the game in full screen mode or in a (borderless) window. On the other hand you have those quality settings mentioned above and listed in detail in the UE4 scalability documentation.
Now the question is how one can set and change those values and parameters from within the game. The obvious way is to do so via in-game console commands. A simple web search will reveal those commands to you, for example as listed in the UE4 answer hub. However, using those console commands seems to be a bit cumbersome, and from our understanding that is also not the way Epic recommends. For example, you need to explicitly call those commands every time you start the game, which for sure is not what we want. Instead we want the engine itself to automatically do all those things for us. Thus let’s have a look at handling those graphics settings the proper way, and in particular: permanently!
For reading the article, please follow this link.
This release serves as a maintenance release, focusing on stability, bug fixes and completing API’s. Enhancements to 2D, 3D, Physics and a new JS and LUA scripting component! It is recommended to upgrade if your circumstances allow it.
Bjarne Stroustrup on the 30th anniversary of Cfront (the first C++ compiler)
Sound is an essential medium for human-computer interaction and vital for applications such as games and music production software. In the audio industry, C++ is the dominating programming language. This talk provides an insight into the patterns and tools that C++ developers in the audio industry rely on. There are interesting lessons to be learned from this domain that can be useful to every C++ developer.
Handling audio in real time presents interesting technical challenges. Techniques also used in other C++ domains have to be combined: real-time multithreading, lock-free programming, efficient DSP, SIMD, and low-latency hardware communication. C++ is the language of choice to tie all these requirements together. Clever leveraging of advanced C++ techniques, template metaprogramming, and the new C++11/14 standard makes these tasks more exciting than ever.
Part I: Introduction to lock-free programming. We will cover the fundamentals of lock-free vs lock-based programming, explore the reasons to write lock-free programs as well as the reasons not to. We will learn, or be reminded, of the basic tools of lock-free programming and consider few simple examples. To make sure you stay on for part II, we will try something beyond the simple examples, for example, a lock-free list, just to see how insanely complex the problems can get. Part II: having been burned on the complexities of generic lock-free algorithms in part I, we take a more practical approach: assuming we are not all writing STL, what limitations can we really live with? Turns out that there are some inherent limitations imposed by the nature of the concurrent problem: is here really such a thing as “concurrent queue” (yes, sort of) and we can take advantages of these limitations (what an idea, concurrency actually makes something easier!) Then there are practical limitations that most application programmers can accept: is there really such a thing as a “lock-free queue” (may be, and you don’t need it). We will explore practical examples of (mostly) lock-free data structures, with actual implementations and performance measurements. Even if the specific limitations and simplifying assumptions used in this talk do not apply to your problem, the main idea to take away is how to find such assumptions and take advantage of them, because, chances are, you can use lock-free techniques and write code that works for you and is much simpler than what you learned before.
How do we use C++14 to make our code better, rather than just different? How do we do so on a grand scale, rather than just for exceptional programmers? We need guidelines to help us progress from older styles, such as “C with Classes”, C, “pure OO”, etc. We need articulated rules to save us from each having to discover them for ourselves. Ideally, they should be machine-checkable, yet adjustable to serve specific needs.
In this talk, I describe a style of guidelines that can be deployed to help most C++ programmers. There could not be a single complete set of rules for everybody, but we are developing a set of rules for most C++ use. This core can be augmented with rules for specific application domains such as embedded systems and systems with stringent security requirements. The rules are prescriptive rather than merely sets of prohibitions, and about much more than code layout. I describe what the rules currently cover (e.g., interfaces, functions, resource management, and pointers). I describe tools and a few simple classes that can be used to support the guidelines.
PS4 and Xbox One have virtual memory and 64 bit address spaces, GPU and CPU are getting closer in the ability to work virtual memory. So our tools are getting better and better and closer to PCs. Most of a games memory goes towards art and level data like bitmap textures and polygon meshes. So artist and designer need to understand how much their data takes up. Giving them call stacks of memory allocations does not help. They want to know how big is a group of building is. Why is this group of building bigger than this one? Maybe this one has some animation data or one of the textures is too big. But there are 10,000s of objects built by 100s of people all around the world.