Whenever I've used a zoom event, the picture quality always gets unreasonably pixelated when I do a zoom in. Now, it's understandable when the image's dpi/resolution is low, but when it's high and it still pixelates it seems strange.
As a test, I used Windows picture viewer and zoomed in to the same image at the same distance as what I zoomed the image on in Construct. The one in picture viewer had its quality still in tact, the one in Construct was very pixelated.
Is there a type of way that Construct processes a zoomed image that causes this? And, is there any work around?
Dpi is irrelevant here as it refers to printing. Anything you see on the screen is based on pixels.
Rule of thumb
Scale down less quality loss.
Scale up high quality loss.
^^^ That's not relevant to the core of his question, and I'm going to give him a lot more credit and say that he would know as anyone who's used a computer for a day or two would know that as an image increases in size it decreases in quality, besides that's not what his question appears to be wondering about anyway. I take it that since he said "dpi/resolution", he was establishing that he was using images of high quality.
I've noticed the same thing he's described. I can take an image into another program and zoom it (up to a certain point) and the quality remains high as it should for a large high-res image, but in Construct the same image is noticeably lower in quality and is fuzzy and pixelated when I use a zoom event and zoom it up to the exact same point. Most users of this program probably don't use many--if any--images that are large in pixel size and high in memory and detail so the quality loss would be less noticeable to those users (or simply more tolerable depending on the type of game) in that case.
Develop games in your browser. Powerful, performant & highly capable.
Well if you follow the link, it describes the different methods of scaling much better than I can here.
Most notably are the first three types. The first two are equivalent to what you have in Construct for the sake of speed. Then the third is the most commonly used, when speed is not an issue.
So without being trying to be completely inappropriate, its just not an image viewer, and wasn't designed for large "high-res" images.
[quote:3czly5oh]Rule of thumb
Is actually a big hint on how to deal with the issue.
Another would be that you can shrink images in the layout editor without quality loss.
And that when you take them back to their original size(runtime) there is no loss either.