@Socks said:
Internally yes, but the actual screen resolution is 1920x1080.
Not sure what you mean by actual? I thought the new res was 2208x1242 which will be displayed on a screen 960w x 540h. Like the iPad res is 2048x1536 displayed on a screen 1024w x 768h.
@colander said:
Socks the new iPhone 6 Plus resolution is 2.3x how does using a 3x image on this resolution work and look?
The image will be scaled down from 3072 to 1920, again not a clean division, so graphic images will be blurred, but the small physical screen size will likely mean that you get away with the reduction in quality.
I'm all for a change in resolution, an upheaval like the move to Retina, it's usually a pain and takes getting used to - and initially more work as you adapt your projects - but it's always worth it in the end, but this change would mean the same adaptation, additional work and larger memory footprint for a lower quality output !
adent42Key Master, Head Chef, Executive Chef, Member, PROPosts: 3,161
To answer your question about why @3x, it's because that's the way Apple specified things (I imagine the whole number multipliers make things faster for them).
The next RC will release with this system. If any of you did your artwork in Vector format, please try making your images 50% bigger, update your game, and publish. Everyone else try publishing with RI turned off.
See how it feels / looks. If you have a particular concern, send us your game and we can pick a few to test on the both the new devices and the older ones (I can't promise we'll get to your game, but send it to us anyway so we have a good variety to choose from).
For the time being, the best compromise between image quality and giant images is to provide images meant for @2x and turning off RI. Since it's the end of our day too, we'll pick this up again tomorrow (and we understand everyone's concerns, so we'll be thinking about this problem overnight too).
adent42Key Master, Head Chef, Executive Chef, Member, PROPosts: 3,161
Just thinking about it now, I'm gonna see if we can get a slight adjustment in before release.
While it's not the cleanest solution in terms of super clean images, I'm gonna see if we can use the @3x images for iPhone 6 Plus + iPad RI and the @2x images for iPad / iPhone 6-4 RI. This works out even better since before I believe you getting the @1x images for non RI iPads which would be too low of resolution in most cases and aligns the max resolutions for images more closely. Someone from the team here will let you know when the next RC comes out whether we got this adjustment in or not.
@adent42 said:
To answer your question about why 3x, it's because that's the way Apple specified things (I imagine the whole number multipliers make things faster for them).
Absolutely, I'm not saying this is the doing of GameSalad, I understand that Apple throws this stuff at you all the time, and it can't be easy keeping up with their ever-changing specs, I was more calling for a better implementation of Apple's latest demands (if that's even possible).
@adent42 said:
The next RC will release with this system. If any of you did your artwork in Vector format, please try making your images 50% bigger, update your game, and publish. Everyone else try publishing with RI turned off.
Vector artwork, especially, will suffer from being produced at 3x size then reduced to 2x and 1x.
@adent42 said:
For the time being, the best compromise between image quality and giant images is to provide images meant for 2x and turning off RI. Since it's the end of our day too, we'll pick this up again tomorrow (and we understand everyone's concerns, so we'll be thinking about this problem overnight too).
That's kind of where I'd arrived at too, as the best compromise, 2x (2048 ) with RI off, and then scale 'up' (or down as we say in maths when something is smaller ) to the iPhone6/6/+ . . . . any qualitative difference on an iPhone6/6+ screen between a downscaled version (which is coming from a larger 2048 source file) and a native 1920 resolution image will largely be lost due to the small size of the screen.
While it's not the cleanest solution in terms of super clean images, I'm gonna see if we can use the 3x images for iPhone 6 Plus + iPad RI
This seems a little crazy to me, if I understand it correctly you are referring to your reference of 3072 ? Which would mean we have three image sizes . .
3x - 3072 x 2304
2x - 2048 x 1536
1x - 1024 x 768
So for the iPhone6+ which has a 1920 x 1080 screen resolution we would use the 3072 x 2304 image rather than the 2048 x 1536 image ?
And for the iPad RI which has a 2048 x 1536 screen resolution we would also use the 3072 x 2304 image rather than the 2048 x 1536 image ?
Would it not be possible to use the 2048 x 1536 image on the 2048 x 1536 pixel screen which would avoid the aliasing/blurring downscaling would bring ?
. . . . and the 2x images for iPad / iPhone 6-4 RI. This works out even better since before I believe you getting the 1x images for non RI iPads which would be too low of resolution . . . .
Ok, now this really is crazy !
. . . but how can 1x be too low for an iPad 1, it is exactly, pixel for pixel, 1:1, the perfect pixel count for the device !?
. . . . . .
EDIT . . . . Unless by 3x, 2x, 1x you mean those scales based on a 3x equalling 2048 ?
In which case that sounds like a good move, the compromise here (over the previous Apple 1x/2x system) is a quality loss on the non-RI iPads . . for example it would now be, using your compromise, mathematically impossible to access a single pixel on a non-RI iPad, so no neat lines or fine detail left un-anti-aliased (neologism alert) but if anything should soak up the compromise it really should be devices that are nearing the end of their useful lives.
As for the iPhone6+ I would have thought that was an ideal candidate for a letterboxed/scaled project from a 2048 source file ?
If you scale an iPad RI project's 2048 pixels down to 1920 wide, that gives you a project size of 1920 * 1440, which means cropping from 4:3 to 16:9 chops 180 pixels off the top and the bottom of a landscape project, which isn't such an additional burden of unused pixels to carry around in a project (certainly much better than 3072 x 2304!) - you could literally add 16:9 guides to Creator's iPad project and have a viable iPhone6+ project - and like I say any loss of fine line fidelity through downscaling is less of an issue on the iPhone6+ given it's comparatively smaller screen size.
To add another voice to the discussion -- personally, I have RI turned off, always, and my apps run well on all devices, iPhone 4 up and iPad 2 up. I don't care much about supporting older devices than these.
From that perspective, the changes have absolutely no bearing on the resulting app.
As for the whole 'why 3072' discussion -- first off, @adent42 does that mean we can now import max 3072x3072 images into GS instead of 2048x2048? -- the reason this number is kicking around is only because we use iPad projects to build our universal apps. Thus the size is the resolution of an iPad, if it was @3x. If you start with an iPhone 6 Plus project, you will only need to use 2208x1242 graphics, and then those will scale down well.
So the problem is really caused by conversion between iPad and iPhone, not simply by the system of @3x, @2x and @1x itself.
@pHghost said:
As for the whole 'why 3072' discussion --
Probably an error, lol !
Why specify 3x resolution for a new iPhone device and then use, as a reference, the original iPad size !? The result is this problematic 3072 size !? If Apple's request to make iPhone6+ images 3x was based on a starting size of 640 (3 x 640 = 1920 which is the iPhone6+'s actual size) it would make much more sense !?
@pHghost said:
first off, adent42 does that mean we can now import max 3072x3072 images into GS instead of 2048x2048?
And does it now mean that we should make sure our images are divisible by 3 instead of 2/4 ?
That 100 x 100 pixel default GameSalad actor is looking decidedly worried, yet his sexier 99 x 99 pixel cousin won't get the job either as he is unable to sit on a whole pixel value without smearing his image
Here's quick example of fine detail quality loss when working downwards from 3072 (bicubic interpolation). The image is enlarged with a perfectly divisible NN scale - so basically we are zoomed in on the actual pixels.
The left column has started life at 3072 (not shown), then was scaled down to 2048, 1920 and 1024, The right column started life at 2048 and was scaled down to 1920 and 1024 (always from the original source).
Obviously the 2048 image in the right column is perfect as that was the size it was generated at, whereas the 2048 image in the left column (which came from a 3072 image) is already starting to look compromised (hey GameSalad's 8bit graphics game makers, watch out !! Your days are numbered ) - moving down to 1920 the 2048 source is still looking pretty good, with a little aliasing becoming noticeable, whereas the 3072 source is fairing much worse - and by the time we get to 1024 the quality is noticeably poorer all round, as to be expected, but the 2048 source does seem to be doing a much better job at holding the lines.
I'd go as far as to say that the 2048 source is doing a better job at holding fine detail definition at 1920 than the 3072 source is at 2048. Which in part comes back to an earlier point, that you often hear people saying that downscaling is fine whereas upscaling is guaranteed quality loss, but in reality all scaling results in compromised quality.
May I point out that the iPhone6+ project dimensions are wrong in GS to begin with.
They are set to 540x960. However this is based on the post 0.87 downsampling that the current phone does in preparation for future higher resolution displays - actually squeezing 23 pixels into 20 real screen pixels AFTER rendering, leading to the physical 1080x1920 pixels.
The actual virtual point size of the phone is 414x736, leading to 1242x2208 @3x.
The value of 1080x1920 should be of no concern to us as this downsampling is not under our control and may change in upcoming models.
I thus believe the project dimensions should be 414x736, otherwise there will be a double loss by first downsampling during rendering, then again by the device after rendering.
To support my case, XCode actually requires the launch image for the iPhone6+ to be 1242x2208 pixels.
p.s. The dimensions for the normal iPhone6 projects are correct.
@Socks said:
hey GameSalad's 8bit graphics game makers, watch out !! Your days are numbered
Well, that's the reason I don't use RI in the first place (better to use just the original files) and am developing methods how to have pixel art always rendered at its native resolution -- though I'll need to do some tests on the iPhone 6 Plus once a friend or someone crazy around me gets one.
PhilipCCEncounter Bay, South AustraliaMemberPosts: 1,390
A few days ago I found an article that helped me understand the subject better because it is represented graphically. (A similar link to the one that adent42 put up earlier today.)
I found this when looking into this, explains it a little bit
The 6, the 5s, the 5, the 4s and the 4 are all 326 pixels per inch, and use @2x assets to stick to the approximately 160 points per inch of all previous devices.
The 6+ is 401 pixels per inch. So it'd hypothetically need roughly @2.46x assets. Instead Apple uses @3x assets and scales the complete output down to about 84% of its natural size.
In practice Apple has decided to go with more like 87%, turning the 1080 into 1242. No doubt that was to find something as close as possible to 84% that still produced integral sizes in both directions — 1242/1080 = 2208/1920 exactly, whereas if you'd turned the 1080 into, say, 1286, you'd somehow need to render 2286.22 pixels vertically to scale well.
A few days ago I found an article that helped me understand the subject better because it is represented graphically. (The same link that adent42 put up earlier today.)
The paint code video at the bottom is what we need.
PhilipCCEncounter Bay, South AustraliaMemberPosts: 1,390
@BBEnk I just edited my comment with a link to a better graphic (while you were writing) and the video is a nice ad for PaintCode, but it doesn't help us with GameSalad.
@PhilipCC said:
BBEnk I just edited my comment with a link to a better graphic (while you were writing) and the video is a nice ad for PaintCode, but it doesn't help us with GameSalad.
Yes I know, I just meant if we could use something like paint code would solve the issue.
Hope this can be verified/solved soon. Changing this after the fact is a pain.
Back to the dirty topic of smeared images:
I wonder, @adent42, would it be possible to give us a third option to the resolution independence? One where WE supply the images in the 1x, 2x and 3x format? Just like one does in the native and traitor tools?
The thing is, even at 1242x2208 you still are rendering less pixels than at 2048x1536. granted a 3072x2304 is way bigger so you have a many more pixels and a higher beginning fidelity, however that doesn't necessarily translate into a better image at 1920x1080 and either way your not maintaining the aspect ratio.
I wonder, adent42, would it be possible to give us a third option to the resolution independence? One where WE supply the images in the 1x, 2x and 3x format? Just like one does in the native and traitor tools?
I was just typing up that exact idea!
I was looking at the screenshot requirements:
iPhone6+(3x):2208 x 1242
iPhone6(2x):1334 x 750
iPhone5(2x):960 x 640
iPhone3(1x):480x320
iPad Retina (2x): 2048x1536
iPad2(1x):1024 x 748
I wonder (and i saw this idea on apple's side) if we could create images like this:
so has anyone been able to find any documentation on how to manage graphic assets when targeting a universal build? I understand that now for just iPhone games, 2208 x 1242 is the number you want to go with. For iPad games, it is still 2048x1536. I can't find anyone posting online in any of the dev forums about what to do for a hybrid build, unless people are doing what I mentioned above and creating different assets for each device type, ... which is probably what they are doing.
@PhilipCC said:
I wonder, adent42, would it be possible to give us a third option to the resolution independence? One where WE supply the images in the 1x, 2x and 3x format? Just like one does in the native and traitor tools?
That was my suggestion (in an earlier post) too, to allow us (an option for those who care for it) to produce our own image sets, the advantages are obvious enough, it would have even been useful in the old days (last week), as it is our 2x Retina iPad projects are currently squeezed down for non-RI iPad through some unknowable and mysterious interpolation method (which I suspect is bicubic) - which means everything is antialiased, if we had control over this process (by doing it ourselves) we could tailor our smaller images to our needs, for an obvious example, you might want very fine lines on something, no problem on a Retina iPad, make them as fine as you want, a pixel wide even, but once this file has been digested by GS's servers the fine lined image made for non-RI iPad is just a grey mess of interpolation - if we had control over these aspects we could dive into the smaller resolution image and draw our fine lines straight onto the image file.
People making 8 bit games would also benefit from having control over their images like this.
adent42Key Master, Head Chef, Executive Chef, Member, PROPosts: 3,161
edited September 2014
Sorry, I didn't mean a full 3027 image of @3x. The idea would be to use images closer to the 2048 scale (notice that if you build a single image that would full screen on both iPhone6+ and iPad Retina it would be 2208x1536). Image for smaller RI devices and iPad would then be 2/3. That way you're not making your images 50% larger, it's just the RI scaled down images would match better to the smaller retina device at 2/3 size and the iPad would get larger images that better match it's scale. I'm gonna rearrange @jonmulcahy loading image list to illustrate what i mean.
So the images you are already making that target iPad retina will probably work fine, but if you make them slightly bigger, then you can get the best look possible out of both iPhone 6+ and iPad R. 2/3 of that size will look good on the iPhone6-4 and load slightly faster in those devices, and since iOS8 doesn't even support iPhone 3, we could forgo the 1x images all together.
If you have a Iphone6+ Resolution Independence project, then an image dragged into the actor pane should initialize an actor to 1/3 of its size, not?
It currently does the usual 1/2 size actor.
@jonmulcahy, have been testing and currently, starting with an iPhone6+ project and upsizing to iPad looks just as good/bad as the other way round with the current scaling.
To your question as to best practice for universal projects, info in other forums will not really help us here, as different engines do the viewport rendering, scaling and texturing in different orders. As far as I know GS renders the viewport first into a final image and then does the scaling/cropping(?). Maybe the GS techs can tell us what they think will be best in theory.
adent42Key Master, Head Chef, Executive Chef, Member, PROPosts: 3,161
As for the self service option, here is my proposal:
Move RI to a publishing time checkbox, so you don't have to decide at game creation time.
If you don't have any @#x images and enable RI, we would scale the images, just like we do now.
If, per chance, you were to include images for the @3x and @2x scales in the gameproj/images directory yourself and enabled the RI checkbox, the publishing server could just ignore converting the images.
Now here's the trade-off, if y'all are okay with this plan. You have to provide @3x and @2x images for ALL of your art. Our image loader does not "fall back" and there is good reason for this related to our upcoming graphics rework. So if you miss an image for a given scale factor, we will just show a blank actor.
Until we can add similar support in the tool, this will be officially an "unsupported" feature (anything that edits the gameproj but doesn't use the tool is unsupported). It will just be something advanced users can try to play with / tweak.
How does that sound?
adent42Key Master, Head Chef, Executive Chef, Member, PROPosts: 3,161
@Hopscotch good catch! We haven't enabled the @3x stuff yet, but I'll make sure to have it do that in a future RC.
Comments
Not sure what you mean by actual? I thought the new res was 2208x1242 which will be displayed on a screen 960w x 540h. Like the iPad res is 2048x1536 displayed on a screen 1024w x 768h.
Universal Binary Template - Universal Binary Template Instructions Rev 4 (Short) - Custom Score Display Template
The image will be scaled down from 3072 to 1920, again not a clean division, so graphic images will be blurred, but the small physical screen size will likely mean that you get away with the reduction in quality.
The physical pixel count on the screen is 1920 x 1080.
That number is an internal scaling value for developers, the screen itself isn't 2208 x 1242.
The Retina iPad is simply 2048 x 1536 pixels.
I'm all for a change in resolution, an upheaval like the move to Retina, it's usually a pain and takes getting used to - and initially more work as you adapt your projects - but it's always worth it in the end, but this change would mean the same adaptation, additional work and larger memory footprint for a lower quality output !
To answer your question about why @3x, it's because that's the way Apple specified things (I imagine the whole number multipliers make things faster for them).
The next RC will release with this system. If any of you did your artwork in Vector format, please try making your images 50% bigger, update your game, and publish. Everyone else try publishing with RI turned off.
See how it feels / looks. If you have a particular concern, send us your game and we can pick a few to test on the both the new devices and the older ones (I can't promise we'll get to your game, but send it to us anyway so we have a good variety to choose from).
For the time being, the best compromise between image quality and giant images is to provide images meant for @2x and turning off RI. Since it's the end of our day too, we'll pick this up again tomorrow (and we understand everyone's concerns, so we'll be thinking about this problem overnight too).
Just thinking about it now, I'm gonna see if we can get a slight adjustment in before release.
While it's not the cleanest solution in terms of super clean images, I'm gonna see if we can use the @3x images for iPhone 6 Plus + iPad RI and the @2x images for iPad / iPhone 6-4 RI. This works out even better since before I believe you getting the @1x images for non RI iPads which would be too low of resolution in most cases and aligns the max resolutions for images more closely. Someone from the team here will let you know when the next RC comes out whether we got this adjustment in or not.
Absolutely, I'm not saying this is the doing of GameSalad, I understand that Apple throws this stuff at you all the time, and it can't be easy keeping up with their ever-changing specs, I was more calling for a better implementation of Apple's latest demands (if that's even possible).
Vector artwork, especially, will suffer from being produced at 3x size then reduced to 2x and 1x.
That's kind of where I'd arrived at too, as the best compromise, 2x (2048 ) with RI off, and then scale 'up' (or down as we say in maths when something is smaller
) to the iPhone6/6/+ . . . . any qualitative difference on an iPhone6/6+ screen between a downscaled version (which is coming from a larger 2048 source file) and a native 1920 resolution image will largely be lost due to the small size of the screen.
@adent42 said:
This seems a little crazy to me, if I understand it correctly you are referring to your reference of 3072 ? Which would mean we have three image sizes . .
3x - 3072 x 2304
2x - 2048 x 1536
1x - 1024 x 768
So for the iPhone6+ which has a 1920 x 1080 screen resolution we would use the 3072 x 2304 image rather than the 2048 x 1536 image ?
And for the iPad RI which has a 2048 x 1536 screen resolution we would also use the 3072 x 2304 image rather than the 2048 x 1536 image ?
Would it not be possible to use the 2048 x 1536 image on the 2048 x 1536 pixel screen which would avoid the aliasing/blurring downscaling would bring ?
@adent42 said:
Ok, now this really is crazy !
. . . but how can 1x be too low for an iPad 1, it is exactly, pixel for pixel, 1:1, the perfect pixel count for the device !?
. . . . . .
EDIT . . . . Unless by 3x, 2x, 1x you mean those scales based on a 3x equalling 2048 ?
In which case that sounds like a good move, the compromise here (over the previous Apple 1x/2x system) is a quality loss on the non-RI iPads . . for example it would now be, using your compromise, mathematically impossible to access a single pixel on a non-RI iPad, so no neat lines or fine detail left un-anti-aliased (neologism alert)
but if anything should soak up the compromise it really should be devices that are nearing the end of their useful lives.
As for the iPhone6+ I would have thought that was an ideal candidate for a letterboxed/scaled project from a 2048 source file ?
If you scale an iPad RI project's 2048 pixels down to 1920 wide, that gives you a project size of 1920 * 1440, which means cropping from 4:3 to 16:9 chops 180 pixels off the top and the bottom of a landscape project, which isn't such an additional burden of unused pixels to carry around in a project (certainly much better than 3072 x 2304!) - you could literally add 16:9 guides to Creator's iPad project and have a viable iPhone6+ project - and like I say any loss of fine line fidelity through downscaling is less of an issue on the iPhone6+ given it's comparatively smaller screen size.
To add another voice to the discussion -- personally, I have RI turned off, always, and my apps run well on all devices, iPhone 4 up and iPad 2 up. I don't care much about supporting older devices than these.
From that perspective, the changes have absolutely no bearing on the resulting app.
As for the whole 'why 3072' discussion -- first off, @adent42 does that mean we can now import max 3072x3072 images into GS instead of 2048x2048? -- the reason this number is kicking around is only because we use iPad projects to build our universal apps. Thus the size is the resolution of an iPad, if it was @3x. If you start with an iPhone 6 Plus project, you will only need to use 2208x1242 graphics, and then those will scale down well.
So the problem is really caused by conversion between iPad and iPhone, not simply by the system of @3x, @2x and @1x itself.
Probably an error, lol !
Why specify 3x resolution for a new iPhone device and then use, as a reference, the original iPad size !? The result is this problematic 3072 size !? If Apple's request to make iPhone6+ images 3x was based on a starting size of 640 (3 x 640 = 1920 which is the iPhone6+'s actual size) it would make much more sense !?
And does it now mean that we should make sure our images are divisible by 3 instead of 2/4 ?
That 100 x 100 pixel default GameSalad actor is looking decidedly worried, yet his sexier 99 x 99 pixel cousin won't get the job either as he is unable to sit on a whole pixel value without smearing his image
Here's quick example of fine detail quality loss when working downwards from 3072 (bicubic interpolation). The image is enlarged with a perfectly divisible NN scale - so basically we are zoomed in on the actual pixels.
The left column has started life at 3072 (not shown), then was scaled down to 2048, 1920 and 1024, The right column started life at 2048 and was scaled down to 1920 and 1024 (always from the original source).
Obviously the 2048 image in the right column is perfect as that was the size it was generated at, whereas the 2048 image in the left column (which came from a 3072 image) is already starting to look compromised (hey GameSalad's 8bit graphics game makers, watch out !! Your days are numbered
) - moving down to 1920 the 2048 source is still looking pretty good, with a little aliasing becoming noticeable, whereas the 3072 source is fairing much worse - and by the time we get to 1024 the quality is noticeably poorer all round, as to be expected, but the 2048 source does seem to be doing a much better job at holding the lines.
I'd go as far as to say that the 2048 source is doing a better job at holding fine detail definition at 1920 than the 3072 source is at 2048. Which in part comes back to an earlier point, that you often hear people saying that downscaling is fine whereas upscaling is guaranteed quality loss, but in reality all scaling results in compromised quality.
You guys having fun without me?
May I point out that the iPhone6+ project dimensions are wrong in GS to begin with.
They are set to 540x960. However this is based on the post 0.87 downsampling that the current phone does in preparation for future higher resolution displays - actually squeezing 23 pixels into 20 real screen pixels AFTER rendering, leading to the physical 1080x1920 pixels.
The actual virtual point size of the phone is 414x736, leading to 1242x2208 @3x.
The value of 1080x1920 should be of no concern to us as this downsampling is not under our control and may change in upcoming models.
I thus believe the project dimensions should be 414x736, otherwise there will be a double loss by first downsampling during rendering, then again by the device after rendering.
To support my case, XCode actually requires the launch image for the iPhone6+ to be 1242x2208 pixels.
p.s. The dimensions for the normal iPhone6 projects are correct.
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
Damn, this is getting complex ! lol !!
So the delivery size is 1242 x 2208 which is then (hardware) downscaled to 1920 x 1080 ?
Of course this won't effect the image quality issues, as ultimately your artwork will end up being mapped across the actual devices pixels.
I think I'm going to get my old black and white CRT out and watch the noise for a while.
Well, that's the reason I don't use RI in the first place (better to use just the original files) and am developing methods how to have pixel art always rendered at its native resolution -- though I'll need to do some tests on the iPhone 6 Plus once a friend or someone crazy around me gets one.
@Socks @Hopscotch and @pHghost
A few days ago I found an article that helped me understand the subject better because it is represented graphically. (A similar link to the one that adent42 put up earlier today.)
This one is even more comprehensive: See: http://www.paintcodeapp.com/news
I found this when looking into this, explains it a little bit
Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left
Yes, there is even a version of the normal iPhone6 that renders at iPhone5 resolution and then does upsampling
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
The paint code video at the bottom is what we need.
@BBEnk I just edited my comment with a link to a better graphic (while you were writing) and the video is a nice ad for PaintCode, but it doesn't help us with GameSalad.
this is headache inducing!
Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left
Yes I know, I just meant if we could use something like paint code would solve the issue.
I have submitted the project dimensions problem as a bug.
http://bugs.gamesalad.com/show_bug.cgi?id=332
Hope this can be verified/solved soon. Changing this after the fact is a pain.
Back to the dirty topic of smeared images:
I wonder, @adent42, would it be possible to give us a third option to the resolution independence? One where WE supply the images in the 1x, 2x and 3x format? Just like one does in the native and traitor tools?
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
The thing is, even at 1242x2208 you still are rendering less pixels than at 2048x1536. granted a 3072x2304 is way bigger so you have a many more pixels and a higher beginning fidelity, however that doesn't necessarily translate into a better image at 1920x1080 and either way your not maintaining the aspect ratio.
Follow us: Twitter - Website
I was just typing up that exact idea!
I was looking at the screenshot requirements:
iPhone6+(3x):2208 x 1242
iPhone6(2x):1334 x 750
iPhone5(2x):960 x 640
iPhone3(1x):480x320
iPad Retina (2x): 2048x1536
iPad2(1x):1024 x 748
I wonder (and i saw this idea on apple's side) if we could create images like this:
image@3x
image@2x
image@2x-ipad
image
image-ipad
Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left
so has anyone been able to find any documentation on how to manage graphic assets when targeting a universal build? I understand that now for just iPhone games, 2208 x 1242 is the number you want to go with. For iPad games, it is still 2048x1536. I can't find anyone posting online in any of the dev forums about what to do for a hybrid build, unless people are doing what I mentioned above and creating different assets for each device type, ... which is probably what they are doing.
Send and Receive Data using your own Server Tutorial! | Vote for A Long Way Home on Steam Greenlight! | Ten Years Left
@jonmulcahy @Hopscotch I really like this idea! If we had this then everyone could create it however they want.
Follow us: Twitter - Website
That was my suggestion (in an earlier post) too, to allow us (an option for those who care for it) to produce our own image sets, the advantages are obvious enough, it would have even been useful in the old days (last week), as it is our 2x Retina iPad projects are currently squeezed down for non-RI iPad through some unknowable and mysterious interpolation method (which I suspect is bicubic) - which means everything is antialiased, if we had control over this process (by doing it ourselves) we could tailor our smaller images to our needs, for an obvious example, you might want very fine lines on something, no problem on a Retina iPad, make them as fine as you want, a pixel wide even, but once this file has been digested by GS's servers the fine lined image made for non-RI iPad is just a grey mess of interpolation - if we had control over these aspects we could dive into the smaller resolution image and draw our fine lines straight onto the image file.
People making 8 bit games would also benefit from having control over their images like this.
Sorry, I didn't mean a full 3027 image of @3x. The idea would be to use images closer to the 2048 scale (notice that if you build a single image that would full screen on both iPhone6+ and iPad Retina it would be 2208x1536). Image for smaller RI devices and iPad would then be 2/3. That way you're not making your images 50% larger, it's just the RI scaled down images would match better to the smaller retina device at 2/3 size and the iPad would get larger images that better match it's scale. I'm gonna rearrange @jonmulcahy loading image list to illustrate what i mean.
@3x
iPhone6+(3x):2208 x 1242
iPad Retina (2x): 2048x1536
@2x
iPhone6(2x):1334 x 750
iPad2(1x):1024 x 748
iPhone5(2x):1136x640
iPhone4(2x):960 x 640
@1x
iPhone3(1x):480x320
So the images you are already making that target iPad retina will probably work fine, but if you make them slightly bigger, then you can get the best look possible out of both iPhone 6+ and iPad R. 2/3 of that size will look good on the iPhone6-4 and load slightly faster in those devices, and since iOS8 doesn't even support iPhone 3, we could forgo the 1x images all together.
If you have a Iphone6+ Resolution Independence project, then an image dragged into the actor pane should initialize an actor to 1/3 of its size, not?
It currently does the usual 1/2 size actor.
@jonmulcahy, have been testing and currently, starting with an iPhone6+ project and upsizing to iPad looks just as good/bad as the other way round with the current scaling.
To your question as to best practice for universal projects, info in other forums will not really help us here, as different engines do the viewport rendering, scaling and texturing in different orders. As far as I know GS renders the viewport first into a final image and then does the scaling/cropping(?). Maybe the GS techs can tell us what they think will be best in theory.
@Socks, why are you not in bed yet, its 4:48!
MESSAGING, X-PLATFORM LEADERBOARDS, OFFLINE-TIMER, ANALYTICS and BACK-END CONTROL for your GameSalad projects
www.APPFORMATIVE.com
As for the self service option, here is my proposal:
Move RI to a publishing time checkbox, so you don't have to decide at game creation time.
If you don't have any @#x images and enable RI, we would scale the images, just like we do now.
If, per chance, you were to include images for the @3x and @2x scales in the gameproj/images directory yourself and enabled the RI checkbox, the publishing server could just ignore converting the images.
Now here's the trade-off, if y'all are okay with this plan. You have to provide @3x and @2x images for ALL of your art. Our image loader does not "fall back" and there is good reason for this related to our upcoming graphics rework. So if you miss an image for a given scale factor, we will just show a blank actor.
Until we can add similar support in the tool, this will be officially an "unsupported" feature (anything that edits the gameproj but doesn't use the tool is unsupported). It will just be something advanced users can try to play with / tweak.
How does that sound?
@Hopscotch good catch! We haven't enabled the @3x stuff yet, but I'll make sure to have it do that in a future RC.