Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: WMCoolmon on May 30, 2004, 03:22:10 am
-
How should they be specified?
Absolute values:
Goober:
Here's my idea: Add full support for all the gauges by specifying exact coordinates, but *only* for 640x480. The game will automatically adjust the coordinates for the other resolutions.
This way people can have the exactitute of specifying absolute pixel coordinates, but the gauges will still be scaled for alternate resolutions. I think doing it by percentages would eventually get far too confusing.
As a bonus, all the values would be integers, so you wouldn't get floating-point slowdown.
Percentages are the percentage of the screen to the left or top of the item, ie 50%, 50% would specify the middle pixel of the screen.
From 0 to 1, basically percentages except with decimals...
-
isn't 0 to 1 the same thing as Percentages?
anyway I like 0 to 1 becase it's like UV coordanants, and also the easiest to code for (for all the many new resolution modes, IMHO)
-
Yeah, it is.
-
hmmm you edited your post :)
now I look like an idiot :D
-
I'm voting pixels. It might mean some minor messing when it came time to resize for different resolutions, but it does give you a more accurate representation of your motion. ie - .0001 might not move you at all in real terms. Also, it's easier to specify the sizes of your guages in pixels as that's the way Aniview and your paint program spits them out...And we will be able to change sizes right?
-
Yeah, which is in pixels.
-
Awesome :yes:. And the relevance was that it'd probably be less confusing at the user end to use a single set of numbers for both size and location, ie. pixels.
-
The problem with doing it in 640*480 seems to me that not every resolution is a direct multiplacation from that number. Because if you need to multiply it by 1.5, you're still be using floats. 0 to 1 makes more sense if you ask me, though if you go from 0-4 for horizontal, and 0-3 vertical it might make more sense, because then every 1,1 block is square.
-
wait why is size in pixels?
it should all be the same system so the HUD looks the same in all resolutions.
I'm thinking I'm getting an idea about how you'r trying to implement this and I think maybe there should be two types of positioning systems one were you indicate the upper left hand courner and the lower right, and another were you indicate the center and it's size. internaly it can be easily converted to what ever the hud is useing.
-
Percentages.
Pixels will look odd because screen resolutions don't multiply directly and so it can lead to odd misaligned gauges and stuff.
0-->1 will get a pain with the values you have to insert (0.12639202973 = blah).
Percentages work basically the same way, but you'll have a more useful scale (0->100) so you can make things more precise without having to use zounds of decimals.
-
Originally posted by Lightspeed
0-->1 will get a pain with the values you have to insert (0.12639202973 = blah).
Is that any different from 12.639202973? :p
-
Yes, because its very possible you set something at say, 50.283% which looks okay, number wise.
On the other hand, 0.50283 is gettin insane (and hell of easy to typo).
The human mind just works better with 'normal' numbers than long stings of decimals. That's the whole deal why we came up with logarithms and all :)
-
Check the thread on this in the recent builds forum, I posted something that might work for all of this.
-
oooooooh.,...I hate this....now I gotta go and try and find the thread your are talking about,'is it really too much of an effort to either repeat it here or post a link? that way it still makes sense next week...
oh btw...0.25308 or 25.308 is the same to me...and for the enduser/modder, only pixels are of importance, since that can be visually mapped out and checked...percentages or any other system requiring to work in decimals is a pain in the but to position correctly...and no matter which non-pixel coordinate system you are going to use, something will always end up 1 pixel too far in any direction when you don't want it coz of rounding...
-
http://www.hard-light.net/forums/index.php/topic,23874.0.html
-
you talk of exactatude of pixel coordanants, but the thing is it will only be exact for the resolution you specify, you wil lack controle on the higher resolutions, and the lower ones will be off by ever larger degrees (based on how much higher the resolution you are working in.
-
If you need precision relative to other HUD gauges, the gauge will have to be a mini-gauge. In that case you can specify the location with relative pixel coords.
-
mini-gauges are gauges that are parts of other gauges right?
the floating point representation could be relitive to the size of the parent gauge.
or you know I just thought of something, why not have at the top of the table a $X_scale_division_factor: and a $Y_scale_division_factor:, it divides any numbers parsed by that, you can put 1024 and 768 in respectively and anything you put in will be the pixel space for the 1024X768 display mode, internaly the code handels it as a floating point, divides the table value by the division factors to get the 0 to 1 value then multiplies it by the current screen resolution to get the actual pixel position, you can store the floating (0 to 1) representation for maybe a later in game resolution switch.
if you were to put in 1 and 1 for both division factors then the values entered would be the 0 to 1 system, if you put in 100 for both it would be percentages.
-
Originally posted by Bobboau
you talk of exactatude of pixel coordanants, but the thing is it will only be exact for the resolution you specify, you wil lack controle on the higher resolutions, and the lower ones will be off by ever larger degrees (based on how much higher the resolution you are working in.
exactitude :D so why bother with the decimals? just pick 800x600 as reference res to work from, let the game deal with the decimals and the modder with the exact pixels...rounding errors will occur anyway no matter which system you choose...
-
I DO NOT want the hud to look the same in all resolutions
I absolutely despise the 640x480 HUD, however the 1024x768 hud is good
Pixels, relative position
ie X=1 is one pixel from left and X=-1 is one pixel from right edge
Y=1 one from top, Y=-1 one from bottom
-
Then ask for two different sets Kazan - for many people with small monitors the 1024x768 HUD is an eye killer and vice-versa for people with big monitors.
A Hud that's optimised for a 17'' screen would look good even in 640x480 and 4000 x 2000 with the system Bob suggests.
-
yeah, diferent hud configurations can be made for people who like the big buttons of the 640 or the effecency of the 1024, I hate it when changeing resolution changes the way things look, so no problems as far as I can see.
-
Warning: once this has been implemented I will have to add the hud.tbl to the mod verification list
-
It has been implemented, and what verification list? If this is for fs2_openpxo, this shouldn't be a problem since SEXPs are required to make custom HUDs do anything.
Bobb, your idea was workable and easy to add. The next time I make a big change the $Default: will work like you said.
-
why would the HUD need to be verified, I can't think of anything that you could do to it that would give you any sort of advantage, all it controles is how some game variables are displayed to you.
-
Originally posted by Kazan
Warning: once this has been implemented I will have to add the hud.tbl to the mod verification list
Why? I can't imagine having a different HUD will cause any unfairness :)
Or is this cause of the ships.tbl to hud.tbl connection.
-
bobboau: theorectically it can cause balalnce problems
-
I don't see how :wtf:
explain
-
with our code changes it may become possible to have information displayed that is not displayed on another persons hud
-
I can see that. I just can't see how it would do you any good. Unless you were playing a mod that removed basic flight info (like missile warnings , speed etc)
-
My vote: percentages.
-
Originally posted by karajorma
Or is this cause of the ships.tbl to hud.tbl connection.
Side note: hud.tbl is no longer necessary or even read from by fs2_open. Unless you want backwards compatibility.
-
it would be an advantage if you were playing a mod that removed something, yeah,
do you think it would be doable to have HUD.tbl checking an optional thing for a mod? becase I like the idea of people makeing and useing customised HUDs.
-
bobboau: ANY table checking is optional for a mod - for each table to be checked for a mod i enter another row in the table with Columns mod=[modname], filename=[tablename] and crc32=[32bitcrc]
-
ah! alright then, exelent!