The problem is...on a 3G or iPod 2G...you have 40 MB of Ram to work with. If you fill that up with high-res graphics...there isn't anything left to run a game in.
You can't use 4 times the graphics load in an old device. Its hard enough making it work with 40MB of RAM...so if your image load quadruples on a 3G...its game over before you even get out of the level selector.
Right now...the resolution independence doesn't work... You are either forced to publish to either 4G or 3G...not both.
And this doesn't take into account that our app download file is 3 times bigger than it should be...which means it will be virtually impossible to build a game that cannot be downloaded outside of a Wi-Fi or through iTunes on a PC...since it will be hard as hell to stay under the 20MB quota for wireless downloads.
synthesis said: The problem is...on a 3G or iPod 2G...you have 40 MB of Ram to work with. If you fill that up with high-res graphics...there isn't anything left to run a game in.
Here is another sample to explain the differences that currently exist in quality.
The image on the left is a screenshot from an iPod 2G BEFORE the last release and using original art that was at 320x480 x 8BIT resolution. The middle image is a screenshot from an iPod 2G AFTER the last release using hi-res originals and then using resolution independence to generate the low res images. The right image is a screenshot from a 4G using the original hi-res art.
As you can see...the reduction in visual quality from 8.7 to 8.8 is considerable...the text is blurry and the art is not nearly as sharp as before (on the iPod graphics). However, the 4G art look absolutely crystal clear now.
Yes...the icons above (flame throwers and gas cans, etc.) are 24 bit images...and you can see what happens. And the background behind them (the grey tiles) was an 8 bit image.
it doesn't seem to matter what bit depth the originals are in...the auto-crusher that GS is using to generate the 3G image clones is not maintaining original quality.
OH SNAP... FMG...you might have something there... A few are at odd numbers when split in half. I will be sure to correct that and test it out.
However, The sample 3 graphic on page 1 is 160x240...and it looks AWFUL scaled down. So I still am convinced its a GS issue.
But the icons above (the flame throwers and gas cans) are 190x190...which would split to 95x95. I will adjust those by 10 pixels and see if I can get a better result.
I reworked the game making sure that my hi-res graphics were a multiple of 4 and that did the trick. Now my low-res remain a multiple of 2 and do not split a pixel when centering on an x or y position point.
Below is a new sample. All were compiled using v0.8.8
The left image is on an iPod 2G and is before image reworking...where the low-res were odd sizes...thus splitting pixels on the grid. The middle image is also on the iPod but after adjusting the images so that the hi-res were a multiple of 4. The right image is the 4G sample of the same image.
So it appears that the quality is there...just need to make sure you use a multiple of 4.
HOWEVER!!!!!!!!!!!!!!!!!!!! My sample 3 graphic is still a problem and VERY blurry. I am not sure why this is...it looks fine on the 4G and the original art is sharp and crisp...the the 3G version is AWFUL and BLURRED.
ALSO!!!!!!!!!!!!!!!!!!! Gendai. The 3G art (auto generated) is STILL LARGER in file size than the hi-res art. If this is the case...THEN WHAT IS THE POINT OF HAVING INDEPENDENT RESOLUTION!!!
Until this is fixed and the low-res art is successfully reduced at a bit sample rate identical to the larger art...then the resolution independence is still un-usable. We will be forced to publish as 3G capable and have crappy looking games on the 4G or publish hi-res for the 4G and ignore the 3G line and 80-90% of the current market. To me...neither option is a good one...but if I had to choose...I would choose the low-res versioning...which makes resolution independence pointless.
It would be great if you could give us some idea if this fix is a priority of if its something that will be addressed "when you get around to it". A yellow post to this question would be quite welcomed by many I am sure.
Thanks.
Hopefully this independent testing we did helped some. We would love to have the 4G hi-res graphics...but not at the file size expenses that currently exist (making our games likely crash often on a 3G and unplayable) and at the expense of a .app file being twice as big as it should be.
I will keep you all posted if I find anything else our on the issue or if I discover what is causing sample 3 (on page 1) to come out so bad on an iPod 2G...where it is crystal clear on a 4G.
BTW!!! A big thanks to FMG for the delivery of the AH-HA moment early this morning with the split pixel theory/suggestion.
Cool! I am glad I could help some! Getting there at least...
The 32bit images should not affect the RAM on an older device any more than an 8bit image would. Everything gets turned into 32bit textures in openGL, regardless of the original file.
But the file size is certainly a concern, especially if you care about staying under the 20MB 3G limit.
And the blurriness isn't acceptable of course.
I cannot imagine that this will ever be 100% perfect.
You ARE able to Control-click on the published .app and Control-click on the .gameproj file... Can you simply replace the low-res images yourself?
Not that that is the answer of course, but does that work?
FMG: Thanks again for the tip. I hope you are right about the 32 bit textures...but the file size thing is horrible. We will all end up with 50-100 MB games to download if designing for 4G with over 40 levels/scenes.
And...Can we replace those graphics?
2 issues with that I see... 1) It violates the TOS...same as changing the Default.png graphic (GS splash logo). 2) I believe they are parced and indexed and simply replacing them could corrupt the app bundle.
If we have to do our own 8Bit art anyway...perhaps Gendai can put 2 image slots in the actor...1 for hi-res and 1 for lo-res (which is available by a checkbox option). Then if its checked...the compiler can skip it and use our custom 8Bit graphic. All the complier would need to do is name them correctly and index them. If unchecked...it can be auto-crushed. This way we would have the option of making our app packet bundles lighter.
And it really does need to be 100%. This is a CORE feature.
A Yellow post would be nice (and welcomed) right about now on how this is going to be handled in the coming days/week(s).
I double checked my sample 3 (page 1) graphic in my game.
The original art is 320x480 x 8Bit. The game actor is set to 160x240 in size and placed at 160 X and 240 Y (screen center). The only other rules I have affecting the image is the alpha...where it starts at 1 and interpolates to 0.
I HAVE NO IDEA why the image looks so bad on the iPod 2G. I can only guess that the image crusher damaged this image.
A yellow post would help right about now. Any responses are welcome on how to proceed from here in using the new resolution independence feature.
An update... So I tried figuring out what is going on with sample 3 (first page) with the blurry text. I tried saving the original image so that it is 24bit. The file size went up a bit but now it is VERY CLEAR on the iPod.
I will plan to test the image back at 8 bit again to verify that it goes back to blurry or not. Will let you know what happens when I do.
quoth synthesis: SOOOO.... [snip/] Gendai. The 3G art (auto generated) is STILL LARGER in file size than the hi-res art. If this is the case...THEN WHAT IS THE POINT OF HAVING INDEPENDENT RESOLUTION!!!
I presume you mean that the original file is smaller than the generated files. I looked at your original sample, ran it through our publishing system, and found that your background image was an indexed PNG file. Indexed PNGs are optimized to use a color palette instead of a full PNG color scheme, which is not suitable for loading on an iOS device.
When your images are optimized for loading by an iOS client, they are run through the pngcrush utility, using Apple's iPhone-/iPad-specific optimization scheme. This converts the image from an indexed format to a pure per-pixel color specification. Therefore, in almost all cases, the image will take up more disk space than the original indexed image.
The upshot of this is that the image will be loaded faster by the iOS device at the cost of more disk space. If the image was simply copied to an iOS device as an indexed PNG, it would take longer to load. Given the relative space between an iOS device's RAM and its solid-state storage, we choose to optimize runtime performance.
I hope this has cleared up your situation. I would recommend using non-indexed PNGs in all stages of asset production. If you find that non-indexed PNGs still produce undesirable results, please post a new thread in our official technical support forum.
Thank you sooo much for following up on this Khakionion.
So am I to understand then... As we develop our art assets...using Photoshop for example, we should be generating ALL assets as a 24 bit asset on PNG export (rather than a compressed 8 bit) whether or not they have inherent transparency?
If we do this...even though the file sizes are usually 200-300% bigger...the game engine will run at a more optimized environment rather than a crushed 8 bit file?
synthesis said: So am I to understand then... As we develop our art assets...using Photoshop for example, we should be generating ALL assets as a 24 bit asset on PNG export (rather than a compressed 8 bit) whether or not they have inherent transparency?
OK. I have another issue but similar. I started a new game and I have an actor that is 50 x 38 png 32 i set the image to the actor and fixed. It looks good in the object pane but when drag it into the game it makes it super small. It changed the size. This happened to me in the first game I made. Then I toggle off Enable Resolution Independence and that fixed the issue. Tried it for this game, but no luck. Any suggestions?
So I started making a game with reso independence and importing my images thenstarted working on the app. Images look good and the sizes look like they held their 960 by 640. Then I add a couple more images at the 960 x 640 format but this Time when I drag one of the original actors into the scene it is huge. I check the size and it's correct both on the actor and on the scene. So I check the other actors on the scene and some are correct in size and some have been converted to the 480 x 320 format yet they only actor that looks huge is the newest added yet instances are all different some 960 and some 480. So needless to say glad I didn't get too far so I unchecked reso indep and guess I'll stick with just the 480 x320 until reso becomes stable.
Whether or not this helps, i'm not sure. Those of you that know me, I am a programmer by trade, and second an artist-in-training. So what i've been doing for my game graphics is oversizing them. That is to say that if my actor is 50x50, i'll create a graphic that's 128x128. Then let the GameSalad engine itself downsize them at runtime. This results in a clean look no matter what resolution it's on. Additionally I can create re-use the same art for different sizes of the same actor. I don't use the resolution-independence checkbox. Yes, file sizes are slightly larger but not to the point where it's killing me. Performance of moving actors and game logic is more of an issue than image file sizes, and that's where I spend most of my time optimizing. There is negligible cpu penalty for large graphics files (to a limit).
Btw, you guys are gonna love this game i'm working on... looking at an Oct 15th launch... more to come
Comments
You can't use 4 times the graphics load in an old device. Its hard enough making it work with 40MB of RAM...so if your image load quadruples on a 3G...its game over before you even get out of the level selector.
Right now...the resolution independence doesn't work...
You are either forced to publish to either 4G or 3G...not both.
And this doesn't take into account that our app download file is 3 times bigger than it should be...which means it will be virtually impossible to build a game that cannot be downloaded outside of a Wi-Fi or through iTunes on a PC...since it will be hard as hell to stay under the 20MB quota for wireless downloads.
Some graphics look fine while others look awful. Some samples above (on page 1) have the same (sample 3 and 4) result.
The automated graphics crusher needs to be improved considerably.
The image on the left is a screenshot from an iPod 2G BEFORE the last release and using original art that was at 320x480 x 8BIT resolution.
The middle image is a screenshot from an iPod 2G AFTER the last release using hi-res originals and then using resolution independence to generate the low res images.
The right image is a screenshot from a 4G using the original hi-res art.
actual image here: http://www.furiousapps.com/toxic/sample5.png
As you can see...the reduction in visual quality from 8.7 to 8.8 is considerable...the text is blurry and the art is not nearly as sharp as before (on the iPod graphics). However, the 4G art look absolutely crystal clear now.
it doesn't seem to matter what bit depth the originals are in...the auto-crusher that GS is using to generate the 3G image clones is not maintaining original quality.
A 70x70 graphic hi-res now becomes a 35x35 pixel graphic.
Thus causing a blur due to the centering of the actor and the split pixel.
FMG...you might have something there...
A few are at odd numbers when split in half. I will be sure to correct that and test it out.
However,
The sample 3 graphic on page 1 is 160x240...and it looks AWFUL scaled down. So I still am convinced its a GS issue.
But the icons above (the flame throwers and gas cans) are 190x190...which would split to 95x95. I will adjust those by 10 pixels and see if I can get a better result.
Thanks for the suggestion.
Hopefully that improves it a bit, but I cannot imagine that will solve it. Let us know!
I reworked the game making sure that my hi-res graphics were a multiple of 4 and that did the trick. Now my low-res remain a multiple of 2 and do not split a pixel when centering on an x or y position point.
Below is a new sample. All were compiled using v0.8.8
The left image is on an iPod 2G and is before image reworking...where the low-res were odd sizes...thus splitting pixels on the grid.
The middle image is also on the iPod but after adjusting the images so that the hi-res were a multiple of 4.
The right image is the 4G sample of the same image.
original sample: http://www.furiousapps.com/toxic/sample6.png
So it appears that the quality is there...just need to make sure you use a multiple of 4.
HOWEVER!!!!!!!!!!!!!!!!!!!!
My sample 3 graphic is still a problem and VERY blurry. I am not sure why this is...it looks fine on the 4G and the original art is sharp and crisp...the the 3G version is AWFUL and BLURRED.
ALSO!!!!!!!!!!!!!!!!!!!
Gendai.
The 3G art (auto generated) is STILL LARGER in file size than the hi-res art. If this is the case...THEN WHAT IS THE POINT OF HAVING INDEPENDENT RESOLUTION!!!
Until this is fixed and the low-res art is successfully reduced at a bit sample rate identical to the larger art...then the resolution independence is still un-usable. We will be forced to publish as 3G capable and have crappy looking games on the 4G or publish hi-res for the 4G and ignore the 3G line and 80-90% of the current market. To me...neither option is a good one...but if I had to choose...I would choose the low-res versioning...which makes resolution independence pointless.
It would be great if you could give us some idea if this fix is a priority of if its something that will be addressed "when you get around to it". A yellow post to this question would be quite welcomed by many I am sure.
Thanks.
Hopefully this independent testing we did helped some. We would love to have the 4G hi-res graphics...but not at the file size expenses that currently exist (making our games likely crash often on a 3G and unplayable) and at the expense of a .app file being twice as big as it should be.
I will keep you all posted if I find anything else our on the issue or if I discover what is causing sample 3 (on page 1) to come out so bad on an iPod 2G...where it is crystal clear on a 4G.
BTW!!!
A big thanks to FMG for the delivery of the AH-HA moment early this morning with the split pixel theory/suggestion.
Getting there at least...
The 32bit images should not affect the RAM on an older device any more than an 8bit image would. Everything gets turned into 32bit textures in openGL, regardless of the original file.
But the file size is certainly a concern, especially if you care about staying under the 20MB 3G limit.
And the blurriness isn't acceptable of course.
I cannot imagine that this will ever be 100% perfect.
You ARE able to Control-click on the published .app and Control-click on the .gameproj file...
Can you simply replace the low-res images yourself?
Not that that is the answer of course, but does that work?
Thanks again for the tip. I hope you are right about the 32 bit textures...but the file size thing is horrible. We will all end up with 50-100 MB games to download if designing for 4G with over 40 levels/scenes.
And...Can we replace those graphics?
2 issues with that I see...
1) It violates the TOS...same as changing the Default.png graphic (GS splash logo).
2) I believe they are parced and indexed and simply replacing them could corrupt the app bundle.
If we have to do our own 8Bit art anyway...perhaps Gendai can put 2 image slots in the actor...1 for hi-res and 1 for lo-res (which is available by a checkbox option). Then if its checked...the compiler can skip it and use our custom 8Bit graphic. All the complier would need to do is name them correctly and index them. If unchecked...it can be auto-crushed. This way we would have the option of making our app packet bundles lighter.
And it really does need to be 100%. This is a CORE feature.
A Yellow post would be nice (and welcomed) right about now on how this is going to be handled in the coming days/week(s).
The original art is 320x480 x 8Bit.
The game actor is set to 160x240 in size and placed at 160 X and 240 Y (screen center).
The only other rules I have affecting the image is the alpha...where it starts at 1 and interpolates to 0.
I HAVE NO IDEA why the image looks so bad on the iPod 2G. I can only guess that the image crusher damaged this image.
A yellow post would help right about now. Any responses are welcome on how to proceed from here in using the new resolution independence feature.
So I tried figuring out what is going on with sample 3 (first page) with the blurry text. I tried saving the original image so that it is 24bit. The file size went up a bit but now it is VERY CLEAR on the iPod.
I will plan to test the image back at 8 bit again to verify that it goes back to blurry or not.
Will let you know what happens when I do.
When your images are optimized for loading by an iOS client, they are run through the pngcrush utility, using Apple's iPhone-/iPad-specific optimization scheme. This converts the image from an indexed format to a pure per-pixel color specification. Therefore, in almost all cases, the image will take up more disk space than the original indexed image.
The upshot of this is that the image will be loaded faster by the iOS device at the cost of more disk space. If the image was simply copied to an iOS device as an indexed PNG, it would take longer to load. Given the relative space between an iOS device's RAM and its solid-state storage, we choose to optimize runtime performance.
I hope this has cleared up your situation. I would recommend using non-indexed PNGs in all stages of asset production. If you find that non-indexed PNGs still produce undesirable results, please post a new thread in our official technical support forum.
Cheers!
./Khakionion
So am I to understand then...
As we develop our art assets...using Photoshop for example, we should be generating ALL assets as a 24 bit asset on PNG export (rather than a compressed 8 bit) whether or not they have inherent transparency?
If we do this...even though the file sizes are usually 200-300% bigger...the game engine will run at a more optimized environment rather than a crushed 8 bit file?
Thanks,
Syn
_______________
Nesen Probe http://itunes.apple.com/us/app/nesen-probe/id377766693?mt=8
Tickle Stones http://itunes.apple.com/us/app/tickle-stones/id363484260?mt=8
Food Fight! (free) http://itunes.apple.com/us/app/food-fight/id352646643?mt=8
Btw, you guys are gonna love this game i'm working on... looking at an Oct 15th launch... more to come
Darren.
@ORBZ, I'm not sure why your not just using a 100x100 image instead of 128??