Math problem in menu

[iCore]

Heya!

Now it's the third day that I can't solve a menu problem, so it's time to ask for some pro mathematician and menu editors' help.
So now I'm working on a Call of Duty 4 mod (called APB Mod), and I'm making a 2D map in menu (if anyone is playing APB, it will be something like the respawn-slection menu); and well, I want players to be able to zoom on it, and zoom out. The menu is working fine, except that the zooming is not done linearly. Here is a video about it: Xfire video. The zoom is controlled by a variable, between 0 and 1. The X coordinate is changing based on the percentage of the zoom variable this way:

100 percent: -99.2
90 percent: -79.7090
80 percent: -54.9333
70 percent: -26
60 percent: 5.94
50 percent: 40.5
40 percent: 77.2
30 percent: 115.57
20 percent: 155.37
10 percent: 196.37
0 percent: 238.4

As you can see, the smaller the zoom variable is, the bigger steps will be in the X coordinate.

So I'd need some help in figuring out, why the hell is it happening.
Here are the definitions and the map item itself:

#define ZOOM dvarFloat("zoom")

#define placeX(o, q) dvarInt("width") / 2 - (dvarInt("respawn_x") - o) / (20 - ZOOM * 10) - (q)
#define placeY(o, q) dvarInt("height") / 2 + (dvarInt("respawn_y") - o) / (20 - ZOOM * 10) - (q)

itemDef
{
	style			WINDOW_STYLE_SHADER
	rect			0 0 0 0 HORIZONTAL_ALIGN_NOSCALE VERTICAL_ALIGN_NOSCALE
	exp				rect X(placeX(0, 512 + ZOOM * 512))
	exp				rect Y(placeY(0, 256 + ZOOM * 256))
	exp				rect W(1024 + ZOOM * 1024)
	exp				rect H(512 + ZOOM * 512)
	exp				material("lookout_" + dvarString("mapname"))
	visible			1
	decoration
}

width and height are the resolution of the game (ie 1024 and 768), respawn_x and respawn_y are the origin. Basically it should be broken even if you write 1000 for all the 4 values, since I think the problem is somewhere in the usage of ZOOM. The starting, and the end points are perfect.
I have tried millions of combinations, but I couldn't get it work. Any ideas are welcome.

Thank you,
iCore

EDIT (07-27 23:13): Viking also checked, and according to him, calculations are fine; so maybe there is an other problem, but still no idea what can be :/