 I'm going to talk about 0D, particularly about 0D graphics. Who knows what is it? What is 0D? Amazing. I'm pretty surprised. It's my small plan about what I'm going to tell you today. It shouldn't be really big because I think it's the end of the day, and you are probably pretty tired, so let's get started. 0D is an open-source game, a real-time strategy about ancient warfare. We have a game about time around 0AD, obviously. The game is pretty old. Development started really a long time ago. First drafts were in 2001 or 2002, so we have already in our repository a pretty old core that we should support, and we try to improve it, but we still have it, so it makes sense. Let's talk about graphics in our game. We don't use any ready engine. We use our own engine that's pretty old, but we try to improve it each year, each release. It's called Pyroganesis. It's fully written in C++ with small C places, but it's really rare. So C++, and for rendering, it's OpenGL. As other stuff, we use SDL as most of, I think, free or open-source games, at least that I met, so it's pretty, I think it's not so complicated as QT, in example, but it's not bad for us, and we use SDL for a long time, so we're glad to have it. We use for most of the dependent things, like input-output events, like system calls, like window icons, so we don't want to depend on system calls, like from X-windows or Windows API, just set window icon, but it's small details, so don't care. The main thing that we still use OpenGL 1 and OpenGL 2 API. Yes, it's not modern, but we still use it, because, as I said on the previous slide, it's pretty old. We have to support these two versions, because I said it in other slide. So OpenGL 1 for people who don't support OpenGL 2 API. Yes, we have it. So in some places, we use old code, pretty old code, so I think that it's not really good in 2K19. We still use AIB shaders, so it's pretty assembler-ish shaders, and we use DLCLE, but still with really low version is 1.2 mostly, so not even 1.4. By the way, assembler shaders pretty equal age than compared to R. So what current problems? Old OpenGL, so we can't use modern OpenGL functions, because we use OpenGL libraries, old libraries that don't provide us stable, constant stable functions like del-doll instance, because they don't have it at all. For example, in Mac OS, mostly we don't have. Modern functions like del-doll instances, it really could help us, but currently we can't do this because we still support old players. Players with old hardware, I will see it later, but we have some players with OpenGL 1 and OpenGL 2. OpenGL 1 sounds like, hmm, I will show you. It's our feedback statistic that we started to collect from December of 2018, so you can see that this is our distribution, so you can see that we have pretty old versions. It's really our players, it's not magic players, so by numbers it's something like 25% of our real number of players, so we have currently of current stable version, we have something like 20,000 of downloads, and here we have 5,000 of feedback reports. So I think we can use this data to make some conclusions. So we still have 1.4, 1.5, and a lot of 1.1. I can tell to you that 2.1 is not only old hardware, it's also Mac platforms because as you probably know, that example for 10.14, Apple dropped their OpenGL support, so they never supported very well, so even on most of Mac platforms we have old OpenGL, so we can't use any useful for us modern functions, because of that we have sometimes really low VPS because really basic functions, sometimes we need to just draw each object, just bind VTX buffer and draw it. No optimization like single bind for VTX buffer and one bind for transform-matter cells, so it's not really good. Also we noticed amount of crashes of our application on Intel cards, especially it's not tested for particular version of drivers, so it's not old drivers. Also it's really not tested by our track system, so if you try to find something like Intel Crash, you may find a lot of tickets that we close with duplicate or doesn't have information. An example of Intel Crash, so this crash may happen even on pretty simple call, OpenGL call. An example, GL begin or GL end with simple parameters like you are drawing a triangle, simple triangle without any textures, normals or another complicated stuff. So why this is a problem for us? Because we open source game, it means that most of our developers are working on this project in free time, so most of our developers don't have this type of card at all and it's really hard to debug bugs like this because to find real reason of this, you need to spend a lot of time because what do you plan to do? You need to run, for example, debug version, you need to find call stack, also it's windows, so it's another lot of problems because you just can't go to driver and simply disassemble it, so you may use some already debug or either programs, but it really costs a lot of time. So yeah, legacy support of OpenGL drivers that I said before. It doesn't mean that OpenGL is not supported on macOS, it only means that some functions may don't work, but it probably means that we will lose the OpenGL at all at newer versions, that it's not good for us because we want to share our game with players on macOS too, but if they really drop the OpenGL, it would be bad for us in this situation, so we have to do about feedback. Currently we revived our feedback server, so now we actually collect data that users place will show you. When you start the game, you may see this button, you will see this button. It doesn't just send us some information, of course we don't enable it by default because it should be your decision to send your information. It's absolutely anonymous, but it may really help us to make some conclusion about our OpenGL version, about our drivers. So it's good if someone enables feedback. And we get some statistics here that we got from people who pressed the button. And we made the conclusion that it was 25% of all players of this version, Alpha 23 big. They released one, so if you go filter, you will see that actually about OpenGL extensions that we don't have many support of really cool stuff. So basically 100% support only really basic things, so shadows, textures, you know, nothing really interesting. So even frame buffer object, look. I think it's so good that it's really useful, especially if you are doing some post-partition. Very simple optionally, and so even frame buffer object, it's only 98%, so 2% it's OpenGL one point something. So currently what we have? We have already pretty long time we have in Krashtag that allows us to analyze really stack, crash stack that we got from Krashtag. So it helps us in some times that it helps to get real reason or real place where it crashed because sometimes it's not really obvious, especially Intel card crashes. And we try to connect with our players through track and forum. We have few really very active members who help us a lot. For example, one of our team members is Stan who really answer to each, most of each answer question of our forum. I think he does a really great job for us. So what do we plan to do with this kind of situation? We have feedback server, so we have some kind of statistics about our game, about our players and we need to understand what the audience we have. Do we really can drop OpenGL one? Because sometimes it can be really not real players. For example, you have Raspberry Pi and you just can run the game on it because you want to prove that you are able to run the game on Raspberry Pi, but you don't actually play it. So sometimes players with OpenGL one or OpenGL two are not real players and we should ignore them. So it's one of our steps to improve the graphics. Also, because the game is pretty old, we still have some places where we have got calls to OpenGL. We still have some really old stuff like JLBegin. So we should have to remove this and we should have to make more abstractions for this one to prevent a lot of places of low-level library calls. Also, after Apple news about that they dropped the OpenGL, we start to think about finding a new library that can collect JL or Vulkan calls and transform it, platform-dependent calls. For example, we continue to use OpenGL calls, but in some platforms, for example, all OpenGL calls are converted to metal. We have already, I mean, open-source, we could use Molchanvk library, but we didn't decide it yet. We just know about it. Also interesting things, white lists for drivers. For example, as I shown you, a list of cache, a simple, really simple solution for this kind of cache, just disable JL cell post-processing and cache has gone. So really simple solution, just add particular drivers or particular Intel card versions to blacklist or whitelist and automatically switch options to prevent one really incompatible stuff. So there is, for example, one library that's used in Hormium. It's called LeapAngle and it's pretty interesting for that kind of, but it's not really probably useful for us because it's used to convert OpenGL ES calls to platform-dependent calls. So it's really production-like, I think, because it's Hormium and it's home, but it's OpenGL ES and it has own limits so that we can't allow probably because we, I think, mostly PC-oriented game strategy. So thank you. I want to say that actually we find people who can help us to improve our code with graphics, with testing because there are a lot of reader cards where our application, our game may not work. So if you want to contribute in our game, you are welcome. Stan will always help you and I will try to help you too. Thank you. So how many people are actively working on the graphics part of the project in any average model? Actually, currently I am active graphic programmer of this project but also we have two semi-active, one team member and one man who makes patches for us. So it's not really much but we hope to increase the number of graphics programmers because I think graphics is really important for the game, for games at all. Also it helps artists to make the picture greater. Thank you. The feedbacks of how does it include if a hardware report is unique? Interesting question. Actually, we generate unique user ID for each copy that run, each copy of zero ID. So when you install zero ID and run it, it generates a unique ID pretty long to do not have any hash collisions. So after that the game sends hardware report and already our server is related that this report wasn't accounted before. So yes, currently we try to skip repeated reports and do not analyze them questions.