Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I've been wondering how to archive kind of zooming behavior with 2D graphics. I'm pretty sure that this is not right term, but let me try to explain my thoughts.

Ok, let's start by defining that we are using here tileset with 16x16 tiles. That would something like this:

http://i49.tinypic.com/20r43r7.png

When we're looking these graphics here, all the tiles look pretty small. Now, when we load this tileset to RPG Maker 2K and look at it in game, it looks something like this:

http://i49.tinypic.com/mt353a.png

Like you can see, image is more zoomed and tiles look a lot more bigger than in real tileset. How do you think this kind of effect is done in code and how I can do it?

share|improve this question
    
just plot every pixel as 2x2 pixels (or 3x3, or 4x4..).. Since there's also other, more involved upscaling methods (like eagle etc), I'll let someone else answer. –  Jari Komppa Dec 26 '12 at 8:21
    
@Wondermike, it's not zooming. It's called scaling. Zooming would be "magnifying" from the initial "scale" of your view. I assume it's just done by transformation matrix ( well...I don't see a different way). Stretched to meet he viewport/screen bounds. –  Sidar Dec 26 '12 at 8:28
    
I think I understand what you're saying and it makes sense. I'm still waiting for someone to make it more clear. –  WonderMike Dec 26 '12 at 8:32

1 Answer 1

up vote 3 down vote accepted

The term you're looking for is scaling, not zooming.

If you search scaling algorithms, you'll find a very large number of them. Different scaling algorithms have different qualities and are optimized for different purposes. Some are designed to scale up low-quality bitmaps while making them look smooth and pretty, often used when trying to play games made for old resolutions like 320x200 at newer monitor resolution sizes like 1920x1080.

Your graphics hardware has several simpler scaling algorithms naturally built in. If you try to render a 16x16 texture to a square that is 64x64 in size, OpenGL/Direct3D will just do the right thing. They'll also handle uneven sizes. The same is going to be true of whatever other low-level 2D graphics API you might be using.

The simplest approach is to just change your sample rate. Say you have a 16x16 bitmap that you want to scale up to 32x32. That is a 2x increase in dimension, so you would "sample" the source bitmap twice in each dimension (for a total for four samples). Example:

Source = 1 2
         3 4
Destination =
         1 1 2 2
         1 1 2 2
         3 3 4 4
         3 3 4 4

Notice how for the first row in the source, we wrote out each element twice in the destination. Likewise, for each row in the source, we wrote out two rows in the destination. 2x scale factor.

In code, that might look something like following (in one dimension; should be simple enough for you to expand to two dimensions):

scale = in_width / out_width;
for (dx = 0, sx = 0; dx < out_width; ++dx, sx += scale)
{
   output[dx] = input[sx];
}

Note that scale is the reciprocal of the scale factor. That is, a 2x scale would actually be 1/2 in the code above. The terminology can be a little ambiguous and confusing, unfortunately.

The algorithm will handle scaling up and down, to even or uneven sizes. If you expand it to two dimensions properly, it'll even handle scaling to different aspect ratios (e.g., changing a square input bitmap to a rectangular output). The results won't be great, but they'll work. I wouldn't use that code in production, but if you want to get your feet wet with some basic bitmap manipulation code, it's as good a starting point as any.

There are much more robust and efficient ways to write that, but I'd guess those might be a bit beyond your current skill level.

If you are interested in higher quality scaling algorithms, or more optimized scaling algorithms, take a look at the excellent WikiPedia Image Scaling article, which covers most of them and has either explanations of the algorithms or links to pages with explanations.

share|improve this answer
    
Thanks for answering Sean. This explains pretty much what I was after. For some reason I've never understood this properly, but now I finally got it. I'm experienced programmer, but graphics have allways been my Achilles' heel. I will look at those algorithms and I'm sure I'll be fine. –  WonderMike Dec 26 '12 at 9:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.