Need to translate an old podcast

[Ansel_505]

Any connoisseurs of the Russian language?

From what I understand, the podcast featured a former graphics programmer from Rockstar Toronto.

 

https://www.youtube.com/watch?v=yND7uaRGFsw

[Ansel_505]

FINE, i'll do it myself!

Used transcription and GPT-4 translator, deleted some gibberish. Russian is very hard 

 

 

Yes, I grew up and studied in Belarus, after which I got a job in a small game dev company that successfully moved me to Toronto.

It was GVL Corporation, they dealt with slot machines for bars and later casino machines. It was all serious, I mean the engine was based on OGRE, 3D graphics, shaders were good, I mean there was a lot to do, it was fun. 

 

Great, and, wait, before you moved, what did you do in Minsk? Or did you go straight into this development and go to Toronto? 

Literally, in my last year of study I was already working in this company GVL, and as soon as I worked there for a year and a half, I left for Toronto. That is, apart from studying and working in game development, I did nothing in Minsk. 

On bar machines, yeah. And I managed to create a real hit there. Unfortunately, of course, nobody knows about this hit, except drunken bar-goers who had our machines. But there was dynamically somehow built a field of emeralds, with which you had to put three together, so that they, respectively, exploded and everything fell down. Well, that kind of game, and the difference with all the games I know, that kind of game, is that you could build these combinations as chain explosions were happening somewhere, and it all fell down. 

So it was all completely asynchronous. So you didn't have to wait for it to settle and then make a new combination. It was possible to bam-bam-bam, that is, explosions, sound, everything was just like in Hollywood. 

Yes, of course, there was math, and there was asynchrony, and the graphics of drawing emeralds was very interesting. They used multilayer translucent shaders. At those times, of course, it may not go to GDC, but the class below yea. 

 

what kind of hardware was there? 

I was a game programmer there at first, then I moved to the writing team and directly dealt with hardware and ported our system to different hardware. We used custom boards and custom processors from VIA and AMD.

AND AMD. The hardware was not very strong, i.e. it was mostly integrated chips. And we had to, of course, squeeze the maximum of both loading speed and rendering speed from all this goodness.

The bosses were economizing on hardware, and every memory card was counted, of course, as it happens with us. The bosses were of Russian-speaking origin, that's why.

 

Look, here you were programming graphics in this company and I realize that it's all an evolutionary path and so on, but how did it happen that a person who was doing match 3 games for truckers suddenly became involved in Grand of theft Auto?

Well then we have to jump back in time another 15 years, just kidding, 10 years, when a great game called Vangers came out that inspired me to really get into the business seriously because it was completely different to anything else that was on the market at the time, and there were a lot of great games on the market at the time if you remember, and it made a lasting impression on me. To this day, I still think there are no similar games on the market. I mean it's still in my heart as one, unique and the best. 

I love it now, especially now, that is, in connection with the recent events, when they opened the source code, which I managed to dig into, and they re-released this version again for Steam, and also for Linux, thank them very much, I love it on all fronts at once. So it's not only a game as a game, it's a game as a technological emerald, in which everything is made so unusual, as if it was from another planet. That is the mode of this rendering, this two-layer terrane, which was built on the map of altitudes, and which was displayed on the camera projection, while the camera could rotate in different directions as if in 3D.

As far as I understand, there were really exclusively programmers working there, most likely there were 1-2 people who actually made this alien wonder.

I was inspired by this game, and I slowly looked in the direction of vangers, learned to be a math programmer accordingly. And while I was working in GVL Corporation with these bar machines, I sat at home and wrote an engine, then another engine, and studied different programming languages, because I'm very, very excited about this topic too. And one of my projects was a whole framework where you could load scenes in real time. It had crazy things like hair calculation.

Well imagine hair that's on your head, it can move. Calculating hair as a multilayered system of particles. I imagined hair as a multilayer system of particles, each layer depends on its neighboring layers. And, accordingly, I emulated hair as a system of particles, I drew it using geometric shaders. And it all looked very funny, and at that time, probably, nobody had even thought of doing that.

It was all using OpenGL Transform Feedback, that is, the results of particle system modeling, they were all stored in vertex buffers of video memory. So it was all quite fast and interesting. It was a cool experience. So where am I going with this? I was able to experiment with a lot of different technologies in this system.

I've gotten to some absolutely mind-blowing things, like stancel routing for Deferred Lighting. And on several of the technologies I've dealt with, I've managed to write articles, big book articles, here's GPU pro 3, there's one of my articles about quaternions and how to build an engine without a matrix at all. 

And, accordingly, of course, I was drawn to big money, big projects, not slot machines. And by that time GVL was safely dying despite all my efforts. What year was that? 11 or so. We're talking '11 now.

I went to Ubisoft, I talked to I think Amazon, and by some miracle I wrote to Rockstar and they wrote me back too. By some miracle it's already Post Mortem, so to speak. Because I was subsequently involved in the hiring process at Rockstar myself, which we'll touch on later. And I think it was a miracle. So, Ubisoft didn't hire me, they said that I have no experience with consoles, so fail.

Although I did the tests with them better than anyone who had done tests with them before. Yeah, right. Well, they probably just wanted to take someone ready to go, and I still had to take someone ready to go. And it's okay, thank them for not taking me, I'm very grateful.

And anyway, I came to Rockstar, how I did the interview, I guess it's very interesting too. Yeah. So it's a dark room. 

As I rockstar moved to an office and another office and this old office here it was actually with something. I looked in there literally once and there were slot machines that glow in the night. That's about what it was like in the office in the middle of the day, of course. The new office, they say, is much brighter and prettier compared to the old one.

But I've only worked in the new office too. So, the new office is still a dark room, with two leads and the president of the company directly asking convenient questions. Why convenient? Because no one wanted to tinker, no one was interested in testing my knowledge. Basically, once it became clear that, like, I had articles in books, they just had something that resonated with them, and they said, Okay, this person can write.

 

If there are publications, then yes, if there are publications and books, it makes a big difference, because people know you a little bit in absentia: Oh, okay, this dude seems to know his way around. Conditionally speaking, that is how you try to show that you are smart during the interview and how many hours are allocated for the interview in this company, but you had all your previous life to do it, you wrote your articles, you showed that you know the subject and it is easier for people to understand you. 

 

Absolutely. Sergey, there is another peculiarity of programmers that you probably do not see so much. We still have open code repositories.

And at that time I had a huge amount of code on Google code. You could study and learn everything about me if you wanted to. But, naturally, no one ever read that code. I'm sure of it, so nobody ever read it.

 

And I for one think reading other people's code is so honest, it's the most hated thing you can do. 

It's the very thing that makes you a better programmer.

 

Let's move on, well these people listened to you, found out that you write books, something clicked in their eyes, so they hired you.

Attention, everything I say is my personal opinion and has nothing to do with the company.

Yes, on the agenda it turned out that the office is not dark at all, very bright, and quite free, we have seen and more dim, kind of dark places. Naturally, the company tries very hard to take care of its employees, we are given very powerful machines, I have never seen such machines in my life, as I am not a rich man at all.

And there are 16 cores with 32 gigabytes. Well, this is at least what I have now, then it was more modest, but as if the power, the power was visible, everything was nice, good. Video cards what we want, too, respectively, all the conditions. 

 

Okay, you got a job at Rockstar. You have great machines. What's it like working for a company like that?

 

At first it was very strange to work, because as it turned out, now we are moving a little bit to Max Payne. It turned out that at the time I came in, Rockstar Toronto got the helm of the Max Payne project from Rockstar Vancouver. So you if you played at the end, you saw that game by Rockstar Vancouver.

We actually turned it in. We were shipping, tweaking it, we were combing it, we were turning it in. And it was very frustrating for us that the credits didn't really talk about us.

The credits were about those who started the game, not about those who finished it. So we were given this game, the game was not ready, we had to keep the deadlines somehow, we had to finish the console version as soon as possible, and then the PC version as well. And the code was quite scary. Well, I'm not saying that the code was bad, but it was very complicated, and it wasn't easy for me to understand it at first. All I did was to fix it at once, fix a lot of bugs.

And in this respect, as soon as I came, I saw that people were working 50 hours, not 40. When we moved a little bit towards the release of the game, it turned out that people were already working 60 hours. And when I as if nothing happened I came to my 8+ hours for lunch a day and left. I was looked at so obliquely, and I eventually even received a warning as if from the president, I say well do not demoralize the team, please. After that, another such warning, and then I realized that I probably need to work like everyone else since I came to gamedev need to feel the atmosphere to the very thread and bones need to so that at four in the morning you were still sitting in the office and your eyes were slipping, and you fixed the bug, which tomorrow should be shipped. I wanted a little bit of that.

So I started working like everyone else, and the code base was a little bit scary. It often happened that you fix a bug and bring a much worse bug into the code, because the device is not obvious at all, and there are traps everywhere, and rakes, and this is the way it is. Now that's not bad code by gamdev standards. I realize that everyone has their own business requirements as to how much time should really be spent on the quality of code, and how much on writing it and forgetting it. So as a business decision, it was probably done right.

Especially because you know the game turned out really well and especially we got great reviews from PC players because the game scaled quite well on good hardware on many GPU systems and many screens even. So this is one of the topics that I dug very deep there, that is actually I realized all the multi-screen support for Max Payne so that AMD Infinity, NVIDIA Mosaic all detected, all of our configurations were supported. So you could put 3 monitors, 2 monitors, 1 monitor, 1 on 2 monitors, whatever you want. Yes, that's all, that is, within the framework of some universal system I had to realize and get in with my tentacles into all parts, into all subsystems of the game, so that they all respected my central config.

 

By the way, I can say that I got to Max Payne about six months, maybe a year ago, I finally got to it, I went through it with great pleasure, because at the time of its release I bought it, I went through the first two missions, I didn't like something, so, you know, I put it aside, something doesn't go in. And then I finally launched it, I went through it in three evenings, it's probably 11 hours there, with great pleasure. It's a good game. 

 

It's great, it's great. I went through it with great pleasure too, I even played multiplayer, I loved it.

What I still did on Max, remembered when I saw the amount of bugs they have in the production of video works. Bink player.

 

That was something, some tricky conditions there, some, you know, synchronization with text. Everything was very bad there, and after that at some point I just decided and rewrote the whole module of interaction with Bink, made it completely asynchronous, and the number of bugs, it immediately decreased by 90 percent. And accordingly, before the release, I fixed the remaining 10 percent. That is, it was mostly just those exceptions that had to be made, not those that just happened to be in the code. And as it is, we played Bink very well, and I'm happy with the way it came out.

Good. Counter question. Let's say at Wargaming, do people play games in the office there?

 

At Wargaming they play, at Epic Games they play. At Wargaming depends on the studio, actually At some I know there was an hour of gaming, taken out break. When you can play at work accesses everywhere open up, everything works. Epic necessarily has an hour of play time too 

Paragon, Fortnite, Spyjinx or anything like that is usually encouraged. That is, if not, well, as we have internal releases, they come out once a week and these days it is mandatory, that is, the team must play because it is an important release you need everyone to pile on and test, because well, who else to test but development. QA is naturally there, but it's easier when everyone is there. And the rest of the time you are not obliged to play at this time, but it is very desirable because there is little chance that you will catch something else.

So you kind of have to know the game. You know, it's specific. Here in Wargaming there was no such mandatory hour, it was voluntary, you can not play an hour. That is, there were evenings when you played your own project, but there was no such thing as an hour every day in Wargaming. At least in the studios where I was.

 

Maybe some of them do, really. We had very different things. That is, there were people who played a lot and often, not necessarily one hour. There were people who never played at all, as far as I could see. I mean these are the kind of laborers that I look at all the time with fear and I'm scared even.

Because if we fight for the same position, I probably will not have a chance. We played Dota with the guys there friendly such rockstar team, rubbed was very fun and rallied the team. 

That is, we entered the crunch as soon as I got a job in 2012 from the beginning of the year and we left it only, probably, when the PC was already sent to print, that is, a year later, roughly speaking, we had a crunch for a year. After that there was probably another six months to a year of such a free regime, when you could actually work 8 hours plus lunch and calmly, without straining yourself even to play games, to be with your family a little bit in this way, to take vacations, after all.

 

By the way, there's a very interesting question there. What was the most difficult thing for you in developing such a big project? 

For me it was difficult that I had never worked with DirectX before.

As fate would have it, I had to work with DirectX a lot in Max Payne and do all sorts of tricky things there, discover the peculiarities of the DirectX runtime, first of all. 

In the process of production there it's all quickly comprehended, at least the basics, how the class system works and how resources are created, When you deal with it, it all automatically settles in your mind. It's just a huge flow of information that you combine simultaneously with the fact that you're crunching and trying to fix hard-to-find bugs that you didn't write yourself in someone else's code. And these three factors together, they had a very, very strong effect on me, and I really wanted to run away from it. During the development of Max Payne, I didn't feel very good, not even very good, I would say.

It's just the kind of time I came to, the kind of time when it was good to come but bad to work. I mean, that's exactly what I was going to say, the way Rockstar hires its employees. It's not that you're smart or cool, it's just that you have to do it now. And they'll probably accept it then. You have to be in the right place at the right time. It's very simple, yeah.

I just got lucky. I mean, I don't know if they would have hired me if I'd come at a time like this. Because when I grew up and I became a senior count, and I was helping our lead interview comrades, we had these guys coming in, just real brains in general. Blackberry came in, a dude from Ubisoft came in, a real veteran of the industry. And we didn't hire them.

Just because it wasn't the right time. I mean, I don't know why we invited them for an interview, but we didn't hire them. Although everyone liked them. 

 

Yeah, here we are touching on a little bit of wave development, and what is, how does development even happen at rockstar? I mean, there are several studios around the world.

The main two are in the UK and California.

And so, you come in and you have to interact immediately with the ones in the early time zones, which is the UK guys. You leave, you're kept busy by the San Diego guys and constantly being yanked around, And so, especially for Toronto, you could come in early, leave late to catch everybody. It's probably not like that in other offices because we're in the middle. 

Yes, so, I've heard reports that the guys from America, actually, they work very hard, from California, that there's constant overwork and constant pressure.

I can't confirm or deny myself. In the UK guys work exclusively the hours that are written in them, and moreover, at 4 o'clock there, and what time they have mandatory tea party, there's no way of that. And that work-life balance there is very, very nice, if anything, you mean. 

By the way, how is it in Canada with this? Is there mandatory vacation of some sort there?

In Canada, we are strongly asked to take vacations. Because if we don't, they're in trouble.

They would probably legally have to pay us back for not taking vacation. But I don't know of any real cases like that. It seems to me that everyone so far has either taken, or they were somehow verbally on agreement to carry over to another year just for vacation. But no one has lost their money.

About youtube, what I would like to say is that rockstar is a great company in this respect, they value their own human-motivation, and you can do whatever you want at work, you can probably do nothing all day long. If you're really showing good results and you're doing your job, you'll be treated favorably.

We write quite a few reports though, and I won't even say how many, but it's hard too. Here, I have this model of how our office, at least, works, roughly like a cauldron. That is, people get there in some way completely different, because mostly depending on circumstances. And in this cauldron they form such phenomena as in the early stages of evolution of life.

That is, someone bursts upwards, someone finds reserves in himself, improves himself, creates some stunning things and advances technology. Someone on the contrary feels the pressure, settles down and just stays afloat. These are very different people. In our office you can find a variety of just different forms of life. So they may not be optimal conditions for development, but they are there.

If you are interested in gamemaking and you have a burning eyes, it will be great for you there.

I remember that we had a comrade there who didn't have much time, he worked mostly at night, when no one is there, I don't know, because of his family situation, maybe. And he came every day for some time and couldn't do anything. And when they started to find out, the lead went to the IT guy and said what's up, why can't a person do anything?

Let's find out. It turned out that he came every day and started synchronizing all the data and all the code of the game. Naturally, it usually took almost a whole day. 

 

Wait, what do you mean he started synchronizing? Why would he start synchronizing?

Well, he wanted to work fresh, I guess. He thought it was normal practice, because a man works in isolation. I'm telling you, he works at night when no one else is around. These are such strange stories. He left us, of course, probably not of his own free will.

There was another person who came to us, and for 8 months he distracted all the graph programmers to help him. He did something with our combined efforts and then left. But then we still had to trash it for another four months with what he did.

Which basically says that we don't have an ideal hiring process, we don't have an ideal quality control process. Basically, there is still a lot of work to be done. Which says a lot about the fact that the president of the company is a very hardcore programmer. He's probably doing a little bit of something now, I'm not aware of it at least. But he used to be known for writing for Sega, games.

So he's such a hardcore fellow, and that kind of dictates kind of the whole, I guess, work of the company. If you're a programmer, it's easy to get along with him, at least. 

It's very rare that people are fired for failure to perform, very rare. That is, if you are caught, you just might stay afloat for quite a long time. The company tries to shut itself off from the world

That is, those who are inside, those who let things happen inside, like in a cauldron, and those who are outside, please stay out of our way, do not interfere. It's like this. 

 

What do you do in the development cycle, graphic programmers, who do you communicate with and what do you do in general? 

 

Yes, in the development cycle we are present at all stages of development.

That is, pre-production graphic programmers, as a rule, develop new technologies They roll out some things like froxils, there are all sorts of Ambient Occlusion effects in real-time, Experimental technologies that need to be evaluated, whether they can be in production or not. Then the artists, of course, in pre-production already draw everything actively, in production they also draw, we realize the plan in production. According to the plan, we need to have, let's say, such and such technologies.

The plan is made, I understand, by the graphic lead programmers on the project, usually one such fellow together with some technical director, and we graphic programmers realize this plan. As a rule, all this is realized at a normal pace, that is, without hurry. That is, everything is civilized, everything is cultural. And at the end we have an ass, because naturally we have to finish some things that we didn't have time to do in production, and we always want more than we can do, right? And along with that we have to spend more and more time on some urgent bugs, that there's some release, some demo, or some video to record, and something doesn't work, somebody's head is off somewhere.

That kind of thing. It's harder and harder for programmers, and the most crunch for us is just in the area of preparing for the release of the game, directly releasing it and patching the first holes in the game. That's why graphic programmers, we always follow the development, we are always involved. The only small digression is that this very pre-production I was talking about, the most interesting thing, you know, the most interesting thing, is not given to all graphic programmers, but only to those who start leading a project. Accordingly, while one project starts, another one ends.

And it's the big studios that start the project. And we, Toronto, we in terms of programming, we're a small studio, and we don't start projects. At least I haven't started any projects. And all I've seen is that we helped finish Max Payne and, of course, release it. We were very active in the development of GTA.

There's no doubt about that. But we didn't start that project. That is, we entered it already in the process of production. So we didn't get a lot of the sweetest things. With you with those who work in California or in the UK.

 

So it's not a very creative part, is that what you're saying? 

 

There is room for creativity, it's just that you are not given so much time to dabble, let's say. 

 

So if we're talking about porting, you're adapting other people's code for the platform, and it's clear that you're writing solutions for things that have no direct analogs, but how do you combine these things? Yeah. Research and porting? 

 

Research work, it's accessible to a few people.

I find these tasks the most interesting. Very few people in the company. They're really capable of performing such tasks. And so you need both ability and initiative to negotiate with your superiors to be allowed to do such things. 

And we were always sitting there, literally writing pages in integrals, trying to prove some formulas to each other. For example, we called it bounce map, that is, a dynamic system of reflections from the terrain.

It was really scientific activity. But the percentage of this compared to the overall development process could be 30, maximum 50%, less than half in any case. 

 

But the question is how to say it right. You have conditionally From the computer you have a scene that should be rendered in 60-30 frames.

And on consoles I understand approximately how it looks like, because you have a budget there and part of this budget is allocated, actually, for you drawing, that there is left for everything else. And there I roughly understand what this work consists of. Let's say, I have to make it look as good as possible within my budget. And how does it look like on PC? 

 

Well, you take a particular configuration and say that let's build a budget based on this configuration.

If the configuration changes, then accordingly some things are revised, somewhere they are trimmed. Well, there are budgets there too, and in principle a little bit softer, but similar to the process of development for the console. And of course, if someone has doubts that PC is developed post facto, I beg you, everyone develops PC from the beginning, it's just that PC release is not a priority, that's why it's released later, but it's a pleasure to develop on PC, that's why many people do it. 

 

And otherwise there wouldn't be all these beautiful videos of games that look much worse on consoles.

 

if anything, have absolutely no idea how it's done. As I say, the company is closed, and this closedness, it is not only the outside world, but also between the different departments. I mean, what marketing does, there, is completely unknown to me, what the plans are for the release of the game, I learn from the news just like everyone else. The only thing is that maybe some urgent bug will come a week before that needs to be fixed and the main programmer himself will ask me to do it. But it will be just a hint and not a concrete notification.

 

So, a question about typical tasks and problems.

Yes, a typical task and problem. A typical bug somewhere something is, let's say, flickering. You're sitting there trying to figure out

Or let's say a strong reflection somewhere. And in the development process we usually implement some kind of smoothing system for reflections so that it's smooth and good. Basically, what we use in the process of work is of course very much playstation, because it works well, fast and utilities for its debugging they are more debugged, probably, than for Xbox.

 

For example, bad FPS is it to you or maybe because of another something, how do you interact with the other department? Maybe there's a logical person there that messed up. I'm just exaggerating.

 

It seems to me that we are often the extreme ones, that everything starts with us. If there is a problem in resources, then we need to find out what the resource is, why it is problematic, and specifically direct it to the department with full information about what went wrong. We are the easiest ones to blame, because after all we are responsible for the appearance, and a lot of the problems of the game they manifest themselves in some aspect of the appearance.

 

Well, because more often than not, of course, players blame the graphical part, because they are what they see in the game and it is a great responsibility to make everything work properly will not be there I do not know well man to explain somehow differently. He sees that you have something lags, so the graphics programmers all screwed up. So how do you feel all to blame? 

I want to tell the players that we are indeed very often to blame. We have a difficult profession, and the most difficult thing is that there are many factors that do not depend on us.

In particular, if we talk about PC, there is a huge variety of hardware and drivers, which behave completely differently, and from one update to another, the behavior can change too. It's not even a joke that we had a bug in GTA, which appeared on AMD and which probably hung open for two years until it was fixed in the drivers. So they were the ones who knew about it. We worked with them. But it was real and it was difficult for them and us to come to a solution.

 

For example, in every game update we write the recommended drivers at the bottom, and our recommended drivers are still May drivers, because the more recent ones work worse. Do you have such a tradition too? 

 

We have it for sure, but we don't report the recommended drivers, but AMD and NVIDIA choose them directly and tell us, I guess. That is, I don't participate in it, what drivers they choose. As far as I understand, they have a rather long cycle of transition from a fixed bug to a driver, and, accordingly, at my stage, when I say that you guys have a problem, let's solve it together, and they say: okay, we fixed it.

At this point I'm breaking away, and then they have another three months, they somehow coordinate it with our guys who release updates and so on. That is, it all passes us by. 

 

I have such a simple question: how do you realize that this is a bug in the drivers and not your fault? At what point does this secret consciousness happen?

 

And here it's actually simpler than it would seem. You just test on a competitor's video card, and if there it behaves the way it should behave, according to your understanding of the problem, then it's most likely a bug in the driver. Fortunately, great tools like renderdoc have come along.

If anyone doesn't know, it's like manna from heaven that fell from nowhere. Comrade develops completely in open source, and it wonderfully allows you to debug any problems. 

And what's more, it can be different on different hardware, that is, we give them a snapshot, so to speak, of our test part of the game and say: Here's what we see on this video card, on this one, please test it, and then they fix it themselves, as a rule. Here, and such bugs happen quite often, something pops up there, especially, as far as I remember, there were big problems with, you know, depth buffer and stencil, they can be marked as read-only in DirectX, even when you connect them as for rendering. That's what you need in order to do a test, but not to write anything to them. And when you do something non-trivial with these flags, for example, you connect the depth buffer for writing and the stancel buffer for reading, the drivers often go crazy and behave strangely. After all, we try to avoid such situations in game code.

I just that drivers are also not omnipotent and in many ways the problem is in these APIs that provide us I when I started to talk about what I learned DirectX there at work I even wrote an article on my blog, what directx is bad. I was so outraged by it in the background. After a certain period of time when I grew up and realized the essence of life for me now directx, especially its 12 part is simply the best that there is among APIs. That is better than Vulkan, better than Metal, better than everything else.

And I'm specifically commenting on the specifics of the API architecture itself. That's a little bit different. Here, and in this respect, DirectX 11 was a breakthrough. That is, it was such a breakthrough that OpenGL still can't catch up with it, because OpenGL drags a huge number of outdated concepts behind it. Take the simplest thing.

Texture in OpenGL, it actually combines three different concepts that exist as three different concepts in DirectX. It's the texels themselves, the texture data itself. Then it's the view, It's the way that we interpret that data in order for the texture to reach the texture. You can do that in many different ways. You can see 1 byte as, say, a real number from 0 to 1, or you can see it as an integer from 0 to 255. But that's if it's trivial.

Here. It's a separate object entirely. There can be several different views per texture and exist in parallel. And in the end it is a sampler, which allows you to read and interpolate data from this structure. This is also a separate object in DirectX.

In OpenGL, it all comes in one cluster. They've certainly put concepts on the side, meaning you can still create your own kind of view and your own samplers, but the fact that the default texture it still comes as a three-in-one, just for compatibility, it just kills me. 

About Vulkan, I found it to be oversaturated with functionality. And it's very complicated to write anything by hand. It's really not for mortals, it's for engines. And it's because of the fact that it wants to embrace the vastness, I mean it wants to run perfectly on this PowerVR, or whatever they call it, mobile data?

Architecturally, I like DirectX 12 the best because it's the simplest. It opens the door for optimizations in the driver while still allowing drivers to stay very thin. At the same time Vulkan, it has so many different concepts, especially these render passes here.

 

They allow you, roughly speaking, to use the results of processing one shader temporarily to enter another shader, while not writing and reading video memory. That is, this pixel is drawn, and instead of going to some render target in video memory and then being read from there, it can simply go one-to-one to the input of another shader. And you can build a whole graph of these renderpads, and it's all beautiful, and it's all just to satisfy these tie renderers.

 

Look, well here you said how Vulcan is overpowered and Vulcan is primarily for engine builders, but it's the same thing they say about 3D12

 

It's just simpler, on it, it seems to me, you can really sit down a programmer, read the documentation and start labbing some demo. That is, yes, it will not be super convenient, it will not be as convenient, maybe, as DirectX 11 or as OpenGL, but it will be a real task. It will be unreal to write something on Vulkan, i.e. to kill yourself and not get up at all. 

Besides writing engines, I just like to appreciate the beauty of APIs. And DirectX has managed to embrace the same concepts on which Metal and Vulkan are based, easier and more flexible than all the others. If you take the concept of Pipeline StateObject, which is the root actually for all 3 APIs, they in DirectX collect data about everything that deals with what the shader, that is, and render targets, and all all they have all part of this pipline state object, everything is logical, everything can be predicted, but in Vulkan need to have a separate state object, separately there is this render pass, which has information about your textures.

And the problem is that in this state object, you have to specify, let's say, such parameters as blending or depth testing, right? And in the render pass you specify specific textures that should work with this blending and depth testing, so you're supposedly concepts that are inseparable, depth testing and self-adept texture, they're inseparable things. And you can't use them separately from each other. You're separating into completely different objects that you're binning independently of each other. That's not pretty.

This one is beautiful. This is the one that I suspect you can still create debugging headaches when something doesn't work. Oh yeah, RenderDoc is said to support Vulkan, but I haven't played with that yet.

 

Let's just forget Max Payne for a second, there's time left. About GTA I had the opportunity to participate in very interesting subsystems gta that really they just exploded my interest in gamemdev that is what I wanted and that is what I was waiting for all the time to work on gta it was an epic game in some ways in terms of technological point of view.

I mean, starting with the fact that I was in a top-secret group of a few people who were locked in a room, given the newest Playstation 4 development kits that no one else had, and told: Go ahead, burn. Nobody had the right to walk past us and look out our window, because we were doing it all by ourselves. It was really fun. So we developed such, you know, a combat unit on our own, which ported to a secret iron platform with super performance and architecture. Naturally, we were not the first, that is, before us, the lion's share of the port had already been done by a system architect from San Diego.

There was nothing we could do about it, but we directly finished the game and made it work. He mostly worked on the low-level parts. So, when we made GTA at 48fps in a week or two, we were just shocked, it's amazing. It's so beautiful, it's such a great console. It was very raw, though.

 

The development and debugging utilities on both Playstation and Xbox were just horribly awful at first. But I think you probably had that touched on already in the podcast. It's not a new topic, I'm not opening anyone's eyes. It's not a surprise new hardware has bad, bad utilities. It's only now that they're getting some kind of acceptable form, only now.

Directly we worked mainly with playstation, another studio worked with xbox one, so I can't speak for xbox one, but we solved a huge number of bugs with them, and, to be fair, Sony was very responsive, very smart with us to sort out all the bugs, and that's the positive impression left from the development for this console. In this respect, the new console, it did not interest me in any way, that is, it's just faster, that's what I noticed from it. It's compatible and it's faster, yeah.

 

I mean playstation pro. My opinion is that if they are going to actually downscale from 4K to 1080p, and they doubled the performance for the sake of it, why the hell do they need it? I don't need something like that. Now, if they wanted to do 1080p 60fps, that's it, I'll take it then.

 

No, you can do 1080p 60fps.

 

Okay. One of the interesting tasks in GTA that I got to work on is tessellation, which is the automatic breakdown of polygons into smaller ones on the graphics card, which involves two new stages of the graphics hool pipeline and the domain shader.

Even actually two and a half because the hool has two different functions that run independently of each other. So this was all so, you know, new, completely incomprehensible and complex. And I was given the task of making sure that we had a good tessellation on PlayStation. So I did it, and then he said: Make it adaptive, so that you run closer to the tree and it was more detailed. What's next?

Well done. Good. And then he says: Now let's do it in such a way that this adaptability is completely smooth, and there are no such hills that appear temporarily when you approach. Here I start reading and realize that this is such a deep research topic, that many people have proposed their own solutions, that there are a huge number of blogs and speeches on how to do adaptive tessellation correctly. And accordingly, I was developing some of my approach based on what I had read about how we do it.

But the amount of math involved was not insignificant. Understanding how texture units work, how to properly sample everything out of them. That was really interesting.

Well, I think that only the basic part of what I was developing, it went into the game, because they decided that it was fine as it was. So it's there in the off state for the most part. Experiments, so to speak.

Yes, everything works beautifully. I was running around in GTA myself, looking at those trees. It's just beautiful. I love the way they've done it. . .

So, about GTA I managed to really lead the project on the antialiasing system, that is, I realized our architecture on antialiasing on PC and on consoles and there developed new methods that are available only for these consoles, using their AMD new hardware, which were not even originally. That is, no one in the API even thought that you could use their technologies in a way that we were able to use and stitch the game even using those technologies. Well, on PC we defined edges there and, accordingly, we tried to do supersampling only where it is really necessary. That is, if you have a polygon roughly speaking with a texture, then inside the polygon we will process only one pixel. On the edges we will process all 4 or 8 or however many samples you have in this MSAA mode.

So that kind of optimization was also a lot of effort to get right, because it's one thing to make a small demo that will work, and another thing when you have an open-walt game with a thousand different materials and features, and it wasn't easy to cover all of them. And finally, yeah, I don't talk much about what I've been doing since GTA. It's mostly low-level work. I mean, I went lower and lower. I started out as such a high-level Game programmer and slowly slid down to architecting and low-level API and engine building.

Even if we didn't tell about our technologies at Siggraph and at GDC, they are still pleasing to users' eyes and that's the main thing for us.

[Ansel_505]

 

I thought you'd be interested in this.