Raster graphics

How are raster graphics renderers usually organized?

I'm making a simple bitmap (as in, the file format) renderer in C++ as a learning project. I've got a BitmapReader class which takes in a FILE handle to a .bmp and provides basic services such as retrieving the pixel at row X and column Y, retrieving all of the pixels of row X, and so on.

Right now the renderer just runs a loop that calls getPixel(row, column) over and over until the image is complete, but of course this is very slow.

Row by row would be faster, and it would work in most cases, but what about cases where it wouldn't? Off the top of my head I can only think of one, which is when you're zoomed out. I assume the basic principle is to grab a block of pixels from the bitmap, average them according to some algorithm, and then display the result. In which case you'd have to go pixel by pixel rather than row by row. How is zoom-out usually implemented?

What are you even doing?

>>2
A program to read standard Windows V3 BMP files and display their contents. I want it to be able to pan across and zoom in and out of the image. It's to run on the Nintendo DS, although I don't think that's relevant.

I'm just wondering what the basic process is for rendering raster graphics files, and also asking how zoom-out is usually implemented.

movsd is your friend.

Oh boy. Listen buddy, just go and use some prebuilt library.

To answer your question more specifically, look up bilinear interpolation, mip-mapping, bicubic interpolation, and lanczos resampling, for starters.

Also, a friendly hint: competitive implementations use real-time code generation to build optimized filter kernels for whatever magnification/minification factor is desired at the time. Many implementation use separate horizontal and vertical resizing passes, often interleaved — it must be done with care if you want reasonable speeds.

You can check out avisynth, ffmpeg/libswscale and chromium/skia for some reasonable source code.

PS: Nowadays you're much better off rendering quads in a 3D context, if all you want is draw stuff to the screen.

PPS: Classic sprite games don't usually zoom out. When they did, it was nearest neighborhood sampling (you can't do much better with palette graphics). In most cases they used prebuilt sprites of all the needed sizes.

>>3
The Nintendo DS is capable of zooming sprites in hardware.

>>5
Woah, I'm not planning on using any of this code for more advanced projects. This is my first non-trivial program for the NDS, I'm just getting familiar with the platform. Thanks for the tips and the search terms.

What kind of faggot writes for the DS.  Get some dignity

>>6
The Nintendo DS also uses nearest neighbor interpolation, even for textures. Then again, considering it uses low-res textures that might actually for the better.

>>9
Also, a friendly hint: competitive implementations
Are you telling me there is competition for image zooming applications? I'm sorry but this is complete bullshit; you might say "state of the art implementations", but saying someone won't use a particular image application because it cant zoom fast enough is extremely pathetic.

>>10
I wrote my particular image application which can zoom faster than (almost) any other's. I use it to view porn.

>>11
You need to zoom quickly due to your premature ejaculation problems, am I right?

>>12
^{HAW HAW YOU ARE INDEED CORRECT}

>>10
The main reason I switched from eog to gthumb is the speed with which it zoomed.