Entries for tag "productions", ordered from most recent. Entry count: 125.
# Vulkan Memory Allocator - budget management
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.
# D3D12 Memory Allocator 1.0.0
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.
# Slavic Game Jam 2019 and our project
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?
# Make Your Game Friendly for Graphics Debugging and Optimization - My Talk from Digital Dragons 2019
I've recently gave a talk at Digital Dragons conference in Kraków, Poland. It wasn't very technically advanced this time. Most of it should be understandable to everyone working on games - artists, programmers, producers... I've published slides on GPUOpen.com blog, along with slides my colleagues presented last month at other events across Europe. See: AMD at Digital Dragons and Vulkanised Conference.
# WinFontRender - my new library
Displaying text is a common problem in graphics applications where all you can do is to render textured quads. I've implemented my solution already back in 2007, as part of my old engine The Final Quest 7, which was my master thesis. I've recently come back to this code and improved it because I needed it for the personal project I now work on. Then I thought: Maybe it's a good idea to extract this code into a library? So here it is:
It does two things:
1. It renders characters of the font to a texture, tightly packed.
2. It calculates vertices needed to render given text.
Here are more details about the library:
# Vulkan Memory Allocator Survey March 2019
Are you a software developer, use Vulkan and the Vulkan Memory Allocator library (or at least considered using it)? If so, please spend a few minutes and help to shape the future of the library by participating in the survey:
Your feedback is greatly appreciated. The survey is anonymous - no personal data is collected like name, e-mail etc. All questions are optional.
# Global Game Jam 2019 - my impressions
Last weekend the 2019 edition of Global Game Jam took place - a worldwide event where teams od developers gather in different sites all around the world to make games during two days and two nights. There was a large site in my city (Warsaw) - PolyJam, but I decided to go to Gdańsk to participate it their local site called Hackerspace Game Jam together with my friends.
Theme this year was "what home means to you". As always, participants interpreted it very differently. Those who have families associated home with all kinds of troubles caused by the other residents. Pooplers - the game I liked the most - is about babies crawling around the house and pooping competitively to cover as much surface as possible with their specific color, while avoiding the mother :) Home Alone: Cat edition is about a cat that can destroy and drop stuff from the shelves, all in first person perspective. Kapeć Defender is about a man who throws slipper (pol. "kapeć") at the wife and other people to be able to just sit and watch TV. There were more sci-fi settings as well. I liked the game Gwiezdni Somsiedzi a lot. It is the only one with multiplayer over network. Players have to control satellites flying in space, catch asteroids and throw them at the other players. Another space game was Glop where players have to cooperatively control various devices on the surface of a planet to make it fly, as well as shoot at incoming obstacles.
Our team was a group of friends from the demoscene - 2 ex-Intel C++ developers and 2 DevOps currently working in a bank. Unfortunately we had no graphics artists. Although I would prefer to use Unity or Unreal Engine these days, we eventually decided to go the hard way and code in C++ using dxfw - the old framework developed by Krzysiek K., based on Direct3D 9. I had to remind myself this old technology before the jam, including all these
D3DRS_ fixed-function pipeline states and D3DX math library. By the way: If the last version of DirectX SDK for DX9 was released in June 2010, can we already consider it a retro platform, along with Atari and Amiga? ;)
We used FMOD library for playing sound and music and Gainput for handling input from gamepads. We started from having a ray-traced sphere, so we had to code all the game logic and rendering from scratch, including displaying characters, UI, collisions, etc. We've developed some of the logic in C++ and some in Squirrel, because we had this scripting language already integrated with the framework. I had no previous experience with Squirrel, so I had to learn it very quickly. After going through the documentation, I concluded that I love it! It looks like a great scripting language for simple applications. It's not perfect, e.g. it lacks vector and matrix types so necessary in game development (just like pretty much every other programming language except HLSL/GLSL), but I like its simplicity and syntax. It is very similar to Lua in its overall philosophy - dynamically typed, object oriented, and based on key-value arrays. The syntax is not that weird though. It seems to follow the "principle of least astonishment" - it's very similar to C++, arrays are indexed from 0, plus ending statements with a semicolon is optional - end of line also works.
Participating in an event such as GGJ is always an adventure and an opportunity for many new experiences - much better than just sitting on the Internet at home. During this jam I not only learned Squirrel as a new programming language, but I've also heard what is it like to work as a programmer at a bank, I've registered on Asana (a web service for organizing TODO lists, just like Trello which I used before), and of course I had an opportunity to practice quick and dirty programming, as opposed to code carefully thought out and tested, like it has to be done in a regular job.
Finally, the game we've made is here: LazerBugz. It is a twin-stick shooter happening on a spherical surface of a planet. The "home" is the cosmic base that you have to defend while shooting at alien bugs and going out to gather randomly placed gems. It supports local co-op for any number of players using Xbox gamepads or keyboard and mouse. Some screenshots and a photo of people playing our game:
There was a competition on our site. We didn't take any of the first 3 places. We just got mention among the games who received a good number of votes. The game that won was Clash of T-Rexes - kind of Pong with two dinosaurs standing on two planets.
Official photo gallery from the event: Hackerspace Game Jam 2019
# Debugging D3D12 driver crash
New generation, explcit graphics APIs (Vulkan and DirectX 12) are more efficient, involve less CPU overhead. Part of it is that they don't check most errors. In old APIs (Direct3D 9, OpenGL) every function call was validated internally, returned success of failure code, while driver crash indicated a bug in driver code. New APIs, on the other hand, rely on developer doing the right thing. Of course, some functions still return error code (especially ones that allocate memory or create some resource), but those that record commands into a command list just return
void. If you do something illegal, you can expect undefined behavior. You can use Validation Layers / Debug Layer to do some checks, but otherwise everything may work fine on some GPUs, you may get incorrect result, or you may experience driver crash or timeout (called "TDR"). Good thing is that (contrary to old Windows XP), crash inside graphics driver doesn't cause "blue screen of death" or machine restart. System just restarts graphics hardware and driver, while your program receives
DXGI_ERROR_DEVICE_REMOVED code from one of functions like
IDXGISwapChain::Present. Unfortunately, you then don't know which specific draw call or other command caused the crash.
NVIDIA proposed solution for that: they created NVIDIA Aftermath library. It lets you (among other things) record commands that write custom "marker" data to a buffer that survives driver crash, so you can later read it and see which command was successfully executed last. Unfortunately, this library works only with NVIDIA graphics cards.
Some time ago I showed a portable solution for Vulkan in my post: "Debugging Vulkan driver crash - equivalent of NVIDIA Aftermath". Now I'd like to present a solution for Direct3D 12. It turns out that this API also provides a standardized way to achieve this, in form of a method ID3D12GraphicsCommandList2::WriteBufferImmediate. One caveat: This new version of the interface requires:
I created a simple library that implements all the required logic under easy interface, which I called D3d12AfterCrash. You can find all the details and instruction for how to use it in file "D3d12AfterCrash.h".
I guess it would be better to allocate the buffer using WinAPI function
VirtualAlloc(NULL, bufferSize, MEM_COMMIT, PAGE_READWRITE), then call
ID3D12Device::CreatePlacedResource, but my simple way of just doing
ID3D12Device::CreateCommittedResource seems to work - buffer survives driver crash and preserves its content. I checked it on AMD as well as NVIDIA card.
Update 2019-01-28: Microsoft is releasing a new, more powerful API for analyzing reasons of driver/GPU crash, called Device Removed Extended Data (DRED).