Change order of resolutions list

[raster]

Hi all:

I've been playing with UfoAI for a long time, and found a very frustrating detail in the configuration: the screen resolutions aren't ordered. In a big screen that isn't a problem, because all the resolutions are shown, but when you have a tiny screen like an EEEPC, the resolution you want is outside the screen, so you have to set a big resolution first in order to be able to select the resolution you want.

So I modified the file src/client/cl_video.c and changed the resolutions, ordering them first by vertical resolution, and then by horizontal resolution.

I attach a diff file with the changes; they are very simple.

[Duke]

Interesting.
I just set up my new EeePC with UFO:AI two days ago. It compiled fine, but didn't really run (got the sound, but a blank window).

Are you talking about 2.2.1 or 2.3 ??

[raster]

2.3 version, the SVN one.

But I replaced the original OS in my EEEPC with an off-the-shelf Ubuntu 9.04 (I have the EEEPC 1000H)

[Duke]

I have the 1000H too. Cute

As of R26050+ it looked better. I got sound and graphics and managed to set resolution to 800x600, then back and exit. But at the next start, it came up with 1024x768 again. Any ideas ?

[geever]

config.cfg? Is it writeable? Did you close the program correctly or it died?

-geever

[bayo]

I remember if you close the game with the [ x ] button of the Windows manager (top-right) you lose your changes. Not sure about that.

[Duke]

config.cfg? Is it writeable?

Good hint, geever. That was probably part of the problem. But the final breakthrough was to use that little icon 'maintain resolution'. Then it changes and saves the new resolution.
May I suggest that we rename it to 'apply resolution' ?

@bayo:
raster's above fix also changes the magic numbers (1-22) in the resolution table. If they are *only* used as a return value from the drop-down-list, I think it's ok to change them. Do you know if they are also used for other purposes (eg. stored in config.cfg) ?

[bayo]

OPTION_VIDEO_RESOLUTIONS (drop-down list content) is generated from the list of resolution description. Then, IDs will be right (GUI<->client), only the stored ID can became wrong (old vid_mode from the config.cfg (hmmm strange file name)).

Maybe there is an hidden dependency, the third value (the mode) from vid_modes but be the index of the mode into vid_modes. Then you can't sort resolutions without broking mode IDs.

Anyway, sorting rules should/can be a GUI point of vue. I mean you can sort OPTION_VIDEO_RESOLUTIONS options (CL_InitAfter(), vidModesOptions, cl_main.c) without sorting vid_modes, and add new modes at the end of the vid_modes list.

[Mattn]

if someone is going to replace the vid_mode cvar and the magic numbers - go for it. we really only need vid_width and vid_height in our settings. maybe the magic numbers are still quite useful in the code, i'm not sure.

[raster]

Hi all:

About the magic numbers, they seem needed to recover the resolution after exiting the game: first I just reordered the resolution without changing the magic number, and it seemed to work; but when I exited and launched it again, the resolution it used was wrong. I was selecting 1680x1050, with magic number 18, and when I relaunched UFOAI, the resolution selected was 1400x1050, which was the one in the position 18 in the reordered list. I, then, changed the magic values, and all worked fine.

So it seems that UFOAI stores that value in the configuration in order to retrieve the resolution the next time the game is launched.

Another detail about ordering: it's not possible to just use a generic string sorting function, because the resolution must be sorted first by vertical resolution, not by horizontal resolution. This is needed to ensure that, in small screens, the user will always be able to see the desired vertical resolutions.

[Duke]

Good findings, raster
I've looked it up in the code and can confirm that that 'magic number' vid_mode
- is stored in the config
- is used as an *index* into the array of videomodes.

That is, your original patch would leave all users that have an existing config and a new exe with the wrong resolution ==> no go.

I see two options:

1. *completely* get rid of vid_mode as Mattn suggested
This looks quite complicated and we would certainly need the help of a dev that is more familiar with the video code than I am.

2. make the code use vid_mode as a lookup-value instead of an index.
That looks fairly easy to me. We just need some accessor-functions and change very few places.

Raster, do you think you could provide such a patch ?

[raster]

The lookup-value idea sounds very good. I'll try. I hope to have it in two days (I'm quite busy these days).

[raster]

Well, here is the patch. It modifies both cl_main.c and cl_video.c, sorting the resolutions first by vertical, then by horizontal resolution, and keeping the old selection values to maintain compatibility with old configurations.

To add new resolutions, just add them in the right position and set the index value to the inmediately next free (23 in this case).

[geever]

Well, here is the patch. It modifies both cl_main.c and cl_video.c, sorting the resolutions first by vertical, then by horizontal resolution, and keeping the old selection values to maintain compatibility with old configurations.

To add new resolutions, just add them in the right position and set the index value to the inmediately next free (23 in this case).

Why vertical first?

-geever

[Duke]

@geever:...because the lower the vertical resolution of your screen is, the less you'll see of the drop down list if it is displayed at a higher vertical res than yours

@raster:
The patch looks good. Will take a closer look and commit tomorrow.