shinkan wrote:Mipmaps are created from exported by C2 sprite sheets, right?So if you design your sprite frames so they all end up on one (or more) 1024x1024 (or any other power of 2) sprite sheet all should be fine.

Yeah, I think you are right. I haven't thought about that.But I guess if you wish to see a smooth result on preview you will need to use power of 2 textures.

Last edited by Animmaniac on Fri Oct 02, 2015 10:07 pm, edited 1 time in total.

Just trying to figure out the best way to use HD art in C2, man... That is, retaining image quality, scaling well with camera zooming & multiple resolutions, not wasting memory / bloating project / losing performance, and unison between object types such as sprites, tiled BGs, 9-patches, tilemaps, and 3rd party image plugins.

Everyone says something different or contradicts themselves. Now there's talk of mipmapping power of two textures on export? So there will be discrepancies between preview and final build image quality? Oy...

Tokinsom wrote:Just trying to figure out the best way to use HD art in C2, man... That is, retaining image quality, scaling well with camera zooming & multiple resolutions, not wasting memory / bloating project / losing performance, and unison between object types such as sprites, tiled BGs, 9-patches, tilemaps, and 3rd party image plugins.

Everyone says something different or contradicts themselves. Now there's talk of mipmapping power of two textures on export? So there will be discrepancies between preview and final build image quality? Oy...

I learned that long time ago, that construct is the only software i think, where you have to optimize before starting a project. But you could replace graphics later.

In terms of scaling if you scale in two's, for example 1 to 0.64 or 1 to 0.62 or 1 to 0.48 or 1 to 0.50 or 1 to 1.12 etc images will look better then if you would scale to something like 0.65. On the side note, same goes for any form of movement, which also will display sprite better.

I suggested you making game in smaller or small resolution, but with big assets, because it does make a difference in the performance after upscaling using high quality scaling, and you can use solely sprites. But it is true you would need to stick power of 2 textures, or at least large textures should be sized evenly, so 2,3 or 4 times bigger. Another reason was that it will restrict you from having too many objects on the screen. In reality having more then 100 objects on screen can start bringing performance dips, but also that will mean you have a lot of objects on the layout, so the loading will be longer.

Continuing on resolution, if you can, rather use 960x540 (or half of that )instead of 720, as it is exactly proportional scale of hd and upscaled to full hd looks much better then 720.

But in the end, a lot depends on the game you are making. What I was suggesting is certainly good for action games. If you are making adventure game, then you need to use diverse assets, thought in this case, due to nature of the game, it will not cause any issues.

And remembered another trick to make assets look better, is to set default zoom to slightly bigger or smaller number. This will glue your assets a bit, achieving more of a painting or drawing look.

I'm a little confused if you mean designing a HD game, as in for 1080p, in which case you just set your viewport to 1920x1080 and off you go. So I'm guessing you really mean high-DPI graphics so designing for different display DPIs (aka the device pixel ratio, or number of physical pixels to CSS pixels, e.g. 2 for 2x retina devices).

The intent in C2 is just to design it all at the highest resolution, and let letterbox scale shrink it down where appropriate. There are so many device pixel ratios out there (including 1.325, 1.33, 1.5, 1.7, 1.8, 2.37, 2.4...) that designing artwork for each level is insane, and even if you do 1x, 2x and 3x, there's always going to be a bunch of devices scaling that anyway, so it seems you may as well go with the highest and let the GPU scale it down.

Mipmapping improves the downscaling quality and performance. It uses a slower, high-quality downscaling filter at initialisation time to take in to account all the image's pixels. It basically turns the image in to an array of images at sizes 1, 1/2, 1/4, 1/8... down to 1px big. Then if the image is half as big it renders from the 1/2 size image. If mipmapping is not used it just linear samples down the full-size image, which requires more GPU bandwidth since it's sampling a larger area of pixels, and the quality is inferior because linear sampling only ever considers a 4x4 patch of pixels at the sampling point, which is insufficient for more than 50% downscaled images. Beyond that it skips areas of the image which causes aliasing artefacts that make it look "crisp". Some people subjectively seem to prefer that look, but it really is actually technically worse quality.

It is a bit of a problem that WebGL currently does not support mipmaps on non-power-of-two images. This means in preview mode often you won't see the effect of mipmaps, regardless of your "downscaling quality" setting. However after export, most images are assembled on to power-of-two spritesheets and then mipmapping can take effect. I can see this inconsistency is frustrating, but it is fixed in WebGL 2 (which can mipmap any size image), and in-editor spritesheeting is a goal of C3 which would help preview work identically to export.

So anyway if we can assume for a moment that mipmapping is enabled, then with all artwork at full resolution, the GPU is basically rendering from high-quality automatically downscaled source textures by using the appropriate mip levels. This should resolve any question about performance. It does use more memory on devices which don't need the extra detail. On the up side if you zoom in or upscale images then you get the extra detail back. Perhaps there could be a feature to save memory in this case. However with good game design and C2's existing layout-by-layout memory management, this already seems largely mitigated (I don't hear much about it). Also you probably need to optimise the full-resolution version of your game anyway, since corner-cutting device vendors will happily stick an insanely high-resolution display on a weak device with not much memory, so the memory use of the full-res version is still a concern.

I do think there are some features we could add to make this easier though - in particular I think if the image editor had a way for you to tell it what the device pixel ratio of the source image is, it could get the default size in the layout view correct, and improve the detail of tiled backgrounds, etc.

Ashley wrote:Beyond that it skips areas of the image which causes aliasing artefacts that make it look "crisp". Some people subjectively seem to prefer that look, but it really is actually technically worse quality.

It's kinda like FXAA or TXAA, it removes aliasing great. But it also blurs the image a lot, making overall image quality poor.

I guess it depends on the art style as well, art with lots of details will be impacted badly with blur of mipmaps as I found for myself.

@TokinsomDon't worry about it so much since you can change the art pretty quickly. My current project is 1080p native. I use source images that are exactly the size of sprites in-game, there's no scaling issues. If you want to maintain crispness or details when zooming in, then use image sources that are 2x as large as your sprites. It's important when you do that, use Downscaling on LOW quality to avoid blurry images.

Hmm...alright I think I'm getting the idea now. Most of the confusion came from the art that I was given. It's about 4x the size it needs to be even for a 1080p game, and not all of it was drawn "to-scale". For example, the source image for the player is almost 1/4th the size of an entire level image. He'll need to be scaled down roughly 70% just to fit! Looks like we need to spend some time scaling all the source images so they are closer to the final product, and minimize in-editor scaling so we can still use object types that don't allow it like tiled backgrounds and 9-patches. Hoorah for batch processing.