Programming, graphics, games, media, C++, Windows, Internet and more...
All blog entries, ordered from most recent. Entry count: 1171.
Pages: 
1 ... 6 7 8 9 10 ... 147 
# Vulkan Memory Allocator - budget management
Wed
06
Nov 2019
Querying for memory budget and staying within the budget is a very needed feature of the Vulkan Memory Allocator library. I implemented prototype of it on a separate branch "MemoryBudget".
It also contains documentation of all new symbols and a general chapter "Staying within budget" that describes this topic. Documentation is pregenerated so it can be accessed by just downloading the repository as ZIP, unpacking, and opening file "docs\html\index.html" > chapter “Staying within budget”.
If you are interested, please take a look. Any feedback is welcomed - you can leave your comment below or send me an e-mail. Now is the best time to adjust this feature to users' needs before it gets into the official release of the library.
Long story short:
VMA_ALLOCATION_CREATE_WITHIN_BUDGET_BIT, which causes the allocation to just return failure if it would go over budget.Update 2019-12-20: This has been merged to master branch and shipped with the latest major release: Vulkan Memory Allocator 2.3.0.
Comments | #vulkan #libraries #productions Share
# Further improvements on my website
Sat
12
Oct 2019
Have you noticed any changes on my website? Probably not - and that’s the whole point. I’ve made few improvements on the technical side of it, but it’s still working as usual. Here is a brief story of the development of my home page...
I was never a passionate web developer, but I learned a bit of some languages and technologies needed to make a web page. When I started this one in 2004, the word “blog” was already in use, but there was no “cloud”, no Node.js or Ruby on Rails. I could either buy a hosting account with PHP scripting and MySQL database on the back end, or a Linux shell account with full SSH access, which would be much more expensive. Surely I chose the first option. Besides that, there was HTML 4.01 and CSS 1 on the client’s side.
Over time, I introduced gradual improvements to my home page, including:
<table>s to more modern based on <div>s and CSS formatting. Started using HTML5. (See Changes on My Website.)For some time I thought maybe I should rewrite this whole website from scratch. Then there would be a difficult question to answer: What technology to use? I don’t know web technologies well, but I know there are many of them. I could just install WordPress or some other blogging system and somehow move all the existing content there. I could rewrite all the scripts using more modern PHP 7 or a more trendy language, like Ruby, server-side JavaScript. I could even make it all static HTML content, which would be enough for the things I have here. Then I could use some offline tool to generate those pages, or write my own. I could also use Amazon S3 to host those pages. The possibilities are endless...
Then I recalled the rule that “if it ain’t broke, don’t fix it” and thought the hosting service I now use at Domenomania.pl company is quite good with a low price for WWW + PHP + MySQL + FTP + e-mail account. I decided eventually just to improve the existing solution. Here is what I’ve changed recently:
If you have any suggestions about my website, whether its looks or technical details, please leave a comment.
Comments | #homepage #webdev Share
# Book review: C++17 in Detail
Sun
06
Oct 2019
Courtesy its author Bartłomiej Filipek, I was given an opportunity to read a new book "C++17 in Detail". Here is my review:
When I am about to read or decide whether to buy a book, I first look at two things. These are not the looks of the cover or the description on the back. Instead, I check the table of contents and the number of pages. It gives me a good overview of the topics covered and the estimation of chances they are sufficiently covered. "C++17 in Detail" with its 361 pages looks good as for a book describing what's new in C++17 standard, considering the additions to the standard are not as extensive as they were in C++11. The author is undoubtedly an expert in this field, as seen from entries on his Bartek's coding blog.
Author claims to describe all the significant additions to the language. However, this is not a dull, difficult to read documentation of the new language elements, like you can find on cppreference.com. Instead, the book describes each of them by giving some background and rationale, and showing real-life examples. It makes them easy to understand and to appreciate their usefulness. Each addition to the standard is also accompanied with a reference to the official documents by C++ standard committee and a table showing which versions of the most popular C++ compilers (GCC, Clang, Microsoft Visual C++) support it. Spoiler: They already support almost all of them :)
The book doesn't teach everything from scratch. That would be impossible in that number of pages, considering how big and complex C++ is. It assumes the reader already knows the language quite well, including some features from C++11 like unique_ptr or r-value reference + move semantics. It explains however few topics needed for the book in more details, like the concept of "reduce" and "scan" parallel algorithms, which C++17 adds to the standard library.
The contents of the book is grouped into 3 parts. Part 1 describes additions to the C++ language itself, including init statement for if and switch (e.g. if(int i = Calculate(); i > 0) ...), additions to templates like if constexpr, and attributes like [[nodiscard]], [[maybe_unused]]. Part 2 describes what has been added to its standard library, including std::optional, variant, any, string_view, filesystem. Finally, part 3 shows more extensive code examples that combine multiple new C++ features to refactor existing code into more clean and more efficient one. The author also mentions what parts of the language have been deprecated or removed in the new standard (like auto_ptr).
To summarize, I recommend this book to any C++ developer. It's a good one, and it lets you stay up-to-date with the language standard. You will learn all new features of the language and its standard library from it in a more pleasing way than by reading documents from the C++ committee. Even if you won't be able to use these new features in your current project because your old compiler not upgraded for many years or the coding standard imposed by your team lead doesn't let you, I think it's worth learning those things. Who knows if you won't be asked about them on your next job interview?
You can buy printed version of the book on Amazon.com and electronic version on Leanpub. Bartek, the author of the book, also agreed to give all of the readers of my blog a nice discount - 30%. It's valid till the end of October, and to use it just visit this link.
# Weirdest rules from coding standards
Sat
28
Sep 2019
Earlier this month I asked on Twitter "what is the weirdest and the most stupid rule you had to follow because of the "Coding Standard"?" I've got some interesting responses. Thinking about it more, I concluded that coding standards are complex. Having one in your project is a good thing because it imposes a consistent style, which is a value by itself. But specific rules are of various types. Some carry universally recognized good practices, like "use std::unique_ptr, don't use std::auto_ptr". Some serve good code performance, like "pass large structures as const& parameters, not by value". Others are purely a matter of subjective preference of its authors, e.g. to use CamelCaseIdentifiers rather than snake_case_identifiers or spaces instead of tabs for indentation. Even the division between those categories is no clear though. For example, there is a research showing that Developers Who Use Spaces Make More Money Than Those Who Use Tabs.
But some rules are simply ridiculous and hard to explain in a rational way. Here are two examples from my experience:
Number 2: Lengthy ASCII-art comment required before every function. In that project we couldn't write an inline function even for the simplest getters, like:
class Element
{
private:
int identifier;
public:
int GetIdentifier() { return identifier; } // Illegal!
We had to only declare member functions in the header file, while definition had to contain a specific comment that repeats the name of the function (which is a nonsense and a bad practice by itself, as it introduces duplication and may go out of sync with actual code), and its description (even if the name is self-descriptive), description of all its parameters (even if their names are self-descriptive), return value etc. Example:
/*****************************************************************************\
Function:
Element::GetIdentifier
Description:
Returns identifier.
Input:
None.
Output:
Identifier of the current element.
\*****************************************************************************/
int Element::GetIdentifier()
{
return identifier;
}
I like comments. I believe they are useful to explain and augment information carried by function and variable names, especially when they document valid usage of a library interface. For example, a comment may say that a pointer can be null and what that means, a uint may have special value UINT32_MAX and what happens then, or that a float is expressed in seconds. But the comment as shown above doesn't add any useful information. It's just more symbols to type, developer's time wasted, makes code bloated and less readable. It's not even in any standard format that could automatically generate documentation, like with Doxygen. It's just custom, arbitrary rule.
What was the reason behind this rule? A colleague once told me that many years ago the architect of this whole program hoped that they would develop a tool to parse all this code and those comments and generate documentation. Decades have passed, and it didn't happen, but developers still had to write those comments.
The effect was that everyone avoided adding new functions as much as possible or splitting their code into small functions. They were just adding more and more code to the existing ones, which could grow to hundreds of lines. That also caused one of the most obscure bugs I've met in my life (bug number 2).
Number 1: Don't use logical negation operator '!', like: if(!isEnabled). Always compare with false instead, like: if(isEnabled == false).
I understand a requirement to always compare pointers and numbers to some value like nullptr instead of treating them as booleans, although I don't like it. But banning one of the fundamental operators, also when used with bool variables, is hard to justify for me.
Why would anyone come up with something like this? Is it because a single '!' symbol is easy to omit when writing or reading and not so explicit as == false? Then, if the author of this rule suffers from bad sight or dyslexia and a single dash here and there doesn't make a difference to him, maybe he should also define functions Add(), Subtract(), and tell developers to use them instead of operators '+' and '-', because they too are so easy to confuse? Or maybe not... He should rather go do something other than programming :)
Comments | #software engineering #c++ Share
# D3D12 Memory Allocator 1.0.0
Mon
02
Sep 2019
Since 2017 I develop Vulkan Memory Allocator - a free, MIT-licensed C++ library that helps with GPU memory management for those who develop games or other graphics applications using Vulkan. Today we released a similar library for DirectX 12: D3D12 Memory Allocator, which I was preparing for some time. Because that's a project I do at my work at AMD rather than a personal project, I won't describe it in more details here, but just point to the official resources:
If you are interested in technical details and problems I had to consider during development or you want to write your own allocator for either Vulkan or Direct3D 12, you may also check my recent article: Differences in memory management between Direct3D 12 and Vulkan.
Comments | #libraries #directx #productions Share
# Most frequent questions on programming job interviews
Thu
29
Aug 2019
There are different questions that appear on job interviews. Good preparation to such interviews is an art on its own, just like making a good CV, and there are whole books and trainings about it. A potential employer usually asks for details of what is in your CV - your past experience (especially previous 1 or 2 jobs) and why did you leave your previous job. He may ask you to solve some algorithmic puzzles to test your general “intelligence”. He may even ask some ridiculous questions like “Try to estimate how many litres of paint is used every year to renovate buildings in London?”, believing that your response and your way of thinking will be some estimate of whether you will be a good employee. But most of the interviewers also ask some real, technical questions, checking your knowledge from the domain you will work with. Out of these, I observed few questions occurring most frequently. Here they are, together with a draft of the correct response:
1. About C++
1.1. What does inline keyword do? Answer: It means the function should be inlined by the compiler in each place where it is called instead of leaving the function call in the compiled code. It’s only a hint, modern compilers decide which functions to inline on their own.
1.2. What does virtual keyword do? How does it work? Answer: It lets you implement polymorphism when using class inheritance. When an object of a derived class is passed by a pointer or a reference to a base class, calling such a function will call the version from the derived class - the one that the passed object “really is”. It works thanks to each object having an additional, hidden pointer to the virtual function table, which dispatches calls to such functions to the appropriate version.
1.3. What does volatile keyword do? Answer: It tells the compiler that a variable marked with this modifier can change value out of its control (e.g. by a different thread, operating system, or hardware) so it should not optimize its access by caching its value in CPU registers, assume it won’t change for some period etc., but use it in its original location every time. Side note: This keyword is rarely used. It probably appears more frequently on job interviews than in a real code :)
1.4. What does mutable keyword do? Answer: It allows to change a class member variable marked with this modifier even if the member function and the current object is const. It might be useful e.g. to perform lazy evaluation - object is passed as const& and appears to be unchanged, but its methods GetSomething() calculates and caches the value of “something” on first call. Side note: This keyword is rarely used. It probably appears more frequently on job interviews than in a real code :)
2. About general programming
2.1. What is the difference between process and thread? Answer: Process is launched from a particular executable file. It has its own address space (memory heap is common for the whole process), handles to open files, network sockets etc., separated from other processes in the operating system. It comprises a main thread and may have several additional threads. Each thread shares the same code and memory heap, but it has its own stack, instruction pointer (the place in the code currently executed), and values of CPU registers.
2.2. What is a mutex? Answer: It’s a synchronization object that allows multiple threads to access a common resource safely. If only one thread can access the resource, the code accessing it (called a critical section) has to be surrounded by locking the mutex above it and unlocking the mutex below it. Then only one thread will be able to execute that code in any moment. Other threads have to wait.
2.3. What is a deadlock? How to prevent it? Answer: Deadlock is an error in multithreaded code occurring when two or more threads wait for each other and will never make progress. To prevent it, always remember to unlock your mutexes (even when doing early return, break, throwing exception etc.) Also, when locking multiple mutexes, always lock them in the same order, never like: thread 1 locking A then B, thread 2 locking B then A.
3. About graphics programming
3.1. Describe graphics pipeline in modern GPUs. Answer: Depending on how detailed you want to describe it, you can tell that data is processed through following stages: vertex fetch / input assembler (fetching vertices/triangles) --> vertex shader --> optional tessellation (hull shader aka tessellation control shader --> fixed tessellator --> domain shader aka tessellation evaluation shader) --> optional geometry shader --> triangle clipping and culling (incl. viewport culling, backface culling etc.) --> rasterizer (converting triangles to pixels) --> pixel shader aka fragment shader --> depth-stencil test --> writing to render targets with blending.
3.2. What’s the difference between forward and deferred shading? Answer: In traditional forward shading, each object is rendered already shaded by each affecting light. In deferred shading, objects are rendered only once, with their parameters stored in intermediate render targets called G-buffer - like albedo color (taken straight from color texture), normal, depth (allows to reconstruct full position), material parameters (like roughness and metalness in case of PBR). Then separate screen-space passes use these data to apply shading from particular lights. One could say forward shading has complexity of O*L, where O is a number of objects and L is a number of lights, while deferred shading has O+L, which is better for a large number of lights. But deferred shading has its drawbacks: heavy G-buffers consume lots of bandwidth, the algorithm doesn’t work well with translucent objects, MSAA, or using different materials.
There are many more questions you may meet on programming job interview, whether from the topics described above (e.g. from advanced C++ - what is RAII, what is SFINAE), or any other topics important for a specific position, but from my experience those mentioned above are especially frequent, so preparing good answers to them may be the best investment of your time before the interview.
# Differences in memory management between Direct3D 12 and Vulkan
Fri
26
Jul 2019
Since July 2017 I develop Vulkan Memory Allocator (VMA) – a C++ library that helps with memory management in games and other applications using Vulkan. But because I deal with both Vulkan and DirectX 12 in my everyday work, I think it’s a good idea to compare them.
This is an article about a very specific topic. It may be useful to you if you are a programmer working with both graphics APIs – Direct3D 12 and Vulkan. These two APIs offer a similar set of features and performance. Both are the new generation, explicit, low-level interfaces to the modern graphics hardware (GPUs), so we could compare them back-to-back to show similarities and differences, e.g. in naming things. For example, ID3D12CommandQueue::ExecuteCommandLists function has Vulkan equivalent in form of vkQueueSubmit function. However, this article focuses on just one aspect – memory management, which means the rules and limitation of GPU memory allocation and the creation of resources – images (textures, render targets, depth-stencil surfaces etc.) and buffers (vertex buffers, index buffers, constant/uniform buffers etc.) Chapters below describe pretty much all the aspects of memory management that differ between the two APIs.
Comments | #vulkan #directx #gpu Share
# Slavic Game Jam 2019 and our project
Thu
25
Jul 2019
Over the last weekend I took part in Slavic Game Jam 2019 in Warsaw, Poland. (See website, Facebook event, games at itch.io). It was a big one - over 200 participants, many of them coming from different countries all around Europe. The event started on Thursday with a session of talks in 2 parallel tracks. In the evening there was a pre-party in VooDoo club, with electronic music played from GameBoys and live visuals. The jam started on Friday with the announcement of the theme which was "growth". As always, this was just an inspiration, so participants were free to make any kinds of games.
During the event there was food provided, as well as fruits and vegetables, coffee, and ice cream - all for free, included in the ticket price. Also during the event there was "HydePark" organized in a separate room - something like a small Slot Art Festival where people could reserve time slots to organize their events of any kind - like a talk, a workshop, playing video games, or playing some instruments. It made me wonder if people could come to SGJ, not make any game and still enjoy themselves all the time!
The official communication between the organizers and participants happened on a designated Discord server. Organizers kept us informed about everything what's important by posting announcements to @everyone. And there was a lot happening. For example, they asked us to deliver an exactly 3-second video from our games, from which they later assembled this showreel. They were also making quality photos and posting them during the jam on the Facebook event.
The deadline for games was on Sunday midday. What's interesting is that SGJ was non competitive this time. There were no presentations of the games on stage, no voting or judging by any jury, no winners or prizes. Instead of that, everyone needed to prepare their game to be played by others at their desk. I liked that. I think it might even feel somewhat like preparing a booth at some game expo if taken seriously. Finally, as every good party has a before- and after-party, so in the evening we went to a bar :)
To summarize, I think that in some way it's quite easy to organize a (normal) game jam. You need not invite speakers like for a conference. You need not provide any hardware, as people will bring their own laptops. All you need to do is to have some venue booked for a weekend, and some marketing to invite people to come. Possibly that's why there are so many of such events. My friend once said that taking part in game jams can become a lifestyle - you can go to one almost every week. But SGJ was different. There was so much happening and it was so well organized that I'm sure it required enormous work from everyone involved. Congratulations to the entire crew, KNTG Polygon group from Warsaw University of Technology, volunteers and others!
Regarding the games created during the jam, I could see most of them were developed using Unity. Other technologies were used as well. There were few mobile games, few board games... I couldn't see many VR games. I was developing a game in a team of two, together with my friend Thomas Pendragon - just two programmers. We were planning to use Unreal but we eventually used Unity. We ended up making this game: see entry at itch.io (including binary download for Windows and MacOS).
In our game, you need to "grow" your city by creating a balanced number of places of 5 types (red for building, green for park, blue for water, yellow for airport, gray for road). The city visualization on the left is just eye-candy. You play a tile-matching game like Candy Crush Saga, but with one twist. In the bottom-center there is a Tetris-like indicator that goes up every time you make a match of some color. When all colors are matched, the bottom row is cleared - like in Tetris. If any color goes all the way to the top, you lose, so you need to consider which colors do you match to keep a good balance. That makes the game more strategic. Points are calculated for every match - more if you match 4 or 5 in a row or if something else is matched in the same move. How many points can you reach? The record during the jam was above 1000.
Thomas gave initial idea and designed the game. He did some coding (like the city building on the left), composed the music, added sound effects, made some graphics in Blender, and assembled the rest from some assets. I coded the core logic of the matching game, the whole UI, and juicing, like particle effects and animations.
As a post-mortem of this little project, here is the list of what went right:
What went wrong?