# Differences in memory management between Direct3D 12 and Vulkan
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.
# 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?