people here talk like you can optimize a game without sacrificing visual quality. i don't know, is that possible?
yeah remove the 200 godrays and particle explosions the game doesn't sneed
>>719625092yes, read up a brief on algorithm optimization
>>719625092totally doeable, nobody fucking acres about the pores on the characters faces or how realistic the light looks though foliage
>>719625092>>719625347Control has rays and explosions and still looks better and rund better than UE5 shit.
>>719625347>>719625396>without sacrificing visual quality
No.
>>719625092Yes: for example optimizing inefficient code or atlasing textures to reduce drawcalls
>>719625092retard
>frogposter>worthless threadPage 10 it is
>>719625092you can even pre-bake lighting. The issue is that explicitly ignore optimization for speed of creation
>>719625092Most modern games are shit and I wouldn't know how to respond to you if you can't even run 8th gen games at max settings and have 1440p 120fps.
>>719625932>explicitly ignore optimization for speed of creationAnd yet AAAAAAAAA games development is taking fucking decade now
>>719625092YesFor example, a lot of games nowadays generate retarded amounts of shit for no reason, as in, having water under the entire map to give you an easy exampleSaid water would be constantly rendered, you can't see it, it serves no purpose other than it being easier to just fill everything with instead of having it only in lakes or not having to fix a bug an intern didn't know how to fix when creating spots of water, but it is eating up your FPSA LOT of games have shit like this
>>719625932Rasterization only works if the game isn't an open world day night cycle thing that needs dynamic lighting to be believable. Which is pretty much all major games of the last 15 years.
>>719625092You don't need hyper realistic slop with ball shrinking mechanics
>>719626986you don't know what rasterization means. please stop posting ITT.
>>719625092Only doable if there are people with intricate engine knowledge on the team, but that's rarely the case these days, so the only option is to downgrade the graphics.
>>719625092think of the game as a black box. user input goes in, images on the screen come out. is it possibly to make the stuff in the black box happen a little faster? yes, if the devs have left any inefficiency. and a game that is already perfectly efficient is unlikely, and getting even less likely as games get more complex.
Well, it obviously depends on how efficiently it was implemented originally! But in practice contemporary games might even have laggy inventory screen with just a handful of items or whatever, so there's almost certainly room for substantial improvement. I don't know much about graphics programming specifically so I'll pick mostly non-graphics related examples, but there's several categories for potential improvement, and I would imagine there are graphics programming analogues to the things I'm describing:0. Not doing unnecessary compute. For example, in a perfectly naive implementation you render what's in front of the "camera"... even if the objects are behind an opaque wall. Since you couldn't see them in the first place, the scene looks the same without them, and it's very likely cheaper to check. I'm assuming this one is an "obvious" optimization all serious graphics engines do already, but I reckon there's plenty more of these sort of tricks.1. Optimizing assets. For example, if you have a model with a hundred thousand polygons but there's no place in the game where it's visible any closer than at a hundred meters distance, it will render identically if there's only a hundred or a thousand polygons. Or, if the objects are typically at greater distance, you can create separate models for nearby and faraway objects.2. Different rendering techniques. For example, knowing how optics works, you might assume ray tracing works by following "photons" emitted by a light source on their way to camera, but as a matter of fact most photons scatter into the atmosphere and never reach the camera, so RT uses a trick where (like in Platon's theory of vision) the photons are in fact emitted from the camera and are followed until they reach the light source. At least at the limit the implementations would look the same (all else being equal), but actual RT is far more efficient.
>>7196278273. Better algorithms: This probably is more about game logic, but if rendering the frame is ever bottlenecked by waiting on game logic (and I see mindboggling stuff like sorting an inventory with a hundred items or finding a path for an unit in a 100x100 grid map taking a better part of a second, or any noticeable amount of time whatsoever), then it would also affect frames. The archetypal example is sorting items in an array from least to biggest and you might want to check the Wikipedia article for sorting algorithms. There are completely dumb ways of doing this (Bogosort: putting them in random order and then checking if they are sorted, repeat if necessary), there are sensible but inefficient ways (bubble sort), there are good ways (like heapsort and quicksort) and there are even better ways that aren't universally applicable but perform better on certain types of datasets (like radix sort). Sorting algorithms in particular are the kind of stuff students would learn in their first year as CS bachelors, but you know, nowadays not everyone is university-educated or self-taught in the curriculum... Hence, truly insane stuff like perceptible delays on sorting inventory.
>>7196278604. Better implementation of the algorithms: The choice of algorithm determines how the runtime scales as the problem gets bigger (like more items to sort in an inventory), but you can implement its logic better or worse, depending on the characteristics of the hardware you have. For example, a Chess-playing algorithm might call for constructing a list of legal positions a piece can move to, and you could have implemented it in such a way that position of the piece is represented by column*row, such that e.g. a1=1 and h8=64, and you can construct a list of positions a knight can move to by calculating (column+2)*(row+1), (column-2)*(row+1), etc. (and checking that these are within the bounds of the board) OR... you can represent piece positions as 64-digit bitboards (conveniently, this fits to the word size in 64-bit computers) in form of 000...1000 where 1 is the position piece is in, and then using bitshift operations (e.g. shifting 00100 right would become 00010), which computers do in one instruction rather than several. Another, in practice even more impactful, example would relate to table indexing: when you are going through lists, the CPU retrieves parts of RAM to its faster registers, but if it checks each column first and retrieves a row of data (because they are stored in adjacent memory addresses) to the register, a new chunk of memory has to be retrieved every cycle.These sort of low-level details probably matter a lot in graphics programming too but I can't provide any examples.
>>719625092I am still waiting for better skyboxes than fucking Lotro in a gameIt's been more than 20 years and they've only gotten worse
>>719625092does the leather strap on a backpack need to have a 3gb 8k texture?does the 3d model of a pencil that is just ambient clutter that is only ever seen in passing and not typically inspected up close need to have 450000 vertices? Do I really need to install 120gb of audio for other languages? Are people really changing their language settings that frequently?In the same vein, does every piece of audio need to be stored as some ultra high quality lossless audio codec?yes technically cutting back on things like these is a choice to reduce visual/audio quality, but in 99.999999% of cases it is entirely unnoticeable during normal gameplay and would improve performance tremendously.
>>719628213>3d model of a pencil that is just ambient clutter that is only ever seen in passing and not typically inspected up close need to have 450000 verticesKek seen these more and more in recent games. It's easy to see from ripped models.
>>719627904>>7196279045. More appropriate tools. I haven't used Unity or Unreal or any of such engines, but I would hazard a guess that these sort of generic engines undoubtedly, for example, have an inheritance (in object-oriented programming terminology) hierarchy where GameObject class inherits the properties of Object, and is in itself inherited by DynamicGameObject, which is the basis for GameCharacter, etc, etc. And because the generic engine has built all kinds of variables and functions the developers MIGHT use, these get ridiculously bloated. Or, by default the rendering might take place in several stages, some of which might be altogether unnecessary for certain types of games. I'm kinda just guessing because as said I haven't used any such engines, but I find it intuitive that they pretty much cannot be as good as a purpose-built engine (equally well made). Certainly, knowing something about enterprise development practices, the ridiculous inheritance structures in OOP using 3rd-party libraries can mean "simple" operations take a long time, a friend of mine told me about some Android app crashing because it reaches the limits of stack size, and I doubt gamedev is much different if any.6. Different (and computationally cheaper, possibly VASTLY cheaper), but possibly better. A sort of a trick answer, but sometimes e.g. sprites with pre-rendered backgrounds look better than a 3D game. Or "clean" models without self-shadows and bump-mapping and motion blur and piss filters, etc, a look characteristic of e.g. Source 1 games or WoW or generally games from that era over more detail.
>>719625092maybe don't render the dirt in the character's skin pores
>>719627152Anyone can put a pretty pig as the sky box this isn't impressive
>>719625092>>719625515>people here talk like you can optimize a game without sacrificing visual quality. i don't know, is that possible?BTFO, game development industry is filled with griftershttps://www.youtube.com/watch?v=TuaG56SfSeo
