adjust images in any screen resolution

[Nahuel]

as we all know, the way to indicate the position of an image on the screen is given by the vector "position"

float drawpic(vector position .....

I made a hud , it works fine in 640 * 480, 800 * 600 , 1024 * 768 so this is in 4:3 video radius size, but if i change the screen resolution to 16:9 or another, the images are in incorrect places on the screen.
what is the best way to adjust the images (in scale and position) for any screen resolution instead of use "drawpic" . Thanks for your request.

[Max_Salivan]

I had the same problem with pictures in menu:)

Besides changing vid_height and vid_width i have changed vid_conheight and vid_conwidth and it helped

[Spike]

what is the best way to adjust the images (in scale and position) for any screen resolution

not hard-coding the position.

vector hudtopleft = [(vidsize_x - 320)/2, vidsize_y-24, 0];
drawpic(hudtopleft+'xpos ypos 0', ...);

note: doesn't rescale the image, just moves it in line with a centered hud region that is 320 wide, 24 high.
rescaling is nasty when it comes to aspect ratios - if you code your hud to use some 4:3 virtual resolution then things get really nasty when you then display it at a 16:9 physical resolution.
to rescale properly, you'll need to use the concept of origins (ie: hudtopleft being the origin of the main hud region), and to come up with some way to scale that properly (either with a wrapper for drawpic+friends, or by scaling all the origins+sizes in each call).

DP's vid_conwidth and vid_conheight cvars are nasty. they define the 2d virtual size, but their values are often saved into configs and set to 640*480 or whatever instead of the actual screen resolution, which messes up screen aspect. I guess you'll just have to make sure that the user sets them properly. :s

[Nahuel]

thank you guys, i do not understand why do you use "-320" and "-24", but works great

[r00k]

is the negative 320 to center for 640?

[Spike]

the width-320 is halved then added. this is the amount of space at the side, which is chopped in two (for each side) then added to the left coord to center on the x axis.
width-320 is correct for a centered sbar region which is 320 (virtual) pixels wide.
-24 is the main sbar, and does not include the ibar. note that quake's sbar uses the same logic, with the ibar elements using a negative y offset above the sbar.
if the virtual screen size is smaller than 320,24, then your sbar will poke off the sides/top. the maths still works even if you get negatives appearing, but you're likely to want to clamp to at least 0, so the right goes offscreen instead of the left, or something, at least if you care to allow for virtual resolutions smaller than 320... its more of an issue if the sbar is made for a larger base size.

[Dr. Shadowborg]

Meant to put this up for you to look at yesterday but forgot:
viewtopic.php?f=16&t=5372

GFX scaling is handled, but only when going above 640x480.