Yes, you can still replace png with jpg images as described there. I've done it recently myself and have also done extensive testing to make sure that it works.
The GS viewer does not support it so to test it you need an adhoc build
Also, don't worry about the file size of PNGs vs JPGs because the new graphics handling slices and dices the images into tiles to speed up loading. If you stick to 32 bit PNGs you'll get the highest resolution and you can use alpha when you need it.
@PhilipCC said:
Also, don't worry about the file size of PNGs vs JPGs because the new graphics handling slices and dices the images into tiles to speed up loading. If you stick to 32 bit PNGs you'll get the highest resolution and you can use alpha when you need it.
Sorry to be a pedant . . . but . . .
The new graphics system was never implimented (where images are sliced into 64x64 pixel tiles), and the bit depth of an image has no bearing on its resolution !
I for one find the whole issue about how GameSalad deals with image formats really confusing, but I do know something, the size of my app could be cut in half if I could use image compression.
I say this as we were advised at some point not to use ImageOptim etc...
Would be nice instead of having to have a work-around to have the freedom to import JPGs or use compressed PNGs or whatever other format of our choosing...GIFs TGAs TIFFs etc...
@smurfted said:
I agree, i don't see why we should have to cheat in some jpegs into our ups when the engine can obviously handle them..
I partly agree. The GS viewer does not support other image formats than png so they would have to code in support for full support (or many users would probably contact support asking why their project does not work on the viewer).
Also, the GS build process converts all the png images to their own custom "GS image" format. In part this is done to make it much harder for people to steal your images - and this is a very good thing. It's easy to extract all project files (I won't go into further details on this) and extract all the images but the images will not be usable (unless you can reverse engineer the GS image format which 99.9% of the people most likely can't do).
Since you asked about .jpg I assume that you already know of the huge file size / app size saving that is achieved (e.g on 2048x1536 "background images"). What you may also want to know though is that if you do use jpg images those will be left untouched by the publishing system (which is a good thing since they should not be converted) but since they are left in their original jpg format they will also be visible to anyone with the capacity to extract your project file after release (an easy task indeed).
@JSproject said:
Since you asked about .jpg I assume that you already know of the huge file size / app size saving that is achieved (e.g on 2048x1536 "background images").
I'd add one caveat here (whilst agreeing with everything else you say in your post).
The savings between an uncompressed (or losslessly compressed) file and a lossy compressed file (like .jpg) won't always be huge, it will vary depending on the content of the image, in fact a compressed file like .jpg can even be larger than the same file saved as a PNG.
And the one other thing worth throwing in here is that any savings made by using compressed images will only effect the app size on disk, it won't effect RAM usage or load times, that is to say that using .jpgs will have no effect on the app's performance as regardless of the image format the image will be held in RAM in a 32bit RGBA colour space, so a 5MB PNG will use up 5MB of RAM and a 600kb .jpg of the same pixel dimensions will also use up 5MB of RAM.
Comments
Yes, you can still replace png with jpg images as described there. I've done it recently myself and have also done extensive testing to make sure that it works.
The GS viewer does not support it so to test it you need an adhoc build
Then I will give it a try tonight.Thank you..
No problem man!
@smurfted Seeing that you are on a Mac you may find this about graphics of interest: http://forums.gamesalad.com/discussion/76342/convert-graphics-to-png-on-mac-with-preview#latest
Also, don't worry about the file size of PNGs vs JPGs because the new graphics handling slices and dices the images into tiles to speed up loading. If you stick to 32 bit PNGs you'll get the highest resolution and you can use alpha when you need it.
Sorry to be a pedant
. . . but . . .
The new graphics system was never implimented (where images are sliced into 64x64 pixel tiles), and the bit depth of an image has no bearing on its resolution !
[/pedantry]
I for one find the whole issue about how GameSalad deals with image formats really confusing, but I do know something, the size of my app could be cut in half if I could use image compression.
I say this as we were advised at some point not to use ImageOptim etc...
Would be nice instead of having to have a work-around to have the freedom to import JPGs or use compressed PNGs or whatever other format of our choosing...GIFs TGAs TIFFs etc...
I agree, i don't see why we should have to cheat in some jpegs into our ups when the engine can obviously handle them..
I partly agree. The GS viewer does not support other image formats than png so they would have to code in support for full support (or many users would probably contact support asking why their project does not work on the viewer).
Also, the GS build process converts all the png images to their own custom "GS image" format. In part this is done to make it much harder for people to steal your images - and this is a very good thing. It's easy to extract all project files (I won't go into further details on this) and extract all the images but the images will not be usable (unless you can reverse engineer the GS image format which 99.9% of the people most likely can't do).
Since you asked about .jpg I assume that you already know of the huge file size / app size saving that is achieved (e.g on 2048x1536 "background images"). What you may also want to know though is that if you do use jpg images those will be left untouched by the publishing system (which is a good thing since they should not be converted) but since they are left in their original jpg format they will also be visible to anyone with the capacity to extract your project file after release (an easy task indeed).
I'd add one caveat here (whilst agreeing with everything else you say in your post).
The savings between an uncompressed (or losslessly compressed) file and a lossy compressed file (like .jpg) won't always be huge, it will vary depending on the content of the image, in fact a compressed file like .jpg can even be larger than the same file saved as a PNG.
And the one other thing worth throwing in here is that any savings made by using compressed images will only effect the app size on disk, it won't effect RAM usage or load times, that is to say that using .jpgs will have no effect on the app's performance as regardless of the image format the image will be held in RAM in a 32bit RGBA colour space, so a 5MB PNG will use up 5MB of RAM and a 600kb .jpg of the same pixel dimensions will also use up 5MB of RAM.