#Scaling in gideros code
I'd suggest adding a flag in project settings to turn this off to give those developers that want the freedom the ability to do so but I feel that then we'll get into a position where code people share will only work if the flag is on or off. Point is, they have control over it.Īnyway, that's the 4 I can think of at the moment but I'm sure there's more. A developer could actually use images that display larger on lower resolution phones etc. Every file access on mobile carries an overhead - it may not be much, but it's all about efficiency and anything that can be done to improve that is a bonus.Ĥ. And by association this should solve the problem that the downloaded artwork would be in a different directory to the lowest resolution version as that just wouldn't be needed any longer.ģ.
#Scaling in gideros download
The ability to have your app download art assets suitable for the device it's running on without needing to have the lowest resolution version as well. The scaling on BMFont (or any other such class that would work with different ratio images depending on resolutions, for texture memory efficiency, but doesn't currently without clunky changes).Ģ. If you took this away there's a few things that would sort themselves out:ġ. Being able to scale an image exactly is a pretty fundamental use of any graphics package but in writing Gideros in a way that tries to catch such fundamental mistakes, and compensate for them, it's actually dumbing down the system and taking control away from the developer. Do you mind if I make a case for why I don't think that's in the best interests of Gideros. Have I got the wrong end of the stick here? (Possible!) This would also get around the situation I thought of a while ago and posted about, one where you download higher resolution imagery where required for an app rather than including it all as standard in the package. I have no idea how much work this would be so apologies if it's a huge undertaking. Wouldn't changing the core to only base things on the higher resolution images (and if not available, open lower res and scale up accordingly) be better for Gideros as a whole? There must be an overhead in opening the SD images first. I'm using bmGlyph now but simple resizing for lower res versions of a font does lead to some unwanted side-effects, such as alignment issues. That's because of alignment and font sizing issues (plus differences in text effects you may want to apply) so basing scaling and sizing off the sd version leads to incorrect rendering (this is using BMFont). As we're setting image extensions and scales in the project properties, why is this being done in this way - can't you just open the correct resolution image and work out the correct size from the scales set in the project? Surely it's the developer's responsibility to ensure that images are really x 2 in dimensions.įor GlyphDesigner the problem is arising that there's no guarantee that a higher resolution font png will actually be double the size of the sd version, for example. This seems a little wasteful and also is the reason behind GlyphDesigner not working correctly with the system.
I remember mentioning a while ago that for higher resolution images, Gideros first opens the SD image to get dimensions, to scale accordingly, before opening the actual asset you want to use.
0 kommentar(er)
