0 votes
by (420 points)
I realize this probably violates a lot of best practices, but here we go.

I'm doing some reconfiguring of my image directory in my game, which one of the objectives being to allow swappable image packs. Some of these images are animated gifs, some are pngs with transparencies, and some are good old fashions jpgs. I have functions for each in the game, but it's becoming a bit challenging to account for all possible image types, especially when considering some image packs may not have the same needs as others.

As a test, I went ahead and changed a handful of pngs, gifs, and jpgs all to a .img extension and loaded them all with the same function. It worked just fine on my Windows 10 PC and on my Android phone via Chrome. That's great!

My question is, will this work the same way on other operating systems and browsers? Are there issues I'm not accounting for? It'd be great if I could just unify all the images under a single "proprietary" extension so I could handle them all the same way.

2 Answers

0 votes
by (159k points)
How a specific web-browser (brand, version, desktop/mobile, etc..) handles the association between a media file's file extension and the actual content within that file is out of our control, and web-browsers often have restrictions on which file-extensions they will open.

re: Animated GIFs
GIF isn't an efficient (file-size wise) file type when it comes to animation, I would suggest switching to WEBM for that.
by (44.7k points)

I'd recommend against using WEBM, since it still lacks support in a lot of browsers.  See:

https://caniuse.com/#feat=webm

GIF may be somewhat less efficient than WEBM in compression, and also poor due to only supporting 256 colors, but it does have wide support across browsers, which WEBM currently lacks.

0 votes
by (44.7k points)

My question is, will this work the same way on other operating systems and browsers?

The short answer is no.  For example, Internet Explorer determines how to decode images based upon the file extension.

If you'd like to do a test for how things work in other browsers, make a simple test HTML page which shows the various images as you described, put them online, and then try viewing them here:

https://developer.microsoft.com/en-us/microsoft-edge/tools/screenshots/

That will show you what the first page of your HTML page looks like when rendered through different browsers on different operating systems.

In any case, because IE doesn't support what you're trying to do, and the fact that roughly 1 in 20 people in the US still use IE (unfortunately):

http://gs.statcounter.com/browser-market-share/all/united-states-of-america

I would strongly recommend against renaming the file extensions.

That is, unless you want a bunch of people asking you why images don't work for them.  :-P

If all of your filenames are unique, even once the file extension is ignored, then you could just make a lookup table if you really need to.  Something like:

<<set setup.img = { picture1: ".jpg", picture2: ".gif", house: ".jpg", symbol: ".png", etc... }>>

And that should help add the correct file extension like this:

<<set _fnam = "picture" + _n>>
<<set _fnam += setup.img[_fnam]>>

Hope that helps!  :-)

by (420 points)
The problem with this solution is that it's possible that while an image in the official image pack would be animated (gif), it would very well be static (jpg or png) in a user-made image pack. If it were possible to check to see if a file existed I could just have it run down the line of gif > png > jpg until it found a valid filename, but near as I can tell that isn't really possible.

I wonder if I could cheese it the original way I proposed, but just use the .gif extension instead of a non-image one.
by (44.7k points)
You'd encounter the same problem in IE.  If you try to load a JPEG file with a ".gif" file extension in IE it won't open it.  Change the file exentsion to ".jpg" and it will open fine in IE.  Unlike most modern browsers, IE doesn't try to recognize the type of file and then use the appropriate decoder, it just assumes that the file extension is correct, and if it isn't, then it fails to load the image.

For what you want, I think you'd be better off including a file with a lookup table in it to go with your image pack, where it lists "image X = filename Y" for each image that's supposed to be in the image pack.
...