Virtual resolutions and image sizes.
Monkey Forums/Monkey Programming/Virtual resolutions and image sizes.
| ||
| Hi Guys, My game is at a stage now where I'm wanting to get my final artwork in there, I'm currently using Ignition and virtual resolutions. I've seen various discussions regarding having different resolution images for differing device resolutions so you don't get blurred images. I was thinking though, instead of having different resolution images, would having just one larger image resolution and scaling that for the current virtual res do the trick. So for instance, I'm currently using 10 pixels = 1 metre, so one of my unit sprite images is 50 pixels wide meaning it's 5 metres in length. If I was to use 100 pixel sprites instead and scale them by 0.5 when they are loaded would this then look nice when the device resolution scales up? |
| ||
| Scaling images (especially down in size) is quite possible and generally keeps the quality. The side affects there is that your mobile devices will suffer from a larger file size and memory usage. So your game will take longer to download, and will take more from the mobile device when running it. Also, keep in mind that scaling itself takes time too. If you scale the image, you prolly should do that once at load time and then keep the scaled image and let go of the larger one. Scaling down by 0.5 should be ok. That said, I'm not a big graphics buff by any means. This is from my experience alone. Hope this helps :) |
| ||
| i tested this time ago, i get much better performance with pre-scaled images. if you scale down image by 50%, this means, that you have only 1/4 of mem buffer size to copy i decided to use 2 image sizes: -640 virtual screen for screen < 1024 -1280 virtual screen for screen >= 1024 |
| ||
| I agree dragon. I'd pefer pre-scaled over scaling on the fly. Sometimes you need to scale and its ok then, but when you can get away from scaling, its best to go with pre-scaled images :) |
| ||
| Thanks for the input guys, I will go with the pre-scaled solution, it sounds like the best route. |
| ||
| scaling itself do not slowdown a program. here is no difference, if you have 100% scaling or 99% scaling or 50% scaling... only one is important: how many data must copied from one buffer to another. and if you have prescaled (50%) images, you need only 1/4 of the data to copy. in other words: 50% prescaled images is a optimization for small screens. this is important, because small devices are often slower than devices with big screens. |
| ||
| Although the scaled size doesn't make any difference in program execution, PERFORMING scaling at the time of execution takes CPU cycles. Which is what monotonic was talking about. If I have one large image, and depending upon the device it runs on, the image gets scaled down when the app starts. It could be re-scaled if the user changes resolution. Changing the resolution, kicks off a scaling action unless there are images that are pre-scaled and ready to use without scaling them again for the resolution. |
| ||
| What I'm trying to do is remove the need for multiple copies of the same asset. My unit atlas image is quite large already, about a meg. If i have three copies of this at different resolutions its going to add about 1.5-2 megs to the size. Then there's all of the terrain and building assets. Plus a lot of my calculations are based on the scale i mentioned earlier, I'm just trying to find ways of reducing the amount of work i have to do. |
| ||
| I gotcha. Another thought, depending upon how you want to go about this, is to do something like Gameloft and others do. Once you get the base app installed (without assets), figure out what asset resolutions you need for the given device and download those assets. Sure this make you needing multiple sets of assets, but it will result in a smaller initial download and will fit the device accordingly for performance. Plus you get the benefit of using pre-scaled assets vs scaling on the fly. Depending upon the resolutions you pre-scaled and the device resolution, you may still need to perform a scaling upon initial execution of the assets for that particular device and hold on to the scaled size for the duration of the execution. Just tossing out ideas :) |
| ||
| Ugggh... I hate that, especially on Phone games. If I open up an app that I've just installed, and it instantly goes "Hang on, need to download some more" it's an insta-delete for me. No questions asked. Whatever it is, no matter how awesome it is, it's just not worth faffing about. I couldn't care less if it's at the top of the charts, if everyone says it's the best game in the universe, or whatever. When I tap the icon, I want the game playing in my face, not a 3 hour wait before anything happens. Same goes for slapping tutorials and other gubbins in my face, too. Phone = Battery life + Data usage costs .. If it's messing about, then NO!!! Tap - Start - Play - Quit, that's the way it should be. The only exclusion to my rule is Words With Friends which takes SUCH a stupidly long time to load up, but is a necessary evil, because the official Scrabble is 1000 times worse! |
| ||
| I couldn't agree more ElectricBoogaloo! I'd rather just be able to play the game once I downloaded it and installed it. It does suck (even with unlimited bandwidth) to wait for a game to grab the rest of its goodies. I was just giving alternative ideas to help solve this issue. It could only be a few seconds to download the additional content. I also despise the games that take two hours just to download to begin with, then they produce update after update right back to back. I'm thinking that they have poor testing on their game/app to make them need to release so many updates so close together. I'll delete those apps as well. I do realize that Google has a size limit on a single file download from their store. To get around that, the additional file download is needed. |
| ||
| Some people write to a low resolution pixmap and then scale that each frame to fit the screen. That method has lots of advantages if you don't mind a pixelated display-- things like grab image, color cycling and other full-screen processing are much faster at low resolution. The guy who did Meganoid talks about this on his blog. Another idea is drawing your images in a custom editor that saves the image as a series of tool uses rather than as a bitmap. The images are then reconstructed at first runtime and saved. The disadvantage is some processing on first run, but you should end up with images that are resolution independent. It would depend on your application whether that would be worthwhile or not but it was how creature and world data was saved in Spore, to make it tiny so that they could encode it into their little graphical creature cards with something similar to steganography. You can also amortize image loads and first run processing into different chunks to lessen the subjective wait time. Do some on first initial load before displaying splash screen, then some more during your logo splash screen, then more during display of initial game screen. Then have your first level only use a subset of your assets, do a small amount of conversion between frames at the very start of the game, etc. If you only have one or two sprite sheets, you should be able to load, scale and save them on first run without anyone complaining esp if you hide the processing. Nintendo guys were the masters of hiding runtime processing between menus and level intro screens. A lot of their little intermissions had the function of hiding preprocessing and graphics loads. I have also wondered if THQ do this during their famous five-minute intro movies which are unskippable on the first run of the game. Let me know what you come up with, this sort of technique tends to be interesting. |
   |