The Resolution

[mamutas]

i just check the latest version of design document. neither it nor any other docs has mention of what screen resolution we are going to support.

 

So, here are some questions and my answers:

1) will we allow to change the resolution during the game? No

2) what are resolution settings we will support? 1024x768

3) will we have different resolution between differen scapes (geoscape, battlescape, basescape)? No

 

Provide your input.

[Guest drewid]

If we support different res then that means scaling the interface, and designing it to work on our lowest res.

 

Can of worms there. If we can avoid scaling it'll mean the quality is better.

 

1024 x 786 is a good res on both my 15"monitor at home and my 21" at work. a good size to work to I think.

 

Will it work on our min spec? hmmmm I think so.

[red knight]

Drew it is a can or worms if you expect to do the complete GUI from the ground up in a rescalable way... The idea is to mockup the interface in a fixed resolution like 800x600 (dont forget the GF2 guys, they cannot support the geoscape in higher resolution) and after the game is almost on the release time, you go and do some simple scallings using the width and height (i had done that before) to support multiresolution...

 

Greetings

Red Knight

[mamutas]

But when you will do scaling, doesn't it mean that you would need to provide several version of textures (in some cases at least)? Also, the the font height need to be recalculated as well, right? There could be some other issues as well.

[red knight]

Fonts are calculated on relative sizes... 15 pts is 15 pts in every resolution... (i did it that way, really didnt check it, but it should work that way).

 

You would end up using the better texture (higher detail), that is the safer and easier approach. By the way who would use bigger than 1240x1024???

 

Greetings

Red Knight

[mamutas]

because people has very big monitors?

[Guest drewid]

I'll go for that.

 

BTW

 

The buttons textures haven't been power of two up till now would it be better if they were?

 

Also storing the full side panel as a single graphic isn't very efficent. Do we want to keep it like that?

 

Quite happy to do that if that's ok.

[red knight]

mhhh bigger enough to use more than 1240x1024 and see the diference?... Well what do you say drew in your experience the texture problem with bigger monitors it is noticeable???

 

Do it, if you can make it more efficient go for it... just give us the layout of how it is used... after the process.... I should consider start mocking up the other screens of the milestone 1 instead of doing more work on this, we have enough time to make it work better later...

 

By the way, the texture now are all 128x192 they are accepted without problem by OpenGL (even though they are not exactly power of 2)....

 

Greetings

Red Knight

[mamutas]

no one has answered my questions at the top of the thread

[[[Micah]]]

By the way who would use bigger than 1240x1024???

 

Greetings

Red Knight

On my nifty new 21" monitor, I use 1600x1200

[red knight]

Mamutas: I though i had responded the ones that had to be addresed from you original auto-responses.

 

Micah: Ok you win, we will see what we can do for 1600x1240 guys like you.... That is up to the art dept (how to get the textures work in all resolutions, without killing a GF2 :: )...

 

Greetings

Red Knight

[[[Micah]]]

Mamutas: I though i had responded the ones that had to be addresed from you original auto-responses.

 

Micah: Ok you win, we will see what we can do for 1600x1240 guys like you.... That is up to the art dept (how to get the textures work in all resolutions, without killing a GF2 :: )...

 

Greetings

Red Knight

I was just showing off I think either 800x600 or 1024x768 would be fine.

[Guest drewid]

Having read through this thread again I'll try to address the issues as I see them...

 

Fonts. we are using truetype fonts so that's not a problem they are built to scale nicely.

 

Texture sizes. Will DX also handle non power of two textures?

 

Scaling by stretching everything. Depends on the particular texture. For instance our alternate green lines texture, You'll really see it if every few lines is double the width. If its solid green but transparent then you won't. box edges could be very noticeable, but not the marble texture in the middle of the box.

 

There are three approaches to this.

 

1) Scale everything and hope no one notices. Put up with doubled lines and losing the crisp edges.

advantages - easy to do.

disadvantages - could look bad.

 

2) Don't scale anything, but do slightly different layouts for each resolution supported. This would probably mean limiting ourselves to a handful of the more common resolutions.

Advantages - display looks neat and tidy

Disadvantages

- Different layouts is more work for graphics and coders.

- text might be less readable at bigger res.

 

3) Using XML (or some homebrew text format similar) we could build the box edges so they don't scale, or only scale in one direction. So a horizontal line could stretch horizontally but not vertically, the corners don't stretch at all, the marbled centre stretches both ways. The green lines wouldn't stretch, but could repeat tile to keep them neat.

Once a single button is set up then that can be copied around the screen.

 

Advantages

- we only have to do the layout once because it will scale nicely.

- we only need to support a subset of the language, we wouldn't need all of it.

- artists could build layouts without having to stop coders doing more important stuff.

 

Disadvantages - setting up boxes and buttons harder than drawing them but not much really.

- More work for coding having to support or translate a subset of html or xml.

 

Take your pick.

[Deimos]

Option 4, Stick to 800x600.

This would mean that everyone knows exactly how much screen real estate there is and can design things to fit in more aesthetically.

 

Pro's - Less work for the coding and graphics teams. No need to do extra work on different resolutions. Everybody knows what the target is.

 

Cons - Some end users might bitch that they can't use the higher resolutions of their cards. We're not pushing the hardware.

[LordT]

How about designing everything for 800x600 and have the RightBar^tm anchored to the right. All other windows should be moveble.

[mamutas]

I like Deimos suggestion. That would be fastest and easiest way to get out release out of the door.

However, 800x600 seems pretty small for me. Would it be a big trouble to go with 1024x768?

 

To Senior Team members

This is important decision, which should be resolved ASAP. Somebody, please have a voting on that with some near deadline.

Then the decision should be written in stone (that is Design Document) and we will stick to it until further notice.

[[mindstormmaster]]

I want 1600x1200 too! Ok, 1024x768 will work just fine for v1, but higher resolutions are always welcome. (Micah, you're not the only one.)

[Breunor]

Since the original hardware specs will only support 800x600, I suggest this be the default resolution. An optional resolution could be designed around, either 1024x768 or 1280x1024. I don't suggest scaling anything, rather just reposition things to keep the relative positions. You'd see more in the battle view and base view, there'd be more "space" around the planet in the planet view. But the menus don't change size, neither do the fonts or the models/textures. Would that work? The only changes I see would be making sure the main screens lined up panels and menu items correctly. I suggest using 1280x1024 as the second resolution, 1024x768 isn't enough of a change to merit the extra work IMO.

[mamutas]

That sounds good to me. I would rather not having any scaling due to resolution change, cause it will look ugly. Well, drewid has explained that as well.

 

As Breunor has mentioned, we would not do any scaling, but just changing the position. Yes, the buttons and texts would look smaller than. If that would be too ugly, then we can have different textures for different resolutions.

 

The programming implementation of Breunor's last suggestion would be keeping a set of coordinates for each control for each supported resolution. Then depending on resolution the right set will be picked. I suggest even start to code in this fashion right now, that is not to hardcode the values, but make them 'pseudo-loaded' from external resources. For now, 'pseudo-loading' will just initialize values for 800x600 resolution. Later we can switch to real loading which would differentiate between resolutions and load values from external resources.

[Deimos]

Just to giveyou guys an idea of what 1024x768 and 1280x1024 would look like I'm positng a rough draft of what they'd look like. First one is 1024.

 

Sorry to modem users.

[Deimos]

This one is 1280. I think if we did go for adding this resolution in we should re-do the artwork for it as it scale horribly and as you can see the panel looks way too small for it to be considered in this res.

 

I've killed the image here cause I don't like scrolling across to read

Edited May 30, 2003 by Deimos

[LordT]

How about just increasing the standard zoom and centering the planet?

A small menu wouldn't that much then

Edited May 29, 2003 by LordT

[red knight]

I think that our artists can make a good set of textures that can work in multiple resolutions... or maybe two sets of textures.... Just my opinion...

 

Greetings

Red Knight

[Guest drewid]

As long as we have a small number of fixed resolutions then we can redraw buttons and stuff pretty quickly.

 

I like the idea of reading positions in from a text file or something. the artists can tweak positions and spacing and stuff withou taking up coder time bouncing stuff back and forth. It'll also make building new interfaces quicker and easier.

[Sweep]

Don't forget the LCD screen users.

 

I've got a 17'' LCD screen with a 1280x1024 native resolution.

1024x768 doesn't look very good on it

[Deimos]

I think to get the best looking interface (and for me it will be a gnawing annoyange if it doesn't look gorgeous) we should nail down set resolutions 800x600 (that's already set) 1024x768 (which seems to be the most popular) and 1280x1024 for the high res nutters out there. I'd prefer to have a button set for each of them and put in the extra work to make the UI look as good as we can, than scale between them and have it looking not as good.

 

I don't think it would be that much extra work as the only real differences would be the UI panel, all the rest of the elements could stay designed for 8x6 and not look too out of place in the larger resolutions. What do you guys think?

[red knight]

Fixed resolution should be only to interface testing purposes, then the position and size should be calculated on the fly (to avoid have multiple versions for any resolution, maybe have a low res and high res texture pack, but no more than that)...

 

Greetings

Red Knight

[Guest drewid]

I think given the nature of our buttons and panel edges it wouldn't be that much work to have multiple versions.

[mamutas]

I suggest we provide set a config file for each panel which would have coordinates, sizes and texture file names for each panel element. There would be a set of mentioned data for each supported resolution. Thus we would be able to add another resolutions later without recompiling the code.

 

I do not like the idea of calculating the size on the fly. For that you would need either to specify coordinates in percentage or implement some layout manager. Everyone who programmed UI in Java must have delt with that and it ain't pretty and easy. It is very easy to get unpredictable results if you are not paying attention.

[Guest drewid]

So I would suggest we build a standard res interface of 800x600.

Taking the information from a config /script file, so that we can add further res at a later date.

 

I would suggest that the file is arranged with screen elements having a x,y,z co-ordinate, so we can order depth from this file as well. Effectively a simple scene graph. IIRC it's going to be rendered with an orthogonal camera so no perspective.

 

I would also suggest keeping the elements in depth order for sanitys sake.

 

I would also recommend rendering with bilinear filtering off. with anti aliasing built into the texture to keep it as neat and clean as possible.

[mamutas]

Ok, then.

For code it does not matter what resolution it is going to be since it just read the file and draw what it says to it. The key is to implement the reading and data manipulation. But this is not big a problem.

 

So, here is an example:

 

panel.options.backgroundTexture=a.png

panel.options.x=20

panel.options.y=20

panel.options.z=0

panel.options.width=100

panel.options.height=200

panel.options.depth=0

 

button.options.load.parent=panel.options ?? not sure about this one yet

button.options.load.pressedTexture=b.png

button.options.load.x=20

button.options.load.y=20

button.options.load.z=0

button.options.load.width=50

button.options.load.height=20

button.options.load.depth=0

 

EDIT: Umm, I forgot to specify the resolution. Now I think that some XML format will be better as it gives a hierarchy of the elements. Gotta think about different format now...

Edited June 2, 2003 by mamutas

[LordT]

How about adding properties to center windows? And/or props to have the x originate from left or right?

[red knight]

Mamutas look if the config file format works for it cause it is already implemented and working on the Misc utilities...

 

Greetings

Red Knight

Edited June 3, 2003 by red knight