Common pattern to scale "real units" to pixels?

Question

This is a follow-up question to this other one.

I would like to know if there is a common/typical/best pattern to scale my representation of the world (currently 160Kmx160Km) to fit it to the drawing area (currently 800x600 pixels).

I can think of at least four different approaches:

Naïve one (the way I did it so far). I implemented a global function sc(vector) that will simply return a scaled down copy of the vector passed in. This of course works, but obliges me to write code like:

drawCircle(sc(radius), sc(position))

Wrapping functions. I could define several functions, each of them wrapping the original middleware one. For example I could define myDrawCircle that would first scale the arguments that need scaling, and then call drawCircle with the latter. This would make my code perhaps more readable and easier to maintain, but I should write a lot of wrapping functions, which sound silly.

Function decorator. I could simply decorate the existing middleware functions, providing automatic scaling for all the parameters that are an instantiation of the class Vector3D, but the problem is that those functions also work with the same parameters being list or Vector2D too, and the decorator would have no way to know which lists need to be scaled (the radius for example) and which not (the RGB values).

Surface initialisation. When defining the surface I am going to draw on, I could define the scaling factor (so that I would then use metres and not pixels as parameters). This would work transparently for me and would be my solution of choice, but of course it should be implemented in the middleware, so it's not an real option.

...anyhow: since this is a very common problem, I wonder if there is an established pattern that elegantly solves this problem that I failed to find.

PS: For this project I am using python (with pygame), but - although a python/pygame-specific answer is very appreciated, I'm more interested in the general/high-level description of the pattern rather than its concrete implementation.

Thank you in advance for your time and expertise.

Answer 1

The standard way of doing that is to set up a transform matrix to do the conversion during rendering. For 3D rendering it's the view transform matrix for the camera that does it.

Most 2D APIs have a way of specifying a view transform too, as either a 2x3 matrix or as a separate scale, translation and rotation.

A quick look at the pygame documentation suggests you'll have to implement a view transform matrix yourself. Does it let you derive your own class from it's surface class to enable you to add that functionality?

Answer 2

since this is a very common problem, I wonder if there is an established pattern that elegantly solves this problem that I failed to find.

Usually people do not attempt to perform run-time scaling in 2D games. I don't agree that it's a common problem. If people want a mini-map or some other fixed rescaling, there is often a new set of graphics done for this purpose. It's rare that you need any single routine to run at 2 different zoom levels in a 2D game.

If you use a 3D API, you can get this functionality for free - just change the camera/viewport parameters.

PyGame is a very old API and unfortunately is only really suited to 2D. Even if you could work out adequate scaling systems for the different zoom levels, the performance will not be good enough and the appearance is likely to be unacceptably bad.

I would advise that if you want to zoom in and out a lot, you move to a modern 3D API as soon as possible. I would recommend pyglet but there are likely to be others too.