SUBSIM Radio Room Forums - View Single Post

karamazovnew · 03-04-10, 07:17 AM

This is where it hurts. Sorry guys but I'll need you to read something first. Just browse through them, I'll do my best to explain it all again (picture heavy

)

Back in 2007 just as SH4 came out, Zamboni wrote this tutorial. You won't believe it, but it still works: http://www.subsim.com/radioroom/showthread.php?t=111832

It took 2 and a half years for someone (me!) to figure out how to scale things to resolution: http://www.subsim.com/radioroom/show...28&postcount=7

If you're one of the old guards there is nothing New I can tell you and it will only take you a few minutes to figure out the interface of the editor (it took me 1 minute to be exact). Everything is the SAME. And that's a very good thing. You see, even making hundreds of items in NOTEPAD made sense in SH. The workflow was slow but once you understood HOW, it was just a matter of time and patience.

Introduction

Back in SH3, we were stuck with just one resolution, 1024x768. This made modding quite easy as each item's position was presented as an offset to it's parent, in pixels. But positioning and aligning items accurately was a pain. For example:

[G01 I1]
Name=Page shell
Type=1027;Menu page
ItemID=0x1000000
ParentID=0x0
Pos=0,0,0,0

[G01 I3]
Name=SShell
Type=1030;Static bmp
ItemID=0x1000004
ParentID=0x1000000
Pos=146,685,28,33

The 0x0 item was the Root. The main screen. It was 1024 pixels wide and 768 pixels high so it filled the screen. It couldn't be moved, it couldn't be accessed. It "started" from the Top Left corner of the screen.
The 0x1000000 item there is the first menu page. It's a child of the 0x0 item (ParentID=0x0). It's 0 pixels wide by 0 pixels high(Pos=0,0,0,0). But where is it placed? Each item's position is actually given by the position of its TOP LEFT corner. Any child of that item will then be positioned RELATIVE to the item's (the parent) corner, by an offset in pixels. This propagates into the hierarchy so in effect you could never know the actual position on the screen. You had to go step by step, from parent to child, making offsets at each step. In our case, the Page has an offset of 0 pixels on horizontal and 0 pixels on vertical (Pos=0,0,0,0). In other words, it's exactly at 0 0 coordinates (top left of the screen).

The bitmap object 0x1000004 is a child of the page (ParentID=0x1000000). It has a width of 28, a height if 33 and it's top left corner is offset to the parent's top left corner by 146 pixels to the right and 685 pixels up (Pos=146,685,28,33).

In other words, the Pos line is:
Pos=X, Y, WIDTH, LENGTH where X and Y are given relative to the first immediate parent.

Do you think that was complicated? Take a quick glance at the SH4 positioning line:

Zone= 545 396 80 24 0 1 0x28190001 1 -0.5 0x28190003 0 0.5 3 0

Don't worry, it will all make sense. We'll see how the Menu Editor actually generates this monster and why it's important to take the time and understand it. The Menu Editor is a great tool but you must first THINK ahead a lot, and here's why.

When SH4 came out, it featured multiple resolutions and, of course, multiple aspect ratios (1024x768 and 1600x1200 are 4:3 resolutions while 1920x1200 is a 16:10 resolution, or widescreen as it's called). So how did they make the interface fill up the entire screen at any resolution/aspect ratio? Multiple interfaces for each resolution? Magic? Secret tools? The son of Einstein? Nope. They actually programmed the entire interface as a 1024x768 screen and stretched it "behind the scenes"!!! And guess what... you'll need to do the same in SH5.

Because the Menu Editor only shows you a 1024x768 screen. And if you're about to create the imba interface for all to wonder, you need to understand how scaling works in order to plan ahead. Otherwise, you won't know what hit you.

Screen Resolution versus Editor resolution, relative versus absolute

For all my following examples I will only use 2 resolutions as reference: 1024x768 (normal 4:3 aspect) and 1920x1200 (16:10 aspect).

1024x768 is the most important resolution because it's the the resolution at which you will preview your results. If your interface or objects are positioned and scaled correctly in the Editor, they will look just as great in the game. But somehow you need to to do SOMETHING to make it look right on all resolutions and somehow maintain it's relative position or size on the screen. So you need to think ahead about how you want your items too look on any screen. Here's what you need to keep in mind:

ABSOLUTE SIZE: if you want your item to always be X pixels wide and Y pixels high, the item will "shrink" as you increase the screen resolution:

ABSOLUTE POSITION: if you want your item to always be at X pixels left and Y pixels down from the top left corner of your screen, the position will shift as you increase resolution.

RELATIVE SIZE:

Already a lot of people have complained about the recognition manual being too small. It's not small on 1024x768, but it gets smaller and smaller as the resolution increases. This applies to 90% of the game's interface. It's good for some items, but bad for most. What we want is for an item to maintain its relative size to the screen. If the resolution doubles, we want the item to double in size. But here's what happens when you switch aspect ratios:

Why? Because when increasing resolution from 1024x768 to 1920x1200, the screen width has increased by a factor of StretchX=1.6 (as in 1920/1024) while the screen height has increased by a factor of StretchY=1.5625 (as in 1200/768). Thus our item has increased its size by 1.6 horizontally and 1.5625 vertically. This creates the stretching. So what if we don't want it to stretch?

In that case you need to CHOOSE how your items should resize. The game offers a lot of flexibility here:
- "none": don't increase size at all. Result: the items get smaller and smaller.
- "no constraint": increase width by StretchX and height by StretchY. Result: the items get bigger but hey become stretched or squashed on ANY non 4:3 aspect ratio.
- "horizontallyOnly": will only increase the horizontal size by StretchY. Result: the items will get VEEERY wide while at the same time become smaller in height. Very good for things like long bars.
- "verticallyOnly" : will only increase the vertical size by StretchX. Result: same as before but vertically
- "constantAspectRatioHorizontal": will increase both horizontal and vertical size by StretchX. Result: the items become bigger without becoming stretched. This is the best mode for backgrounds as they will fill up the screen. However, it will clip their top and bottom margins.
- "constantAspectRatioVertical": will increase both horizontal and vertical size by StretchY. Result: the items become bigger without becoming stretched. This is not good for backgrounds as it will leave empty bands left and right.
- "constantAspectRatioMin" and "constantAspectRatioMax": this might sound redundant, as all monitors have a Width>Heigth but there might be people out there who like to rotate their monitors. This allows for weird resolutions like 1200x1600 and 1200x1920.

With the risk of "just saying too much", I'd like to point out that because 1024*768 is a 4:3 resolution, all the constantAspectRatio resizing methods will appear to be the SAME if you own a 4:3 monitor. If you do, and you want to create an inteface it's important to remember this because you must be careful when you rescale items, simply because you won't be able to test it on wide res resolutions. It might look good to you, but a person with a different aspect ratio might see errors if you're not careful. As a rule of thumb, you only ever need to test your creations on 2 resolutions: 1024*768, and the maximum wide resolution that your computer can allow. If it looks good on those, it will look good on any monitor.

Does this apply only to images? No. I only used the picture of the greatest hero of all times to illustrate "stretching" when resizing. It actually applies to all items regardless of weather they have images or they're invisible: menu pages, groups, everything. We're not stretching images, we're altering (resizing) dimensions. For example, say you want a menu group that must fill up the entire screen on any resolution. What do you do?

1. you "fill up" the screen at 1024x768, meaning that you create an item that is 1024x768 in size and you place its top left corner at the top left corner of the screen.
2. you assign to it a resize method of "no constraint". This way it will always fill up the screen.

Why would you want to resize invisible objects? Here's why:

RELATIVE POSITION:

Take a look back at the image with Absolute Position. You place the item in the dead center of the screen and you want it to stay there at any resolution. If you say "well, my resolution is 1024x768 so I'll start from the top left of the screen and shift the item right by 512 pixels and down by 384" sure, it will look fine at 1024*768, BUT it will no longer be in the center at 1920x1200, because the center of such a screen is at 860 per 600 (as in the image). What you need to do is think like this:

"Ok, I have a parent (the screen in this example). It has WIDTH and HEIGHT and they vary with resolution. So if I want to make a new child item that stays at the center of the parent(screen), I must express the position of the child as relative to the WIDTH and HEIGHT of the parent". In other words, to make a button that is "glued" to the right side of the screen, you will start from the top left corner of the parent, just as in SH3, and then offset the horizontal position by the full WIDTH of the parent. If you want your item to remain in the center of the screen, you start from the top corner of the screen and then shift your item RIGHT by 0.5 * WIDTH and then shift it DOWN by 0.5 * HEIGHT.

Relative positioning works like this:
1. you start from the position of the parent
2. you offset by an amount relative to the parent's dimensions
3. you then offset by an amount relative to the item's dimensions
4. you then offset by a particular number of pixels
I'll show examples why each step is useful.

So this is what the game does when it stretches items. Even though your pages and items can only have a maximum size of 1024*768 in the editor, when you load the game, the engine will increase the widths and heights of all items "behind the scene" if told to do so through the resizing method. This in turn affects the positions of ALL of the children.

I really hope this makes sense now because I can't explain it better than this.

SH4&SH5 Zone Line

Based on what you've seen so far, it's now time to list the actual variables that make up the position of the TOP LEFT corner of any item (not the center):

ID - the item's ID
AnchorID - the "positioning" parent: for relative positioning you can select any item in the same group (including the group itself, which is the real parent) or, for absolute positioning, no item at all.

X - Absolute Horizontal position on the screen: 0 means LEFT screen edge.. 1024 means RIGHT screen edge
Y - Absolute Vertical position on the screen: 0 means BOTTOM screen edge... 768 means TOP screen edge
In Relative Mode, they both automatically update based on the other values. They don't actually control the position, they're just for show.
In Absolute Mode however, only they control the position.

Resize - the resize method for the item
DX - Width of the item, in pixels
DY - Height of the item, in pixels

1. We start from the anchor's top left corner and shift based on the anchor's dimensions.
ARX - Achor Ratio X: ARX * (Achor's width) = the number of pixels by which the item is moved left or right from the anchor's X.
ARY - Achor Ratio Y: ARY * (Achor's height) = the number of pixels by which the item is moved up or down from the anchor's Y.

2. Then we shift again but this time based on the item's dimensions.
DRX - Item Ratio X: DRX * DX = the number of pixels by which the item is moved left or right from the previous step.
DRY - Item Ratio Y: DRY * DY = the number of pixels by which the item is moved up or down from the previous step.

3. Then, if needed we then shift by a specific offset (usually best left alone because of scaling issues)
Off X - Offset X: horizontal offset in pixels
Off Y - Offset Y: horizontal offset in pixels
No idea if these also get affected by Resizing and resolution scaling or are simply added/substracted as they're entered.

Let's look again at the dreaded zone line:
Zone= 545 396 80 24 0 1 0x28190001 1 -0.5 0x28190003 0 0.5 3 0
Zone= X Y DX DY Resize ? AnchorID ARX ARY ItemID DRX DRY OffX OffY

That "?" item is always 1, when using the Editor and can't be changed. I have a theory on what it does but even after creating 300 items in the same screen I've never found a use for it.

Enough theory, let's do some examples.

03-04-10, 07:17 AM	#3
karamazovnew The Old Man Join Date: Mar 2009 Location: Bucharest, Romania Posts: 1,403 Downloads: 151 Uploads: 0	This is where it hurts. Sorry guys but I'll need you to read something first. Just browse through them, I'll do my best to explain it all again (picture heavy ) Back in 2007 just as SH4 came out, Zamboni wrote this tutorial. You won't believe it, but it still works: http://www.subsim.com/radioroom/showthread.php?t=111832 It took 2 and a half years for someone (me!) to figure out how to scale things to resolution: http://www.subsim.com/radioroom/show...28&postcount=7 If you're one of the old guards there is nothing New I can tell you and it will only take you a few minutes to figure out the interface of the editor (it took me 1 minute to be exact). Everything is the SAME. And that's a very good thing. You see, even making hundreds of items in NOTEPAD made sense in SH. The workflow was slow but once you understood HOW, it was just a matter of time and patience. Introduction Back in SH3, we were stuck with just one resolution, 1024x768. This made modding quite easy as each item's position was presented as an offset to it's parent, in pixels. But positioning and aligning items accurately was a pain. For example: [G01 I1] Name=Page shell Type=1027;Menu page ItemID=0x1000000 ParentID=0x0 Pos=0,0,0,0 [G01 I3] Name=SShell Type=1030;Static bmp ItemID=0x1000004 ParentID=0x1000000 Pos=146,685,28,33 The 0x0 item was the Root. The main screen. It was 1024 pixels wide and 768 pixels high so it filled the screen. It couldn't be moved, it couldn't be accessed. It "started" from the Top Left corner of the screen. The 0x1000000 item there is the first menu page. It's a child of the 0x0 item (ParentID=0x0). It's 0 pixels wide by 0 pixels high(Pos=0,0,0,0). But where is it placed? Each item's position is actually given by the position of its TOP LEFT corner. Any child of that item will then be positioned RELATIVE to the item's (the parent) corner, by an offset in pixels. This propagates into the hierarchy so in effect you could never know the actual position on the screen. You had to go step by step, from parent to child, making offsets at each step. In our case, the Page has an offset of 0 pixels on horizontal and 0 pixels on vertical (Pos=0,0,0,0). In other words, it's exactly at 0 0 coordinates (top left of the screen). The bitmap object 0x1000004 is a child of the page (ParentID=0x1000000). It has a width of 28, a height if 33 and it's top left corner is offset to the parent's top left corner by 146 pixels to the right and 685 pixels up (Pos=146,685,28,33). In other words, the Pos line is: Pos=X, Y, WIDTH, LENGTH where X and Y are given relative to the first immediate parent. Do you think that was complicated? Take a quick glance at the SH4 positioning line: Zone= 545 396 80 24 0 1 0x28190001 1 -0.5 0x28190003 0 0.5 3 0 Don't worry, it will all make sense. We'll see how the Menu Editor actually generates this monster and why it's important to take the time and understand it. The Menu Editor is a great tool but you must first THINK ahead a lot, and here's why. When SH4 came out, it featured multiple resolutions and, of course, multiple aspect ratios (1024x768 and 1600x1200 are 4:3 resolutions while 1920x1200 is a 16:10 resolution, or widescreen as it's called). So how did they make the interface fill up the entire screen at any resolution/aspect ratio? Multiple interfaces for each resolution? Magic? Secret tools? The son of Einstein? Nope. They actually programmed the entire interface as a 1024x768 screen and stretched it "behind the scenes"!!! And guess what... you'll need to do the same in SH5. Because the Menu Editor only shows you a 1024x768 screen. And if you're about to create the imba interface for all to wonder, you need to understand how scaling works in order to plan ahead. Otherwise, you won't know what hit you. Screen Resolution versus Editor resolution, relative versus absolute For all my following examples I will only use 2 resolutions as reference: 1024x768 (normal 4:3 aspect) and 1920x1200 (16:10 aspect). 1024x768 is the most important resolution because it's the the resolution at which you will preview your results. If your interface or objects are positioned and scaled correctly in the Editor, they will look just as great in the game. But somehow you need to to do SOMETHING to make it look right on all resolutions and somehow maintain it's relative position or size on the screen. So you need to think ahead about how you want your items too look on any screen. Here's what you need to keep in mind: ABSOLUTE SIZE: if you want your item to always be X pixels wide and Y pixels high, the item will "shrink" as you increase the screen resolution: ABSOLUTE POSITION: if you want your item to always be at X pixels left and Y pixels down from the top left corner of your screen, the position will shift as you increase resolution. RELATIVE SIZE: Already a lot of people have complained about the recognition manual being too small. It's not small on 1024x768, but it gets smaller and smaller as the resolution increases. This applies to 90% of the game's interface. It's good for some items, but bad for most. What we want is for an item to maintain its relative size to the screen. If the resolution doubles, we want the item to double in size. But here's what happens when you switch aspect ratios: Why? Because when increasing resolution from 1024x768 to 1920x1200, the screen width has increased by a factor of StretchX=1.6 (as in 1920/1024) while the screen height has increased by a factor of StretchY=1.5625 (as in 1200/768). Thus our item has increased its size by 1.6 horizontally and 1.5625 vertically. This creates the stretching. So what if we don't want it to stretch? In that case you need to CHOOSE how your items should resize. The game offers a lot of flexibility here: - "none": don't increase size at all. Result: the items get smaller and smaller. - "no constraint": increase width by StretchX and height by StretchY. Result: the items get bigger but hey become stretched or squashed on ANY non 4:3 aspect ratio. - "horizontallyOnly": will only increase the horizontal size by StretchY. Result: the items will get VEEERY wide while at the same time become smaller in height. Very good for things like long bars. - "verticallyOnly" : will only increase the vertical size by StretchX. Result: same as before but vertically - "constantAspectRatioHorizontal": will increase both horizontal and vertical size by StretchX. Result: the items become bigger without becoming stretched. This is the best mode for backgrounds as they will fill up the screen. However, it will clip their top and bottom margins. - "constantAspectRatioVertical": will increase both horizontal and vertical size by StretchY. Result: the items become bigger without becoming stretched. This is not good for backgrounds as it will leave empty bands left and right. - "constantAspectRatioMin" and "constantAspectRatioMax": this might sound redundant, as all monitors have a Width>Heigth but there might be people out there who like to rotate their monitors. This allows for weird resolutions like 1200x1600 and 1200x1920. With the risk of "just saying too much", I'd like to point out that because 1024768 is a 4:3 resolution, all the constantAspectRatio resizing methods will appear to be the SAME if you own a 4:3 monitor. If you do, and you want to create an inteface it's important to remember this because you must be careful when you rescale items, simply because you won't be able to test it on wide res resolutions. It might look good to you, but a person with a different aspect ratio might see errors if you're not careful. As a rule of thumb, you only ever need to test your creations on 2 resolutions: 1024768, and the maximum wide resolution that your computer can allow. If it looks good on those, it will look good on any monitor. Does this apply only to images? No. I only used the picture of the greatest hero of all times to illustrate "stretching" when resizing. It actually applies to all items regardless of weather they have images or they're invisible: menu pages, groups, everything. We're not stretching images, we're altering (resizing) dimensions. For example, say you want a menu group that must fill up the entire screen on any resolution. What do you do? 1. you "fill up" the screen at 1024x768, meaning that you create an item that is 1024x768 in size and you place its top left corner at the top left corner of the screen. 2. you assign to it a resize method of "no constraint". This way it will always fill up the screen. Why would you want to resize invisible objects? Here's why: RELATIVE POSITION: Take a look back at the image with Absolute Position. You place the item in the dead center of the screen and you want it to stay there at any resolution. If you say "well, my resolution is 1024x768 so I'll start from the top left of the screen and shift the item right by 512 pixels and down by 384" sure, it will look fine at 1024768, BUT it will no longer be in the center at 1920x1200, because the center of such a screen is at 860 per 600 (as in the image). What you need to do is think like this: "Ok, I have a parent (the screen in this example). It has WIDTH and HEIGHT and they vary with resolution. So if I want to make a new child item that stays at the center of the parent(screen), I must express the position of the child as relative to the WIDTH and HEIGHT of the parent". In other words, to make a button that is "glued" to the right side of the screen, you will start from the top left corner of the parent, just as in SH3, and then offset the horizontal position by the full WIDTH of the parent. If you want your item to remain in the center of the screen, you start from the top corner of the screen and then shift your item RIGHT by 0.5 WIDTH and then shift it DOWN by 0.5 * HEIGHT. Relative positioning works like this: 1. you start from the position of the parent 2. you offset by an amount relative to the parent's dimensions 3. you then offset by an amount relative to the item's dimensions 4. you then offset by a particular number of pixels I'll show examples why each step is useful. So this is what the game does when it stretches items. Even though your pages and items can only have a maximum size of 1024768 in the editor, when you load the game, the engine will increase the widths and heights of all items "behind the scene" if told to do so through the resizing method. This in turn affects the positions of ALL of the children. I really hope this makes sense now because I can't explain it better than this. SH4&SH5 Zone Line* Based on what you've seen so far, it's now time to list the actual variables that make up the position of the *TOP LEFT* corner of any item (not the center): ID - the item's ID AnchorID - the "positioning" parent: for relative positioning you can select any item in the same group (including the group itself, which is the real parent) or, for absolute positioning, no item at all. X - Absolute Horizontal position on the screen: 0 means LEFT screen edge.. 1024 means RIGHT screen edge Y - Absolute Vertical position on the screen: 0 means BOTTOM screen edge... 768 means TOP screen edge In Relative Mode, they both automatically update based on the other values. They don't actually control the position, they're just for show. In Absolute Mode however, only they control the position. Resize - the resize method for the item DX - Width of the item, in pixels DY - Height of the item, in pixels 1. We start from the anchor's top left corner and shift based on the anchor's dimensions. ARX - Achor Ratio X: ARX * (Achor's width) = the number of pixels by which the item is moved left or right from the anchor's X. ARY - Achor Ratio Y: ARY * (Achor's height) = the number of pixels by which the item is moved up or down from the anchor's Y. 2. Then we shift again but this time based on the item's dimensions. DRX - Item Ratio X: DRX * DX = the number of pixels by which the item is moved left or right from the previous step. DRY - Item Ratio Y: DRY * DY = the number of pixels by which the item is moved up or down from the previous step. 3. Then, if needed we then shift by a specific offset (usually best left alone because of scaling issues) Off X - Offset X: horizontal offset in pixels Off Y - Offset Y: horizontal offset in pixels No idea if these also get affected by Resizing and resolution scaling or are simply added/substracted as they're entered. Let's look again at the dreaded zone line: Zone= 545 396 80 24 0 1 0x28190001 1 -0.5 0x28190003 0 0.5 3 0 Zone= X Y DX DY Resize ? AnchorID ARX ARY ItemID DRX DRY OffX OffY That "?" item is always 1, when using the Editor and can't be changed. I have a theory on what it does but even after creating 300 items in the same screen I've never found a use for it. Enough theory, let's do some examples. Last edited by karamazovnew; 03-05-10 at 01:54 PM.