UFO:Alien Invasion
Development => Newbie Coding => Topic started by: raster on August 29, 2009, 12:31:48 pm
-
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.
-
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 ??
-
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)
-
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 ?
-
config.cfg? Is it writeable? Did you close the program correctly or it died?
-geever
-
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.
-
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) ?
-
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.
-
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.
-
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.
-
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 ?
-
The lookup-value idea sounds very good. I'll try. I hope to have it in two days (I'm quite busy these days).
-
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).
-
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
-
@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.
-
Resolutions are anyway per systems, i mean many modes from the list are never used. SDL already provide supported video modes. IMO we should 1) remove the mode id, 2) remove the video mode list, and use the SDL function.
Then, i dont think it is nice to apply this patch, because it will be harder to remove the mode id. Please sort the drop-down list content instead. Sorting the drop-down list will be usefull when we will use SDL video modes too.
-
Fine with me.
When will you have changed the program to use that SDL function ?
-
@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 ;)
That doesn't make it a good solution. Sorting by vertical first is a bullsh*t IMHO. The dropdown should have scroll function.
-geever
-
And AFAIk we don`t try to have backard compactibility, do we?
-
When will you have changed the program to use that SDL function ?
Maybe soon, because it is not very hard.
The dropdown should have scroll function.
Patch are welcome :-)
we don`t try to have backard compactibility, do we?
Thats right, but if we update again and again this list, we should.
-
That doesn't make it a good solution. Sorting by vertical first is a bullsh*t IMHO. The dropdown should have scroll function.
Admittably, the patch is a Q&D hack. But if offers *immediate* relief.
I like the scrollable DDL approach very much. Especially after finding that we already have such a control (language selection). Wouldn't that need even less coding effort than the patch ?
@bayo:
I personally run UFO in 1024x768 on a 1920x1080 monitor. Would that SDL function offer a 4:3 res on a widescreen monitor ?
@Kildor:
Allthough it's not UFO policy to be backward compatible *everywhere*, imho we should still try to be compatible wherever we can (with a few more thoughts and/or lines of code).
Users *love* backward compatibility.
-
Would that SDL function offer a 4:3 res on a widescreen monitor ?
There is no documentation about it, but it say the value come from the hardware.
-
I went ahead and compared 'optionlist select_language' and 'selectbox select_res' in options.ufo. It seems that with a few adjustments of size, pos and color etc. we could make select_res an optionlist.
(I even managed to display the resolutions in the language dropdown by merely changing the dataid param LOL)
Is it really that easy ? What did I overlook ?
@bayo:
The biggest difference I noticed is that in the game menu the space for the dropdown is left blank. In the video menu there is not enough space left. Would it impose a problem if the dropdown of the new optionlist would overlap the checkboxes below it ?
-
optionlist and selectbox are fully compatible. Then you can use the node you want.
But i am sorry, i dont think i understand your second comment. optionlist dont have drop down zone.
-
But i am sorry, i dont think i understand your second comment. optionlist dont have drop down zone.
Ouch, you're right. I must have had some sort of blackout :(
Does the menu system also support a scrollable dropdown list ? I haven't see one in the game.
EDIT:
From one of your previous answers I guess we do NOT have such a control yet.
So what can we do to gain some space ?
- Ordering the checkboxes in two columns could be a bad idea for certain languages, I suppose.
- Create a submenu (like 'keys menu') and move the 'fine-tuning-params' there ?
- Create the missing control ? How much work would it be for you ? Is it feasable ?
-
No it dont support scrollable dropdown list.
Are you talking about languages or resolutions? Because i dont think we have problem with languages. I mean we dont need to gain space here, we only use space we can use.
About 2 columns, maybe the option window is too small for it.
About another window, why not, but maybe we can create a tab and sort the content between "basic", "advanced", or finding another logical structure. But i dont think current "key" navigation is the better way.
About a scrollable selectbox, maybe it is not very hard. But i dont want to merge the scrollbar code into the selectbox code. I think we can do it without a merge, and maybe the current system own every thing it need for it. But it need work, and i dont think this feature is really need. i can be wrong.
-
Are you talking about languages or resolutions?
Resolutions.
... maybe we can create a tab and sort the content between "basic", "advanced", or finding another logical structure.
I like that idea :) It might even add to usability for normal users.
... and i dont think this feature is really need. i can be wrong.
Imagine you were a first time user and try to run UFO on an EeePC or similar. That would change your mind ;)
Ok, there are workarounds, but a necessary control outside the bounds of the monitor is simply 'not nice' in any given program.
But I had another idea: I understood you suggested to use that SDL function to fill the dropdown with only the vid_modes available on the machine. What if we use that SDL function to figure out a suitable default resolution, especially when 1024x768 is *not* available on that machine ? Imho that would also solve our little prob without changing the menus, right ?
-
Ho, ok, i undertsand. The fullscrren is cropped, or something like that?
And, yes, i think the SDL function will provide a very little set of resolutions.
Here a patch to *only* display on the log the supported resolutions. How many element do you have? Do you found everything it need?
-
Ho, ok, i undertsand. The fullscrren is cropped, or something like that?
Exactly.
I applied the patch to my i7:
------- video initialization -------
SDL version: 1.2.13
I: desktop depth: 32bpp
I: video memory: 0
I: video driver: windib
I: setting mode 6:Available modes:
* 1920x1080
* 1776x1000
* 1680x1050
* 1600x1200
* 1440x900
* 1280x1024
* 1280x960
* 1280x800
* 1280x768
* 1280x720
* 1152x864
* 1024x768
* 800x600
* 720x480
* 640x480
I: set swap control to 0
1024x768 (fullscreen: no)
At least a reduction to 15. And obviously, it also offers the 4:3 resolutions :)
I'll now apply the patch on my EeePC and come up with the log...
-
Ok, here's what the EeePC says:
------- video initialization -------
SDL version: 1.2.13
I: desktop depth: 32bpp
I: video memory: 0
I: video driver: windib
I: setting mode 22:Available modes:
* 1024x768
* 1024x600
* 800x600
* 768x1024
* 640x480
* 640x400
* 600x1024
* 600x800
* 512x384
* 480x640
* 400x640
* 400x300
* 384x512
* 320x240
* 320x200
I: set swap control to 0
1024x600 (fullscreen: no)
- at least the most interesting resolutions are on top of the list
- I'm a bit confused about 1024x768 being among the available resolutions
- I'm even more confused about those 'reversed' resolutions
@Raster:
You are maybe more familiar with the EeePC than me. Does it have some sort of pivot-function ??
-
Note: we also should add a ratio filter to the resolution selector. Maybe i will start to work on that first.
What 600x1024 mean? The hardware will auto rotate the screen?
-
Note: we also should add a ratio filter to the resolution selector. Maybe i will start to work on that first.
No, please. As I said some posts above, on my i7, I run UFO in a 4:3 ratio on the widescreen monitor in *windowed mode*.
What 600x1024 mean? The hardware will auto rotate the screen?
Sounds like that, but doesn't make sense for the EeePC. I tilted the EeePC by 90 degrees, but nothing changed. Maybe the chipset supports auto rotation, but it's disabled for the EeePC ?
I think it's safe to filter out those reversed resolutions. UFO wouldn't look nice on a vertical widescreen ;)
-
No, please. As I said some posts above, on my i7, I run UFO in a 4:3 ratio on the widescreen monitor in *windowed mode*.
I dont explain very well what i mean. I commit the filter into the trunk. It is a widget filter. You can check it into the option UI. It is anyway something need for any other screens, because the list is very big, and it is hard to found what we need (cropped screen, or not).
You can found the EEE PC resolution into "Others" (with the VIAO resolution). I dont found the ratio name for your screen (1024x600) it is something between 16:10 and 16:9... else we can call it 128:75 or 17:10 :D
-
Ahhh, great :)
I guess that also solves the original prob.
One little detail I noticed:
If I filter for 'All ratios' or '4:3', the resolution selector is preset with 1024x768. When filtering for any other ratio, the selector is not preset ie. blank.
Is that intentional or a glitch ?
-
the selector is not preset ie. blank.
Yes, thats right. I will fix that.