Programming, graphics, games, media, C++, Windows, Internet and more...
Entries for tag "productions", ordered from most recent. Entry count: 138.
# Graphics APIs – Yesterday, Today, and Tomorrow - a New Article
Tue
20
Jan 2026
Today I would like to present my new article: "Graphics APIs – Yesterday, Today, and Tomorrow". In this article, we will take a quick walk through the history of graphics APIs such as DirectX, OpenGL, Vulkan, and the accompanying development of graphics cards on the one hand, and video games on the other, over the years. We will not be learning how to program in any of these APIs. This article should be understandable and may be engaging for anyone curious about games or graphics, or at least for those who played games in childhood.
The article was first published few months ago in Polish in issue 4/2025 (119) (July/August 2025) of the Programista magazine. Now I have a right to show it publicly for free, so I share it in two language versions:
Comments | #productions #directx #vulkan #opengl #rendering Share
# The Secrets of Floating-Point Numbers - a New Article
Wed
28
May 2025
Today I would like to present my new article: "The Secrets of Floating-Point Numbers". I can be helpful to any programmer no matter what programming language they use. In this article, I discuss floating-point numbers compliant with the IEEE 754 standard, which are available in most programming languages. I describe their structure, capabilities, and limitations. I also address the common belief that these numbers are inaccurate or nondeterministic. Furthermore, I highlight many non-obvious pitfalls that await developers who use them.
The article was first published few months ago in Polish in issue 5/2024 (115) (November/December 2024) of the Programista magazine. Now I have a right to show it publicly for free, so I share it in two language versions:
Comments | #productions #math Share
# D3d12info app and online GPU database
Tue
29
Apr 2025
This post is about D3d12info open-source project that I'm involved in. The project is in continuous development, while I noticed I didn't blog about it since I first announced it in 2022. Here, I describe the story behind it and the current state of it. The post may be interesting to you if you are a programmer coding graphics for Windows using DirectX 12.
Various GPUs (discrete graphics cards, processor integrated graphics chips) from various vendors (AMD, Intel, Nvidia, …) have various capabilities. Even when a GPU supports a specific API (OpenGL, DirectX 11, DirectX 12, Vulkan), some of the features may not be supported. These features span from the big ones that even non-programmers recognize, like ray tracing, to the most obscure, like the lengthy D3D12_FEATURE_DATA_D3D12_OPTIONS::VPAndRTArrayIndexFromAnyShaderFeedingRasterizerSupportedWithoutGSEmulation and even lengthier Vulkan VkPhysicalDeviceShaderIntegerDotProductProperties::integerDotProductAccumulatingSaturating4x8BitPackedMixedSignednessAccelerated 🙂
Before using any of these features in our apps, we need to query if the feature is supported on the current GPU. Checking it programmatically is relatively simple. Graphics APIs offer functions for that purpose, like ID3D12Device::CheckFeatureSupport and vkGetPhysicalDeviceProperties2. When the feature is not supported, the app should either fall back to some other implementation (e.g. using screen-space reflections instead of ray-traced reflections) or display an error telling that the GPU doesn’t meet our minimum hardware requirements.
However, when we plan using some optional feature of the API and we think about testing it on a variety of platforms and eventually shipping it to end users, we may ask:
For Vulkan, answers to these questions are: yes & yes. For querying the capabilities of the local GPU, Vulkan SDK comes with a small command-line program called “vulkaninfo”. After calling it, we can see all the extensions, properties, features, and limits of the GPU, in a human-readable text format. Alternatively, JSON and HTML format is also available.
For the database of GPUs, Sascha Willems maintains Vulkan Hardware Database and an accompanying GUI app Vulkan Hardware Capability Viewer that presents the capabilities of the local GPU and also allows submitting this report to the database.
For Direct3D 12, however, I wasn’t aware of any such application or database. Windows SDK comes with a GUI app that can be found in "c:\Program Files (x86)\Windows Kits\10\bin\*\x64\dxcapsviewer.exe". It presents some features of DirectDraw, Direct3D9, 11, DXGI, also some options of Direct3D12, but doesn’t seem to be complete in terms of all the latest options available. There is no updated version of it distributed with DirectX 12 Agility SDK. There is also no way to use it from command line. At least Microsoft open sourced it: DxCapsViewer @ GitHub.
This is why I decided to develop D3d12info, to become a DX12 equivalent of vulkaninfo. Written in C++, this small Windows console app prints all the capabilities of DX12 to the standard output, in text format. The project is open source, under MIT license, but you can also download precompiled binaries by picking the latest release.
JSON is also available as the output format, which makes the app suitable for automated processing as part of some larger pipeline.
I published first “draft” version of D3d12info in 2018, but it wasn’t until July 2022 that I released first version I considered complete and marked as 1.0.0. The app had many releases since then. I update it as Microsoft ships new versions of the Agility SDK to fetch newly added capabilities (including ones from “preview” version of the SDK).
There are some other information fetched and printed by the app apart from DX12 features. The ones I consider most important are:
However, I try to limit the scope of the project to avoid feature creep, so I refuse some feature requests. For example, I decided not to include capabilities queried from DirectX Video or WDDM.
D3d12info would stay only a command-line tool without Dmytro Bulatov “Devaniti” - a Ukrainian developer working at ZibraAI, who joined the project and developed D3d12infoGUI. This app is a convenient overlay that unpacks the command-line D3d12info, launches it, converts its output into a nicely looking HTML page, which is then saved to a temporary file and opened in a web browser. This allows browsing capabilities of the current GPU in a convenient way. Dmytro also contributed significantly to the code of my D3d12info project.
If you scroll down the report, you can see a table with texture formats and the capabilities they support. Many of them are mandatory for every GPU supporting feature level 12_0, which are marked by a hollow check mark. However, as you can see below, my GPU supports some additional formats as “UAV Typed Load”:
The web page with the report also offers a large green button near the top that submits it to the online database. Here comes the last part of the ecosystem: D3d12infoDB. This is something I was dreaming about for years, but I couldn’t make it since I am not a proficient web developer. Now, Dmytro along with other contributors from the open source community developed a website that gathers reports about various GPUs, offering multiple ways of browsing, searching, and filtering them.
One great feature they’ve added recently is Feature Table. It gathers DX12 capabilities as rows, while columns are subsequent generations of the GPUs from AMD, Nvidia, Intel, and Qualcomm. This way, we can easily see which features are supported by older GPU generations to make a better decision about minimum feature set required by the game we develop. For example, we can see that ray tracing (DXR 1.1) and mesh shaders are supported by Nvidia since Turning architecture (GeForce RTX 2000 series, released in 2018), but support from AMD is more recent, since RDNA2 architecture (Radeon RX 6000 series, released in 2020).
As I mentioned above, I keep the D3d12info tool updated to the latest DirectX 12 Agility SDK, to fetch and print newly added capabilities. This also includes major features like DirectSR or metacommands. D3d12infoGUI app and D3d12infoDB website are also updated frequently.
I want to avoid expanding my app too much. One major feature I consider adding is a separate executable for x86 32-bit, x86 64-bit, and ARM architecture, as I heard there are differences in DX12 capabilities supported between them, while some graphics programmers (e.g. on the demoscene) still target 32 bits. Please let me know if it would be useful to you!
Finally, here is my call to action! You can help the project by submitting your GPU to the online database. Every submission counts. Even having a different version of the graphics driver constitutes a separate entry. Please download the latest D3d12infoGUI release, launch it, and when the local web page opens, press that large green button to submit your report.
Only if you are one of those developers working for a GPU vendor and you use some prototype future GPU hardware or an internal unreleased build of the graphics driver, then, please don’t do it. We don’t want to leak any confidential information through this website. If you accidentally submitted such report, please contact us and we will remove it.
Comments | #productions #directx Share
# Global Game Jam 2025 and First Impressions from Godot
Wed
29
Jan 2025
Last weekend, 24-26 January 2025 I participated in Global Game Jam, and, more specifically, PolyJam 2025 - a site in Warsaw, Poland. In this post I'll share the game we've made (including the full source code) and describe my first impressions of the Godot Engine, which we used for development.
We made a simple 2D pixel-art game with mechanics similar to Overcooked. It was designed for 2 to 4 players in co-op mode, using keyboard and gamepads.
Entry of the game at globalgamejam.org
GitHub repository with the source code
A side note: The theme of GGJ 2025 was "Bubble". Many teams created games about bubbles in water, while others interpreted it more creatively. For example, the game Startup Panic: The Grind Never Stops featured minigames like drawing graphs or typing buzzwords such as "Machine Learning" to convince investors to fund your startup – an obvious bubble 🙂 Our game, on the other hand, focused on taking care of babies and fulfilling their needs so they could grow up successfully. In Polish, the word for "bubbles" is "bąbelki", but it’s also informally used to refer to babies. Deliberately misspelled as "bombelki", it is a wordplay that makes sense and fits the theme in Polish.
My previous game jam was exactly two years ago. Before that jam, I had learned a bit of the Cocos Creator and used it to develop my game, mainly to try something new. I described my impressions in this post: Impressions After Global Game Jam 2023. This time, I took a similar approach and I started learning Godot engine about three weeks before the jam. Having some experience with Unity and Unreal Engine, my first impressions of Godot have been very positive. Despite being an open-source project, it doesn’t have that typical "open-source feeling" of being buggy, unfinished, or inconvenient to use. Quite the opposite! Here are the things I especially like about the engine:
I like that it’s small, lightweight, and easy to set up. All you need to do is download a 55 MB archive, unpack it, and you’re ready to start developing. This is because it’s a portable executable that doesn’t require any installation. The only time you need to download additional files (over 1 GB) is when you’re preparing to create a build for a specific platform.
I also appreciate how simple the core ideas of the engine are:
I’m not sure if this approach is optimal in terms of performance or whether it’s as well-optimized as the full Entity Component System (ECS) that some other engines use. However, I believe a good engine should be designed like this one – with a simple and intuitive interface, while handling performance optimizations seamlessly under the hood.
I also appreciate the idea that the editor is built using the same GUI controls available for game development. This approach provides access to a wide range of advanced controls: not just buttons and labels, but also movable splitters, multi-line text editors, tree views, and more. They can all be skinned with custom colors and textures.
Similarly, files saved by the engine are text files in the INI-like format with sections like [SectionName] and key-value pairs like Name = Value. Unlike binary files, XML, or JSON, these files are very convenient to merge when conflicts arise after two developers modify the same file. The same format is also available and recommended for use in games, such as for saving settings.
Then, there is GDScript - a custom scripting language. While Godot also offers a separate version that supports C# and even has a binding to Rust, GDScript is the native way of implementing game logic. I like it a lot. Some people compare it to Python, but it’s not a fork or extension of Python; it’s a completely separate language. The syntax shares similarities with Python, such as using indentation instead of braces {} to define scopes. However, GDScript includes many features that Python lacks, specifically tailored for convenient and efficient game development.
One such feature is an interesting mix of dynamic and static typing. By default, variables can have dynamic types (referred to as "variant"), but there are ways to define a static type for a variable. In such cases, assigning a value of a different type results in an error – a feature that Python lacks.
var a = 0.1
a = "Text" # OK - dynamic type.
var b: float
b = 0.1
b = "Text" # Error! b must be a number.
var c := 0.1
c = "Text" # Error! c must be a number.
Another great feature is the inclusion of vector types for 2D, 3D, or 4D vectors of floats or integers. These types are both convenient and intuitive to use – they are passed by value (creating an implicit copy) and are mutable, meaning you can modify individual xyzw components. This is something that Python cannot easily replicate: in Python, tuples are immutable, while lists and custom classes are passed by reference. As a result, assigning or passing them as function parameters in Python makes the new variable refer to the original object. In GDScript, on the other hand:
var a := Vector2(1.0, 2.0)
var b := a # Made a copy.
b.x = 3.0 # Can modify a single component.
print(a) # Prints (1, 2).
I really appreciate the extra language features that are clearly designed for game development. For example, the @export attribute before a variable exposes it to the Inspector as a property of a specific type, making it available for visual editing. The $NodeName syntax allows you to reference other nodes in the scene, and it supports file system-like paths, such as using / to navigate down the hierarchy and .. to go up. For instance, you can write something like $../AudioPlayers/HitAudioPlayer.play().
I also like how easy it is to animate any property of any object using paths like the one shown above. This can be done using a dedicated AnimationPlayer node, which provides a full sequencer experience with a timeline. Alternatively, you can dynamically change properties over time using a temporary Tween object. For example, the following code changes the font color of a label to a transparent color over 0.5 seconds, using a specific easing function selected from the many available options (check out the Godot tweening cheat sheet for more details):
create_tween().tween_property(addition_label.label_settings, ^":font_color", transparent_color, 0.5).set_trans(Tween.TRANS_CUBIC).set_ease(Tween.EASE_IN)
I really appreciate the documentation. All core language features, as well as the classes and functions available in the standard library, seem to be well-documented. The documentation is not only available online but also integrated into the editor (just press F1), allowing you to open documentation tabs alongside your script code tabs.
I also like the debugger. Being able to debug the code I write is incredibly important to me, and Godot delivers a full debugging experience. It allows you to pause the game (automatically pausing when an error occurs), inspect the call stack, view variable values, explore the current scene tree, and more.
That said, I’m sure Godot isn’t perfect. For me, it was just a one-month adventure, so I’ve only described my first impressions. There must be reasons why AAA games aren’t commonly made in this engine. It likely has some rough edges and missing features. I only worked with 2D graphics, but I can see it supports 3D graphics with a Forward+ renderer and PBR materials. While it could potentially be used for 3D projects, I’m certain it’s not as powerful as Unreal Engine in that regard. I also encountered some serious technical issues with the engine during the game jam, but I’ll describe those in separate blog posts to make them easier to find for anyone searching the Internet for a solution. (Update: the follow-up article is "Fixing Godot 4.3 Hang on ASUS TUF Gaming Laptop".)
I also don’t know much about Godot’s performance. The game we made was very simple. If we had thousands of objects on the scene to render and complex logic to calculate every frame, performance would become a critical factor. Doing some work in every object every frame using _process function is surely an anti-pattern and it runs serially on a single thread. However, I can see that GDScript also supports multithreading – another feature that sets it apart from Python.
To summarize, I now believe that Godot is a great engine at least for game jams and fast prototyping.
Comments | #productions #ggj #competitions #events #godot Share
# Thoughts Beyond C++
Mon
30
Dec 2024
Earlier this month, Timothy Lottes published a document on Google Docs called “Fixing the GPU”, where he describes many ideas about how programming compute shaders on the GPU could be improved. It might be an interesting read for those advanced enough to understand it. The document is open for suggestions and comments, and there are few comments there already.
On a different topic, 25 November I attended Code::Dive conference in Wrocław, Poland. It was mostly dedicated to programming in C++ language. I usually attend conferences about game development, so it was an interesting experience for me. Big thanks to Tomasz Łopuszański from Programista magazine for inviting me there! It was great to see Bjarne Stroustrup and Herb Sutter live, among other good speakers. By the way, recordings from the talks are available on YouTube.
Those two events inspired me to write down my thoughts – my personal “wishlist” about programming languages, from the perspective of someone interesting in games and real-time graphics programming. I gathered my opinions about things I like and dislike in C++ and some ideas about how a new, better language could look like. It is less about a specific syntax to propose and more about high-level ideas. You can find it under the following shortened address, but it is really a document at Google Docs. Comments are welcome.
Of course I am aware of Rust, D, Circle, Carbon, and other programming languages that share the same goal of replacing C++. I just wanted to write down my own thoughts about this topic.
Comments | #c++ #compilers #productions Share
# How to do a good code review - a new article
Mon
19
Aug 2024
Today I would like to present my new, comprehensive article: "How to do a good code review". I can be helpful to any programmer no matter what programming language they use. Conducting good code reviews is a skill worth mastering. In this article, we will discuss the advantages and disadvantages of this process and explore the types of projects where it is most beneficial. We will consider the best approach to take when reviewing code, how to effectively carry out the process, which aspects of the code to focus on, and finally – how to write comments on the code in a way that benefits the project. The goal is to ensure that the review process serves as an opportunity for fruitful communication among team members rather than a source of conflict.
The article was first published few months ago in Polish in issue 112 (March/April 2024) of the Programista magazine. Now I have a right to show it publicly for free, so I share it in two language versions:
I wasn't active on my blog in the past months because I took some time for vacation, but also because I'm now learning about machine learning. I may be late to the party, but I recognize that machine learning algorithms are useful tools in many applications. As people learn the basics, the often feel an urge to teach others about it. Some good reads authored by game/graphics developers are: "Machine Learning for Game Devs" by Alan Wolfe and "Crash Course in Deep Learning (for Computer Graphics)" by Jakub Boksansky. I don't want to duplicate their work, so I will only blog about it when I have something unique to show.
Comments | #productions #software engineering Share
# ShaderCrashingAssert - a New Small Library
Sun
20
Aug 2023
Last Thursday (August 17th) AMD released a new tool for post-mortem analysis of GPU crashes: Radeon GPU Detective. I participated in this project, but because this is my personal blog and because it is weekend now, I am wearing my hobby developer hat and I want to present a small library that I developed yesterday:
ShaderCrashingAssert provides an assert-like macro for HLSL shaders that triggers a GPU memory page fault. Together with RGD, it can help with shader debugging.
Comments | #rendering #directx #productions #libraries #gpu #tools Share
# Hello World Under the Microscope - New Article Published
Tue
11
Oct 2022
A Python program that prints "Hello World" on the console - what can be simpler than this? The entire program is:
print("Hello World")
Yet, together with my friends, we wrote a long article about it! When the topic is described by two security researchers skilled in reverse engineering and knowledgeable about the internals of Python interpreter, Windows operating system, and its console, together with a graphics programmer that knows how graphics and text get displayed on the screen, from Direct3D API down to the internals of a graphics card and pixels on the screen, the result is an in-depth description of the long journey this simple command makes in a computer.
The article was originally published in Polish in issue 100 (1/2022) of the Programista magazine in February 2022. Now, we prepared an English translation, and we are allowed to publish it for free on the Internet, so here it is: Hello World under the microscope. You can also download the original Polish version as PDF file or order printed version of the magazine.