0001671: [PATCH] Minimap wrong aspect ratio in dual screen mode

(0004335)
hoijui (administrator)
2009-11-16 13:05

it looks to me, as if it is not meant to keep aspect ratio if maxspect is false.
so your fix seems to remove a feature, instead of fixing something.
looking at the code, i see that maxspect can be set to true when pressing left Shift key, and then clicking on maximize, or with /maxspect ...
i am not even shure about these, and maybe there are more ways.
please try some, and report back.

(0004349)
Tronic (reporter)
2009-11-17 03:19

What are you talking about? There is no maximize button (on the minimap, I suppose?) and command /maxspect doesn't seem to exist. The minimap source code is so badly written that I really cannot say what is intended there.

(0004350)
hoijui (administrator)
2009-11-17 10:42

i agree it is not nice, but there is worse in spring, and it is especially clear right in the parts you edited, that there are two ways of maximizing the minimap (eg, see the bool maxspect var).
There is a button to mximize the minimap on the default GUI. guess you are using lolUI (default in BA).
look at the coe again, and try to find out how youd best issue the aspect keeping maximization.

(0004351)
Tronic (reporter)
2009-11-17 13:54

In dual screen mode there are no buttons for resizing the minimap. I am using IceUI, which also takes care of AR and resizing by itself and doesn't allow minimap resizing (but it only does this in single screen mode).

Anyway, it is important to get correct AR in dual screen mode and this should be fixed one way or the other.

(0004352)
hoijui (administrator)
2009-11-17 14:46

then maybe talk to MelTrax, which is the author of IceUI

(0004353)
Tronic (reporter)
2009-11-17 14:49

This is not a IceUI problem. Even with IceUI disabled it behaves the same way (in dual screen mode).

(0005258)
Jonas Wielicki (reporter)
2010-08-14 15:15

Here is another fix attempt (with which it works-for-meÔäó):
http://github.com/horazont/spring/commit/632181bdca91aa3376b38ed052159c23562c1618 [^]

(0005262)
jK (developer)
2010-08-14 17:02

removing the glScalef() can't be good

(0005263)
Jonas Wielicki (reporter)
2010-08-14 17:05

With glScalef I get either a distorted map or only the bottom left pixel of the map streched over the whole map area. I thought that too, but it's actually neccessary.

(0005265)
jK (developer)
2010-08-14 17:09

No, that just means that you don't know what you need to enter. This doesn't make it necessary ...

(0005266)
jK (developer)
2010-08-14 17:24

from what I see your first part is okay, just instead of removing the glScalef you need to add a glTranslatef.

(0005268)
Jonas Wielicki (reporter)
2010-08-14 18:32
edited on: 2010-08-14 18:33

No, I can prove it that the glScalef is uneccessary:
before it was
glScalef(width * globalRendering->pixelX, height * globalRendering->pixelY, 1.0f);

where globalRendering->pixelX is initialized with 1.0f/globalRendering->viewSizeX.

thus, the map gets scaled to the viewports size. Now it must be 1.0f/width, as the map won't fill the complete viewport anymore. But width * 1.0f/width is actually 1.0f, which makes the glScalef completely unnecessary (glScalef(1.0, 1.0, 1.0) does exactly nothing.)

However, there is a bug remaining which has to do with issuing commands on the minimap. I will try to investigate that.

greetings
ps: I was some kind of distracted when commenting on your comment at first, that's why I did not think about adding the prove.
pps: Not sure about the glTranslatef, but I'll look into it, thanks for the suggestion.

(0005269)
jK (developer)
2010-08-14 18:39

you math brain, what is with the height when width_normalized = 1.0f and aspect_ratio != 1.0f?

(0005270)
Jonas Wielicki (reporter)
2010-08-14 18:46

I'm not sure I get what you mean. Can you explain please?

(0005272)
Jonas Wielicki (reporter)
2010-08-14 18:58

Okay, I agree that there needs to be a glScalef. But I disagree on the location. I am not sure anymore about anything related to that glScalef, because the code is a lot more complex than seen on the first glance *sigh*.

However, at that point, any scaling instead of 1.0|1.0|1.0 *will* influence the rendering of the minimaps background (terrain I want to say) in a way which is not desired.

Now there is still the problem that lines of commands etc. are drawn with an incorrect scale, while minimap icons of units are correct. So somewhere inbetween there needs to be some scaling and I'd really like it if you could at first forgive my tone in the previous comments (that happens when I'm too self-confident, which also happens way too often :-/). Then it would be also nice if you could give me a hint where to add that and in which way. My guess is around line 1131, as unit icons and minimap itself are rendered before that and command paths etc. after.

greetings

(0005274)
Jonas Wielicki (reporter)
2010-08-14 19:22

Hmm ... I played around with various attempts, but I think that the remaining problems with issuing commands on the minimap and the lines drawn on it are in the lua-scripts. I think so because different mods (namely BA and CA) result in different mis-behaviour. While I can issue commands on the minimap in BA, I cannot in CA.

(0005275)
jK (developer)
2010-08-14 20:30

Yeah, a lot successive code isn't designed for that.
The idea is nice and your starting point to, still it would need some further changes, and it is too unpredictable to be added in a subbuild - it may be worth to reconsider for 83/84, but then the question is why not to totally drop this dirty way of DualScreenMode and giving the minimap its own OpenGL window.

(0005276)
Jonas Wielicki (reporter)
2010-08-14 20:46

Which advantages would a separate window have?
I guess its a lot of effort, at least with SDL, to get another window and render to that. And I'm not sure whether its at all possible to have two fullscreen windows in current window managers, both windows and linux.

I agree that adding it to a sub version of 0.82 would be too heavy, as it will need the modders to adapt to that change, at least from what I've learnt about the process of minimap rendering and click handling.

(0005278)
jK (developer)
2010-08-14 21:47

advantages are: independent resolution, independent update rate, independent GPU (if you have multiple GPUs), much easier to add stuff as this idea, ...

Still the amount of problems is the same length, so it's a very heavy change, still why break code for little when you can do it right.

(0005974)
phantasm (reporter)
2010-11-25 13:11

This problem is still around in newest stable release 0.82.6.1. The mentioned separate window would also allow fixing http://springrts.com/mantis/view.php?id=2235 [^]

Notes
(0004335) hoijui (administrator) 2009-11-16 13:05	it looks to me, as if it is not meant to keep aspect ratio if maxspect is false. so your fix seems to remove a feature, instead of fixing something. looking at the code, i see that maxspect can be set to true when pressing left Shift key, and then clicking on maximize, or with /maxspect ... i am not even shure about these, and maybe there are more ways. please try some, and report back.

(0004349) Tronic (reporter) 2009-11-17 03:19	What are you talking about? There is no maximize button (on the minimap, I suppose?) and command /maxspect doesn't seem to exist. The minimap source code is so badly written that I really cannot say what is intended there.

(0004350) hoijui (administrator) 2009-11-17 10:42	i agree it is not nice, but there is worse in spring, and it is especially clear right in the parts you edited, that there are two ways of maximizing the minimap (eg, see the bool maxspect var). There is a button to mximize the minimap on the default GUI. guess you are using lolUI (default in BA). look at the coe again, and try to find out how youd best issue the aspect keeping maximization.

(0004351) Tronic (reporter) 2009-11-17 13:54	In dual screen mode there are no buttons for resizing the minimap. I am using IceUI, which also takes care of AR and resizing by itself and doesn't allow minimap resizing (but it only does this in single screen mode). Anyway, it is important to get correct AR in dual screen mode and this should be fixed one way or the other.

(0004352) hoijui (administrator) 2009-11-17 14:46	then maybe talk to MelTrax, which is the author of IceUI

(0004353) Tronic (reporter) 2009-11-17 14:49	This is not a IceUI problem. Even with IceUI disabled it behaves the same way (in dual screen mode).

(0005258) Jonas Wielicki (reporter) 2010-08-14 15:15	Here is another fix attempt (with which it works-for-meÔäó): http://github.com/horazont/spring/commit/632181bdca91aa3376b38ed052159c23562c1618 [^]

(0005262) jK (developer) 2010-08-14 17:02	removing the glScalef() can't be good

(0005263) Jonas Wielicki (reporter) 2010-08-14 17:05	With glScalef I get either a distorted map or only the bottom left pixel of the map streched over the whole map area. I thought that too, but it's actually neccessary.

(0005265) jK (developer) 2010-08-14 17:09	No, that just means that you don't know what you need to enter. This doesn't make it necessary ...

(0005266) jK (developer) 2010-08-14 17:24	from what I see your first part is okay, just instead of removing the glScalef you need to add a glTranslatef.

(0005268) Jonas Wielicki (reporter) 2010-08-14 18:32 edited on: 2010-08-14 18:33	No, I can prove it that the glScalef is uneccessary: before it was glScalef(width * globalRendering->pixelX, height * globalRendering->pixelY, 1.0f); where globalRendering->pixelX is initialized with 1.0f/globalRendering->viewSizeX. thus, the map gets scaled to the viewports size. Now it must be 1.0f/width, as the map won't fill the complete viewport anymore. But width * 1.0f/width is actually 1.0f, which makes the glScalef completely unnecessary (glScalef(1.0, 1.0, 1.0) does exactly nothing.) However, there is a bug remaining which has to do with issuing commands on the minimap. I will try to investigate that. greetings ps: I was some kind of distracted when commenting on your comment at first, that's why I did not think about adding the prove. pps: Not sure about the glTranslatef, but I'll look into it, thanks for the suggestion.

(0005269) jK (developer) 2010-08-14 18:39	you math brain, what is with the height when width_normalized = 1.0f and aspect_ratio != 1.0f?

(0005270) Jonas Wielicki (reporter) 2010-08-14 18:46	I'm not sure I get what you mean. Can you explain please?

(0005272) Jonas Wielicki (reporter) 2010-08-14 18:58	Okay, I agree that there needs to be a glScalef. But I disagree on the location. I am not sure anymore about anything related to that glScalef, because the code is a lot more complex than seen on the first glance sigh. However, at that point, any scaling instead of 1.0\|1.0\|1.0 will influence the rendering of the minimaps background (terrain I want to say) in a way which is not desired. Now there is still the problem that lines of commands etc. are drawn with an incorrect scale, while minimap icons of units are correct. So somewhere inbetween there needs to be some scaling and I'd really like it if you could at first forgive my tone in the previous comments (that happens when I'm too self-confident, which also happens way too often :-/). Then it would be also nice if you could give me a hint where to add that and in which way. My guess is around line 1131, as unit icons and minimap itself are rendered before that and command paths etc. after. greetings

(0005274) Jonas Wielicki (reporter) 2010-08-14 19:22	Hmm ... I played around with various attempts, but I think that the remaining problems with issuing commands on the minimap and the lines drawn on it are in the lua-scripts. I think so because different mods (namely BA and CA) result in different mis-behaviour. While I can issue commands on the minimap in BA, I cannot in CA.

(0005275) jK (developer) 2010-08-14 20:30	Yeah, a lot successive code isn't designed for that. The idea is nice and your starting point to, still it would need some further changes, and it is too unpredictable to be added in a subbuild - it may be worth to reconsider for 83/84, but then the question is why not to totally drop this dirty way of DualScreenMode and giving the minimap its own OpenGL window.

(0005276) Jonas Wielicki (reporter) 2010-08-14 20:46	Which advantages would a separate window have? I guess its a lot of effort, at least with SDL, to get another window and render to that. And I'm not sure whether its at all possible to have two fullscreen windows in current window managers, both windows and linux. I agree that adding it to a sub version of 0.82 would be too heavy, as it will need the modders to adapt to that change, at least from what I've learnt about the process of minimap rendering and click handling.

(0005278) jK (developer) 2010-08-14 21:47	advantages are: independent resolution, independent update rate, independent GPU (if you have multiple GPUs), much easier to add stuff as this idea, ... Still the amount of problems is the same length, so it's a very heavy change, still why break code for little when you can do it right.

(0005974) phantasm (reporter) 2010-11-25 13:11	This problem is still around in newest stable release 0.82.6.1. The mentioned separate window would also allow fixing http://springrts.com/mantis/view.php?id=2235 [^]

Issue History
Date Modified	Username	Field	Change
2009-10-06 10:08	Tronic	New Issue
2009-10-06 10:08	Tronic	File Added: dualscreen-minimap-aspect.patch
2009-10-07 20:41	hoijui	Summary	Minimap wrong aspect ratio in dual screen mode => [PATCH] Minimap wrong aspect ratio in dual screen mode
2009-10-07 20:43	hoijui	Projection	none => minor fix
2009-10-07 20:43	hoijui	Target Version	=> 0.81.0.0
2009-11-16 13:05	hoijui	Note Added: 0004335
2009-11-16 13:05	hoijui	Status	new => feedback
2009-11-17 03:19	Tronic	Note Added: 0004349
2009-11-17 10:42	hoijui	Note Added: 0004350
2009-11-17 13:54	Tronic	Note Added: 0004351
2009-11-17 14:46	hoijui	Note Added: 0004352
2009-11-17 14:49	Tronic	Note Added: 0004353
2010-08-14 15:15	Jonas Wielicki	Note Added: 0005258
2010-08-14 17:02	jK	Note Added: 0005262
2010-08-14 17:05	Jonas Wielicki	Note Added: 0005263
2010-08-14 17:09	jK	Note Added: 0005265
2010-08-14 17:24	jK	Note Added: 0005266
2010-08-14 18:32	Jonas Wielicki	Note Added: 0005268
2010-08-14 18:33	Jonas Wielicki	Note Edited: 0005268
2010-08-14 18:39	jK	Note Added: 0005269
2010-08-14 18:46	Jonas Wielicki	Note Added: 0005270
2010-08-14 18:58	Jonas Wielicki	Note Added: 0005272
2010-08-14 19:22	Jonas Wielicki	Note Added: 0005274
2010-08-14 20:30	jK	Note Added: 0005275
2010-08-14 20:46	Jonas Wielicki	Note Added: 0005276
2010-08-14 21:47	jK	Note Added: 0005278
2010-11-25 13:11	phantasm	Note Added: 0005974
2010-11-27 17:21	hoijui	Relationship added	has duplicate 0002235
2012-01-24 23:35	jK	Status	feedback => closed
2012-01-24 23:35	jK	Resolution	open => suspended