Imposed Screen Sizing Standards

[mkruer]

This is something that I have wanted to do. I have notices in the past, thankfully not as much now that GUI came in multiple sizes; some were 800x600 or 1024x768 or 1280x1024 etc… It looks like we have standardized on the 1024x768 interface, and I would like to keep it this way, regardless of what the in-flight resolution might be, the GUI will be set at 1024x768. This means (as far as privateer 1.x is concerned) that all the current animated UI for the bases need to be increased.

Anyway enough with that. What really interests me is the future standard. What I am about to propose may sound like overkill. I think that with the advent of WXGA (wide screen for 20+ inches and up) that any development along the line of widescreen should have a standardized resolution of 1920x1200 this is four time the resolution of the current 1024x768 standard. The main reason why I would like the Wide Screen aspect to be so high is because the current 1920x1200 resolution is the highest standard resolution out there. Depending on how dense they can make the LCD or soon to be OLED this resolution has the best chance of becoming the next 1024x768 standard for wide screen units 17â€

[crouton]

I am totally for high-res images *if* they can be easily and cleanly downsized for lower-res monitors.

If we're going to be updating all the base backgrounds, animations, etc.. might as well do it right as large as possible, and downsize it accordingly. That will make this game more futureproof.

[chuck_starchaser]

Problem is, most videocards won't accept textures with non-power-of-two sizes through the OpenGL pipe. And some of the older ones require that the textures be square. I was just suggesting to spirit that we resize all existing screens to 512 x 512. 1024 x 1024 would indeed be overkill, I think, considering we'd be blur-stretching 360 x 200 originals.

And eventually we'd want to have 3D bases --"no screens"-- so producing original art at higher detail would probably be wasted work, me thinks.

[mkruer]

There is a way to fix the problem with all textures running through the card having to be base 2, and it only requires a small tweak to the core. In a nutshell when a texture is loaded (of non standard size) it does not go directly into video memory, instead it is processed to determine if it a fits the base 2 sizing schema for the video card. If it does, it is sent directly into memory, if it does not it is held and another image is loaded. All the images go through the exact same process of check and verification.

In the end you will end up with a bunch of images that are non base 2. What happens next is that images, for lack of a better word, all the images are concatenated into image(s) that are base 2, and then sent to the video card.

As of right now, all “modernâ€

[crouton]

Chuck: blur-stretching should be avoided at all costs, yes? Currently it's 320x200, and on a 1600x1200 display that looks horrendous. Why not go for super-hi-res images and add functionality to handle lower resolutions?

[mkruer]

Chuck: blur-stretching should be avoided at all costs, yes? Currently it's 320x200, and on a 1600x1200 display that looks horrendous. Why not go for super-hi-res images and add functionality to handle lower resolutions?

the Keyword is "stretching" if the image is over size, then scaling it to fit into a smaller screen size is ok.

[The Phantasm]

mkruer, the idea of simply slapping a group of non-powers of 2 images onto a single texture and using that will cause a series of issues of its
own. First, if that texture is passed through a bilinear filter, depending
on where exactly the vertex falls, it is likely that the nearby colors of
other images will affect the final color.

There are other solutions, such as breaking an image down to power
of 2 sized textures and effectively inserting vertices into an existing
mesh in order to deal with the fact that a texture has been split up.

The real solution is new images that are powers of 2. Most other solutions will carry some baggage over that will cause a lot of headache in some form or another. This engine is still a slave to the video card design in some ways, and video cards demand power of 2 sized textures (there are very very good reasons for this). You can either hack up your engine to support what is a bad texture, or you can fix your textures.

Also, if you are worried about the texture scaling issue, emulator writers have developed several up-scaling techniques (2xSAI and hq2x for example). Since I am under the impression that the graphics are being borrowed from existing software that was built to run as 320x200, I would suggest looking into the hq2x, hq3x, hq4x scaling algorithms.

http://www.hiend3d.com/hq2x.html

You can use the algorithm to "fix" your textures on startup, and then just choose the scaling algorithm most appropriate to the size of the screen.

[mkruer]

Where to begin….
On the bilinear filtering, how so? Game models do it all the time and there is never any color bleed that I could ever find. The only difference is that in how this would work, is in layman’s terms, instead of mapping a texture on 3d object you would be mapping it on a 2d plane with a fixed dimension. Also if you look at game models they use many areas of a texture however

Second one on subdivision. My very first idea was to do this, however after long drawn out discussion, it turned out or my precisely I was convinced that doing it this was would be more difficult and strenuous on the card. The main reason being that instead of the video card managing a few larger texture that the engine would pull off smaller pieces depending of the texture based on the coordinates that model had been mapped, you would be taking a lot of little pieces, and trying to assign it to a large piece. Interestingly enough if you go back to your bilinear argument, you end up with the edges of each on of those “small piecesâ€

[The Phantasm]

> On the bilinear filtering, how so?

glTexParameterf( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER,GL_LINEAR );


And there is a distinct tradeoff between texture sizes and the number of vertices. If you're running with a 1024x1024 texture, that's going to take a lot of the cards bandwidth.. that's a huge texture.

But the engine itself probably uses mipmaps anyway (if it supports LOD's on the meshes, then it almost certainly supports mipmaps).

> If you do the bilinear process you are quadrupling the memory requirement regardless of weather it is used or not, if you do it after it is pull on the texture.

Read up on mipmaps, then you can tell me.

> Finally thanks for the link, I am sure that that will come in handy if someone is willing to implement it.

The source code to hq[2|3|4]x are all available on that site.

[mkruer]

Regardless of how we do this, the simple fact remains, that this is something that NEEDs to be done, "must make image fit" (via stretching) is not an option. Incase you failed to read this was strictly for the UI, it has nothing to do with the models which to my knowledge already fit the Power 2 guideline, even if it is applicably. I just tried of having people destroy a perfectly good 640x480 image so it can fit within a 512x512 box. This is just stupid.