Graphics Reduce size of graphics file (SOLVED)

[Clemens van Brunschot]

Hi there,
I am (as a GML beginner) building a 2D game with 40 1920x1080 static background pictures (mostly jpg, some png) and I like to reduce the volume burden these files will cause in the installation package. I am willing to lose some quality. But what option will serve my goal, using GMS2 and Photoshop CS6.
I know that further compressing graphics does no good, but maybe there are real options, like:
- reducing resolution of source files and scaling them up in GMS2
- using a different colour system
- using a different file format
- changing dots per inch
- or what?
What will help best?
(For your information: so far I do not grasp the sprite_add with an included file; I must be doing things wrong, although I have read https://forum.yoyogames.com/index.php?threads/loading-sprites-from-included-files.15252/, https://docs.yoyogames.com/source/dadiospice/002_reference/game assets/sprites/sprite_add.html and https://docs2.yoyogames.com/source/_build/2_interface/1_editors/included_files.html).

 

[Rayek]

Photoshop is terrible at PNG optimization. Photoshop CS6 is even worse compared to the latest versions. Avoid at all costs (in my opinion). DPI has absolutely nothing to do with screen graphics, and is only relevant to print.

Would you be willing to share a couple of example assets? Both jpg and png?

 

[rIKmAN]

Take a look at PNGCrush.

 

[Rayek]

PNGCrush is acceptable. ColorQuantizer is far ahead though, in particular in regards to user control and ease of use (with visual preview). Many more options, including a quality brush to control the conversion quite precisely. Colour palettes are completely controllable: so if you need an Amstrad retro coloured version, just load up that palette file. And excellent scale down algorithm control. It's free, and there is simply nothing on the market that compares.

http://x128.ho.ua/color-quantizer.html

I still wonder why GMS doesn't support WEBP by now, btw.

 

[Tsa05]

I still wonder why GMS doesn't support WEBP by now, btw.

https://caniuse.com/#search=webp
Wonder no more. For better or worse, it's only in Chrome and Opera; applications don't support it, other browsers don't support it--it's a chicken or egg problem, really. If the format was popular, everyone would implement it. If everyone implemented it, it would become popular. As a format that was introduced in 2010 and hasn't quite made it in 2019, everyone's more or less waiting for the *next* better format to be invented while jpeg and png do "enough" for now.

@OP: What are you looking to do with external files? It should be as straightforward as sprite_add("nameOfImage.png", 1, 0, 0, 0, 0);
But that won't do anything to reduce file size, since you're including the images in the package anyways... If you want the installer to be smaller, you could technically have all of the images in a zip file on a web server, and download them when the game runs. But that's just moving the problem!

Another option to consider is the use of tiles, or background colors, or patterns. For example, a large blue sky with trees and grass does not need to be a giant image; A solid blue backgroun in a room, with a few small grass images mixed together repeatedly, and a few pictures of trees could accomplish the same effect without using huge images. Takes a lot of planning though!

 

[Rayek]

https://caniuse.com/#search=webp
Wonder no more. For better or worse, it's only in Chrome and Opera; applications don't support it, other browsers don't support it--it's a chicken or egg problem, really. If the format was popular, everyone would implement it. If everyone implemented it, it would become popular. As a format that was introduced in 2010 and hasn't quite made it in 2019, everyone's more or less waiting for the *next* better format to be invented while jpeg and png do "enough" for now.

Firefox supports webp now. As does Edge. Only Apple is left not supporting it.
https://www.zdnet.com/article/firefox-and-edge-add-support-for-googles-webp-image-format/

I've been switching slowly to an open source GMS alternative in the past 6 months for most of my work, and the support for webp is great. Lossy, non-lossy, full transparency... It is a very flexible image format, and results in very small file sizes. Imagine larger transparent background elements as PNG, and compare to webp. No competition there, of course. It shaves off large amounts of your final game file size. Some things work better in PNG still. JPG I no longer use, though. No point using it when I can use webp (small file sizes and better quality).

I've been reading interesting things about AVIF, though, as well.

 

[Clemens van Brunschot]

It seems to me that the general advice is: produce PNG in an optimal way rather than feeding JPG into GMS2. Am I right? Would that really help? Being a beginner, I may not fully understand your advice.
Attached is a JPG file of only 163KB (file attached). GMS2 turns it into PNG format and 2.05MB.
If I ask Photoshop CS6 to make a PNG file itself, it is 1,76 MB.
Any other advice how to reduce filesizes?

 

[Homunculus]

I'm not so sure that having sprites in different file formats changes anything with respect to the final size of the package. All sprites get merged into texture groups after all, so it doesn't really matter in terms of size if each single image was a jpg, png or bmp (of course quality is another thing). Should be fairly easy to test.

 

[Rayek]

Import your sprite, save the project, right-mouse click the asset, "open in explorer", drag into Color Quantizer, reduce to 192 colours (you may have to use the quality brush to indicate some colours to be maintained), and overwrite the imported version in your project (both the version in sprites/yoursprite, as well as the one in sprites/yoursprite/layers/ (layers is for the image editor). GMS will notice the changed asset, and ask to reload or save. Choose reload.

Run your project, and enjoy quite smaller file sizes. Not as small as jpg, but still: with the optimized version of your image I reduced the file size of the testimage build from 3624mb to 1525mb. It happens to work quite well with your reduced colours image art style.

I would suggest, though, to export your backgrounds as PNG images from Photoshop, because the jpg artefacts will increase the noise, which increases the file size of the optimized PNG file in Colour Quantizer.

 

[Clemens van Brunschot]

Thanks a lot, @Rayek, for sorting this out. I will try tomorrow and let you know.
Two remarks: the original is in jpg.
And further reduction may occur by saving in a lower resolution, and scaling in GMS. Or maybe not. I'll compare everything.

 

[Deleted member 13992]

So, game development is a challenge of compromise. Using full-sized images as background images has rarely been the way to do it, though it's slightly more acceptable now since platforms have a lot of RAM. Still, with all our available resources, it's still good practice to look at how to optimize. These background images might not get compressed when they're sent to the graphcis card (I dont think GMS supports hardware level compression), and the size they are they will take ENORMOUS amounts of VRAM. A way around this is developing a system that streams images in and out of memory as you progress through the environment. Not for the faint-at-heart.

Breaking it up into smaller images that are repeated and overlayed makes a lot more sense, as games of old did it.

That said, here are some tips if you absolutely want to use images like the one you posted.

JPEG compression is irrelevant. It's not a clean format, was invented for/popularized by the internet, and really isn't suitable at all for game developement. It's not a standard format for games. You may have set the JPEG compression to a high amount, but zoom into the compressed image and you see plenty of artifacts. Definitely use the uncompressed source (non-JPEG) before converting to PNG.

- Starting from a highly compressed JPEG = lots of artifacts = harder for PNG to compress it efficiently because there are more colors (JPEG artifacts = technically more colors), and uglier result.

- Starting from the uncompressed raw image (the one with your cutout effect applied) = easier for PNG to compress, no artifacts, less colors, cleaner image = better PNG result.

It's stuff like this that isn't super intuitive if you're just getting into graphics, but can be learnt over time.

 

[Rayek]

A typical 1920x1080 image takes up around 7mb of video memory, depending on mipmaps, etc. Unfortunately GMS doesn't allow for any video RAM compression control: in my test with another game engine the same image takes up less than 3 mb and no visual quality loss. I wish GMS would allow for deeper control over image assets.

But really, unless Clemens uses tens upon tens of these images in the same scene, running out of video memory won't be an issue. Most video cards have at least 1GB of memory nowadays. Mobile might be troublesome, though in cases.

I do agree that it depends on the type of project, and the hardware targeted. And yes, avoid JPG for game dev if you can. On the other hand, it again depends on the scope and needs of a project. A jpg background can work just as well, but as far as I am aware GMS will convert all of them to PNG anyway. Which means a lossless workflow from the very start is the way to go. Compression should be controllable in the game engine. (An area in which GMS seems to be lacking. That said, other game engines I tested fare little better, so... More control means more user responsibility, and more complexity.)

 

[Clemens van Brunschot]

I get the message clearly, @muki. Thanks a lot! I do not really have raw images, as I have to start from JPG stock photos most of the time. I read your first tip as: after the Photoshop effect not again storing the result as JPG.

Here are my numbers, @Rayek. Using the photo with the Photoshop CS6 colour cutout effect.
- CS6 JPG directly into GMS2 ==> 18.1 MB executable
- CS6 PNG directly into GMS2 ==> 18.0 MB executable
- CS6 PNG into CQ 64 colours ==> 15.7 MB executable. The downgrading is acceptable because of the cutout art effect.
- CS6 PNG into CQ 64 colours and then in the GMS2 project again replaced by CQ 64 colours ==> 15.7 MB executable again
- CS6 PNG into CQ 64 colours and dimensions halved. Stretched in GMS2 ==> 15.1 MB executable. The downgrading is acceptable because of the cutout art effect.
Conclusions so far (based on N = 1 research):
- Up to 3 MB to be saved for each background picture.
- Avoid JPG storing
- Use Color Quantizer to further reduce colours and to halve dimensions where acceptable
- CQ can just as well be applied BEFORE importing the image to the sprite
GREAT !

 

[Rayek]

Klinkt goed! Don't forget that CQ has that quality brush I mentioned before (the tiny mask icon left of the circle icon) which allows you to draw over critical colours that you'd like to retain. After applying that quality brush, click the OK button, and CQ recalculates the colour palette.

PS CQ offers an incredible range of down-scale algorithms. I find that Catmul-Rom works best for most images when downscaling. Generally head and shoulders over Photoshop, anyway. Scaling down an image in CQ is the fifth icon from the far right. Choose Catrom.

Interestingly enough the algorithm used will also have an impact on final file size. No time to go into details here, but catrom scaled down images compress better compared to, for example, bi-linear. But I'd have to say I am a REAL nitpicker in this regard. Most developers couldn't care less

 

[Clemens van Brunschot]

Catrom it will be! Thanks, Dutchman.

 

[TsukaYuriko]

File size questions again, eh? That rings a bell.

Most of the important stuff has already been mentioned, so there's not much new stuff for me to add.

While color reduction can successfully reduce file size, keep in mind that doing so also reduces the quality of the graphic - sometimes noticeably, sometimes less so, depending on the image and reduction method/amount - so this may not be something you realistically want to apply.


There is a possibility to save file size without sacrificing image quality. You already mentioned in the opening post - dynamic resource loading via sprite_add. Any compression you apply to files which you then add as included files is preserved, and those files will not be re-compressed upon compilation.

This means that you can run any compression tools on your images, even lossless ones, and have observable results in the final build - one of them being a reduction of data.win's file size, which you seemed to like in the last topic.

One thing to note with this approach is that any graphics added this way will be placed on their own respective texture pages, one texture page for each file. This would normally introduce some performance concerns, as it would likely lead to an increase in texture swaps.
However, given that the subject matter is 1920x1080 images, they would likely take up an entire texture page on their own with the default settings, anyway, basically rendering this concern obsolete under these circumstances.

Another advantage of dynamically loading graphics with sprite_add is the ability to load and unload them as desired, unlike sprite resources, which stay loaded into memory. Although dynamically loaded sprites tend to take up more memory than static sprite resources, when managed properly, this should result in reduced memory usage as well - especially with 40 1080p images!


The advantages of external graphics aside, if you're facing difficulties implementing them as outlined in the opening post, I suggest posting a topic in the Programming forum, as the subject is more suitable for that forum than the design and publishing forum this topic is in.

 

[Clemens van Brunschot]

Hi @TsukaYuriko . That sounds ideal: on the fly loading and unloading 1080 backgrounds from included files. (I solved most of my problems with that.)
From your post I learn that when starting the game, all sprites (i.e. all backgrounds) will be loaded at the same time. (off-topic: this may cause my initial white game screen...)
That would make your idea a must... I will certainly explore that. Thanks.

 

[kupo15]

One thing to note with this approach is that any graphics added this way will be placed on their own respective texture pages, one texture page for each file. This would normally introduce some performance concerns, as it would likely lead to an increase in texture swaps.
However, given that the subject matter is 1920x1080 images, they would likely take up an entire texture page on their own with the default settings, anyway, basically rendering this concern obsolete under these circumstances.

Another advantage of dynamically loading graphics with sprite_add is the ability to load and unload them as desired, unlike sprite resources, which stay loaded into memory. Although dynamically loaded sprites tend to take up more memory than static sprite resources, when managed properly, this should result in reduced memory usage as well - especially with 40 1080p images!


The advantages of external graphics aside, if you're facing difficulties implementing them as outlined in the opening post, I suggest posting a topic in the Programming forum, as the subject is more suitable for that forum than the design and publishing forum this topic is in.

Hi @TsukaYuriko . That sounds ideal: on the fly loading and unloading 1080 backgrounds from included files. (I solved most of my problems with that.)
From your post I learn that when starting the game, all sprites (i.e. all backgrounds) will be loaded at the same time. (off-topic: this may cause my initial white game screen...)
That would make your idea a must... I will certainly explore that. Thanks.

I have to whole heartedly and respectfully disagree with this being a good way to go. I thought this was a good way to go knowing everything you said here but in practice this is not really the case. In regards to memory, externally loading is always going to be worse than simply keeping everything in the IDE. Unless maybe you really don't use much resources or memory at one time ever that the disadvantages of externally loading never come into play, then using it you can have infinite amount of memory and resources. If this is not the case, then external is terrible:

-Everything is placed on one TP (as you mentioned)
-External sprites take up double memory than inside the IDE as two copies are made. While its true that IDE resources stay in memory forever, as long as they are not prefetched, they are compressed thus take up a fraction of the memory they should...much less than double memory from dynamically adding.

I did the best test I could do regarding this and the results were disappointing and terrible. Unless I'm mistaken somehow, don't ever use sprite_add unless for a really good reason as it doesn't reduce memory at all. The disadvantages are too great for it to be considered a viable option in my current opinion.

https://forum.yoyogames.com/index.p...jectively-worse-memory-wise-vs-ide-why.47258/

 

[TsukaYuriko]

... hence the "However, given that the subject matter is 1920x1080 images, they would likely take up an entire texture page on their own with the default settings, anyway, basically rendering this concern obsolete under these circumstances" part. I doubt that all of these will be loaded into memory at the same time. Most likely, it would be one as a room background, maybe a few more if it's layered... but not all.

Certainly, not everything should be loaded dynamically (we've gone over that topic multiple times in the past, after all ), but in this particular case, it seems fine to me if - and only if - handled properly.

 

[Clemens van Brunschot]

Externally loading one background at the time, indeed. And maybe not the title page, to prevent flickering at game loading. My case is rather special and I like to develop my own experience. Thanks all.

 

[kupo15]

Yep I understand. While that's true, its still taking up double memory which is unnecessary I think. Unless he's making a picturebook I don't see the advantage to external loading, it just makes things more cumbersome and loses the ability to pack additional sprites into the texture.

But if this is a special case and works for him then by all means! Just wanted to put my 2c in there