859
Rule
(lemmy.world)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 17 May 2025
859 points (98.6% liked)
196
17627 readers
904 users here now
Be sure to follow the rule before you head out.
Rule: You must post before you leave.
Other rules
Behavior rules:
- No bigotry (transphobia, racism, etc…)
- No genocide denial
- No support for authoritarian behaviour (incl. Tankies)
- No namecalling
- Accounts from lemmygrad.ml, threads.net, or hexbear.net are held to higher standards
- Other things seen as cleary bad
Posting rules:
- No AI generated content (DALL-E etc…)
- No advertisements
- No gore / violence
- Mutual aid posts are not allowed
NSFW: NSFW content is permitted but it must be tagged and have content warnings. Anything that doesn't adhere to this will be removed. Content warnings should be added like: [penis], [explicit description of sex]. Non-sexualized breasts of any gender are not considered inappropriate and therefore do not need to be blurred/tagged.
If you have any questions, feel free to contact us on our matrix channel or email.
Other 196's:
founded 2 years ago
MODERATORS
I already know that people are going to excuse this practice or say it's progress but it's not excusable, space wasting is a big problem in modern game development. Especially since modern games do not use the same optimization, such as the fact that you do not need to store duplicate rotated or mirrored versions of textures. Since one idiot I've met on Lemmy doesn't understand what that means and thinks I'm talking about actual mirrors. Here's a short demonstration.
Here is an example of a texture tile from an RPGmaker game. It's a lower quality but this concept does scale up and really applies to any game where textures are stored images and not solid colors or AI generated on the fly (basically the vast majority of games out there).
This is an example of Mirroring or Reflection. Yeah that's right the word mirror can refer to a transformation I know wild but for people who are actual game devs you should know this already. Even though this texture is small if you have a lot like this which could easily be mirrored it can add up fast especially with larger textures.
This last one is called rotating, it's not always ideal since some textures are orientation sensitive and could handle being mirrored but get messed up in tiling if they get rotated. So it can't always be used but should be used in cases where it can be.
Both of those are very computationally cheap and simple ways to save space on textures by only having as many as you need to paint the scene.
Another way to optimize is to simply use lossless compression schemes, which these images are already doing since they are .png files. This might seem like a no-brainer but I've seen many modern games which store textures completely uncompressed and waste a lot of space, especially for bigger textures. It also applies to FMVs and animated textures too. Use lossless compression standards for your assets, I really shouldn't have to say that.
Finally one way to reduce size dramatically is to just omit assets that aren't needed. If your machine isn't 4K capable or doesn't have a 4K display than 4K or higher graphics aren't going to do you any good and are going to be a waste of space. Most games don't let you omit them during the download process but worse, some games complain or redownload them if you delete them, despite them not being used at all. Basically these games could fit in a smaller size but they just don't because they have duplicate unused assets that could be removed but either make it difficult or don't let you at all.
The problem is, if you used normal compression formats, you would have to decompress them and then recompress them with the GPU supported formats every time you wanted to load an asset. That would either increase load times by a lot, or make streaming in new assets in real time much harder.
There are still other compression schemes which can be used to save space, and not compressing anything is a bad idea, it's not the biggest waste of space but it is a waste.
Is there any way an additional decompression step can be done without increasing load times and latency?
There are a number of compression algorithms that prioritize decompression speed, usually at the expense of higher compression times.
It can actually be quicker to store them compressed because memory and bus bandwidth is often a bottleneck. So instead of the cpu or gpu wasting cycles waiting for data to be moved, some of that movement time is shifted to the processors by using compression. Especially if there are idle cores that could be put on that task.
As for going from one compression format to another, you could store them in the final format (and convert on install if it differs between hardware setups, repeating if another hardware setup is detected).
Though if there's any processing done on the uncompressed data (like generating mipmaps or something), that conversion might not even cost extra because it needs to be decompressed and the new data compressed again anyways.
Though on that note, you'd get faster load times by just storing all of those preprocessed and faster install times by just sticking it all in the install download, so there is still a conflict between optimal load speeds and minimal storage space.
If you store the the textures in a format without hardware decoding support though, then I guess you would only get the bus speed advantage if you decode in a compute shader. Is that what people do? Or is it the storage bus that people care about and not pcie? I guess even if you decoded on CPU you'd get faster retrieval from storage, even though the CPU would introduce a bit of latency it might be less than what the disk would have...