OpenXcom Forum
Contributions => Programming => Topic started by: Juju Dredd on August 29, 2013, 11:34:14 pm
-
Hi!
This being in the todo list of SupSuper and being usefull to me, I wanted to try and do it by myself.
I think I have found an easy way to do this, but the way I try to do it has a side effect. In fact I change the final stretch of the picture, which prevent the mouse cursor to appear in the black bands.
As the cursor is draw before this final stretch, it is impossible to prevent this.
I really don't know if this is a good thing. On the one side, this could be rather strange, particularly if the black bands are very large. On the other side, it makes sense not to draw the mouse cursor in those black bands.
Should I keep it this way?
Should I modify how the mouse cursor coordinates are calculated? (This way the cursor won't appear in the black bands but it will simply be invisible within them rather than "jumping" when the cursor go out the window).
Should I modify the picture before being draw by enlarging it and apply an offset to every draw in it? (painful I believe).
Should I modify how the mouse cursor coordinates are calculated, but only if fullscreen is not set?
-
Since nobody gave me his wise advice, I am trying to change the way cursor position is calculated.
The development for OpenGL mode is close to be done.
I need some help.
Is there any way to test without OpenGL other than recompiling with __NO_OPENGL being set?
I have found no option regarding to that, is it normal?
-
I didnt realy understand waht you were working on, images work great for me :)
-
I didnt realy understand waht you were working on, images work great for me :)
Is is very simple: play with a resolution other other than 16/10, such as 16/9 or even worse 4/3 or 5/4.
The image will be stretched in a manner she covers all the resolution you asked. It will be deformed. Some people like, some people hates. Of course people who hates are right, it is highly ugly to deform a picture giving the impression Xcom agents are some fantasy elves or dwarves...
So, I'm currently developing an option to ensure black bands will be added, either at the top and the bottom or at the left and the right, to keep images aspect ratio. Do you understand the utility of this feature?
-
now, i understand, sounds like a nice feature.
-
do you think it would be possible - at least for the battlescape - that the "extra space" is used for the battlescape itself, while the GUI stays as it is? it would be nice to have a widescreen battlescape (not stretched, but extended, of course), as long as the GUI stays in the bottom center and isn't deformed.
is it possible at all to "detach" the GUI bar from the actual battlefield in this way?
-
do you think it would be possible - at least for the battlescape - that the "extra space" is used for the battlescape itself, while the GUI stays as it is? it would be nice to have a widescreen battlescape (not stretched, but extended, of course), as long as the GUI stays in the bottom center and isn't deformed.
is it possible at all to "detach" the GUI bar from the actual battlefield in this way?
That would be nice as i have been thinking of having a second GUI at the TOP for square controls plus some other features
-
now, i understand, sounds like a nice feature.
I think the title of this topic is inadequate, I am fixing it.
do you think it would be possible - at least for the battlescape - that the "extra space" is used for the battlescape itself, while the GUI stays as it is? it would be nice to have a widescreen battlescape (not stretched, but extended, of course), as long as the GUI stays in the bottom center and isn't deformed.
is it possible at all to "detach" the GUI bar from the actual battlefield in this way?
I don't know, the space we have is not very big. You probably think of playing on a 16/9 screen, right? Extended 320x200 to this format means 356x200, you gain only 18 pixels on each side. Of course, you could add it at a better resolution but if you do that the cursor has to be drawn differently in this UI, seems pretty odd.
-
If you play on 16:9 screen (for example 1600x900), you can set the option baseXResolution: 356 (because 200/900*1600 = 355,555). As result - screen without distortions.
options.cfg:
baseXResolution: 356
baseYResolution: 200
displayHeight: 900
displayWidth: 1600
fullscreen: true
-
If you play on 16:9 screen (for example 1600x900), you can set the option baseXResolution: 356 (because 200/900*1600 = 355,555). As result - screen without distortions.
options.cfg:
baseXResolution: 356
baseYResolution: 200
displayHeight: 900
displayWidth: 1600
fullscreen: true
That seems a good alternative, even though the game just don't look the same. Not forgetting what have been written in ufopedia:
WARNING: Changing this setting will cause serious UI and performance problems, as the game is not designed for flexible resolutions.
-
If you use correct upscaling (1x 2x 4x) you will not see difference. base resolution is irrelevant (of course if you not set 1600x900 as base resolution :D ).
[ps]
this quote on wiki is mostly obsolete because most problems with UI was fixed.
-
this quote on wiki is mostly obsolete because most problems with UI was fixed.
So it should be corrected.
Anyway, as a purist, I prefer to keep the game the same, changing base resolution is evil! Do not be evil!
@code contributors
I have finished developing the feature, but there was a commit yesterday. Should I incorporate new sources before submitting mines? Please answer, I'm not regular at working with Git.
I'm pretty sure the way I handle zoom without OpenGL will have to be reworked because what I have done does not seem efficient to me. I get the correct result but I introduce a supplementary buffer...
-
Should I incorporate new sources before submitting mines?
As you want. In many cases this is not need. This is really need only if you have conflicts when merging.
-
What is the simplest way too check if this will be the case?
I have updated a branch of my own fork on GitHub with my development, but this branch is not up-to-date with the master branch of SupSuper. In the diff done with GitHub, how can I see if a merge will be necessary?
Edit: I see a rassuring "These branches can be automatically merged" message when trying to do my push request, so I think I am going to submit it.
Edit: Pull request sent.
-
Simplest way is try to merge SupSuper/master into your branch.
If merging was without conflicts, then could be not merge :)
PS
I don't know, how previous phrase sounds for native speaker)))
-
How do I merge SupSuper last changes in my master branch and in my other branch? (on GitHub for the moment)
-
I don't know how to do it on GitHub. I always do merging branches local on my computer, then send or update these branches on GitHub.
-
I tried but I was unable to do it. I believe this is either because I was doing wrong or because I am not in the contributor list...
-
OK. Do you use Git Gui?
1. go to your branch. ctrl-O
2. then local merging. ctrl-M
3. seek branch upstream/master, then click merge.
4. send to GitHub. ctrl-P
-
Git will automatically merge any changes once you pull (fetch & merge) the remote master branch into your master branch. Don't bother applying it to your pull request branch though, or you might just duplicate my changes.
I haven't been answering the question in this thread because I've been too busy with my own stuff, but I would've thought it would've been as simple as just changing the screen surface to match whatever you need, as this doesn't change the scaling ratio so everything else would be fine. Also, the technical term for what you're trying to accomplish is "letterboxing (https://en.wikipedia.org/wiki/Letterboxing_(filming))".
-
Juju Dredd, I looked your code. I think simplest way to do what you want, just add ten strings to screen.cpp:
https://github.com/SupSuper/OpenXcom/blob/master/src/Engine/Screen.cpp#L277
void Screen::setResolution(int width, int height)
{
makeVideoFlags();
if (Options::getBool("keepAspect"))
{
if (!_fullscreen && width * 200 / height < 320)
width = 320 * height / 200;
BASE_WIDTH = BASE_HEIGHT * width / height;
if (BASE_WIDTH & 1)
++BASE_WIDTH; https:// shouldn't be odd
}
...
This code does exactly what you need.
-
(...)
This code does exactly what you need.
But I don't want to increase the size of the base resolution, I just want to add black bands, this is not the same...
Git will automatically merge any changes once you pull (fetch & merge) the remote master branch into your master branch. Don't bother applying it to your pull request branch though, or you might just duplicate my changes.
I haven't been answering the question in this thread because I've been too busy with my own stuff, but I would've thought it would've been as simple as just changing the screen surface to match whatever you need, as this doesn't change the scaling ratio so everything else would be fine. Also, the technical term for what you're trying to accomplish is "letterboxing (https://en.wikipedia.org/wiki/Letterboxing_(filming))".
Sorry, I am simply too impatient because I am discovering OpenXcom...
-
But I don't want to increase the size of the base resolution, I just want to add black bands, this is not the same...
My sample of code does letterbox for screen. Is this what you need?
-
I haven't been answering the question in this thread because I've been too busy with my own stuff, but I would've thought it would've been as simple as just changing the screen surface to match whatever you need, as this doesn't change the scaling ratio so everything else would be fine.
But this is what I have done! The complex thing was changing the way cursor's position is calculated to avoid a "jump" when it enters or exits the game window. I don't know how to explain this better...
-
My sample of code does letterbox for screen. This is what you need?
Oh, err, I don't really understand what you have done, I thought it would extend the shown screen the same way increasing the baseXResolution in options.cfg. I guess the "mouse cursor jump" issue is avoided this way...
-
Juju Dredd, I looked your code. I think simplest way to do what you want, just add ten strings to screen.cpp:
https://github.com/SupSuper/OpenXcom/blob/master/src/Engine/Screen.cpp#L277
void Screen::setResolution(int width, int height)
{
makeVideoFlags();
if (Options::getBool("keepAspect"))
{
if (!_fullscreen && width * 200 / height < 320)
width = 320 * height / 200;
BASE_WIDTH = BASE_HEIGHT * width / height;
if (BASE_WIDTH & 1)
++BASE_WIDTH; https:// shouldn't be odd
}
...
This code does exactly what you need.
I was wondering how the hell you were manipulating const vars, then I noticed it was pseudo-code. :P
Oh, err, I don't really understand what you have done, I thought it would extend the shown screen the same way increasing the baseXResolution in options.cfg. I guess the "mouse cursor jump" issue is avoided this way...
I assume it's because he's only changing the actual screen size without touching the baseXResolution vars, so the game still assumes it's running at 320x200 and gets letterboxed. This probably still results in the cursor getting clipped, but that could be worked around since the cursor is separate from the states.
-
I was wondering how the hell you were manipulating const vars, then I noticed it was pseudo-code. :P
This is not pseudocode. This is really working code)) Yes, for tests only. The code allows resize game window in real time with saving aspect ratio of all surfaces and draw letterbox on right and left sides.
-
this may be a bit off-topic, but I just played around a bit with displayWidth/Height and baseX/YResolution (...I must have missed that before...) - it's really nice, but would it be possible to selectively scale the GUI elements up? I love the high-resolution globe and the big-area battlescape, but the menus and the basescape (and the inventory screen) are really too small. until they are replaced by high-res versions, do you think it would be possible to assign them a scale factor?
for example, I am now playing at display 1280*800 (windowed) and base resolution 640*400, so it would be nice to simply scale the elements by 2. they may look a bit blocky then, but it would increase playability.
I have attached two images (and I would like to apologize in advance for the big images, but here for once it serves a purpose): one shows what the geoscape looks like right now, and the other what I would like it to look like.
-
IIRC the problem with that is the whole game would have to be resolution-aware. Currently we get away with screen scaling because we just scale the final result so the game doesn't need to know (and for baseResolution, we use a lot of if-else-hacks :P). For that every single UI element would have to change based on resolution, and then we might as well just rewrite the whole UI properly. :P
-
is it really that difficult? I would think that with the way it currently works (like in my example picture #1 above), the game already has to deal with two differently scaled systems - I would think that this would actually pose more problems than changing only the globe resolution while keeping the rest at the same relative coordinates?
-
is it really that difficult? I would think that with the way it currently works (like in my example picture #1 above), the game already has to deal with two differently scaled systems - I would think that this would actually pose more problems than changing only the globe resolution while keeping the rest at the same relative coordinates?
The difference is everything is uniformly scaled in the first screenshot. The globe and battlescape map just get "bigger", they're not resized. There is no per-surface scaling.
But don't worry, I'm sure eventually someone will hack that in too and the code will have more options than a spaceship control panel. :P
-
My sample of code does letterbox for screen. Is this what you need?
I have tried your code. It seems to work but it is not really...
In most screens (battlescape, geoscape, introduction) the image is put on the left, it is ugly.
Change the size multiple times after the game start, and you are doomed.
Not speaking you consider there are only wide screens (I love my 5/4 secondary screen and play most games with it), and why the hell should fullscreen mode not be letterboxed if the user wish it?
I must admit your idea is a good base: this method handle mouse cursor very well. Increasing the size of the screen before enlarging it is probably the only way to draw the cursor in the black bands. But your ten lines of code are not enough at all.
Edit:
For GeoScape, I have tried using centerAllSurfaces(), but the globe does not like this. It's better using an offset for the surface, globe, and each button.
With Battlescape, centerAllSurfaces() works better, but the scrolling with mouse cursor does not function, it seems to uses coordinates relatives to the window rather than relative to the shown screen.
-
Yes, BattleScape and GeoScape specially designed for maintain wide screens.
For GeoScape, I have tried using centerAllSurfaces(), but the globe does not like this. It's better using an offset for the surface, globe, and each button.
With Battlescape, centerAllSurfaces() works better, but the scrolling with mouse cursor does not function, it seems to uses coordinates relatives to the window rather than relative to the shown screen.
If you have interest about solution this problem, this branch changes absolute coordinates to relative:
https://github.com/redv/OpenXcom/compare/fix_mouse_coord
But, in my opinion, maintain wide screen is much more important.
I like, how looks the game on wide screen)
-
Yes, BattleScape and GeoScape specially designed for maintain wide screens.
If you have interest about solution this problem, this branch changes absolute coordinates to relative:
https://github.com/redv/OpenXcom/compare/fix_mouse_coord
But, in my opinion, maintain wide screen is much more important.
I like, how looks the game on wide screen)
Is this branch going to be merged in the main one?
If it is, this means I should wait this before implementing letter boxing.
-
Is this branch going to be merged in the main one?
No. Of course, no. This is only for experiments.
-
I've done some work on OP's topic, but only for the OpenGL renderer. I stopped working on it because I couldn't figure out how to do it for the SDL mode and I couldn't build OpenXcom without it running extremely slowly (this has nothing to do with my patch, however, probably just my build environment isn't quite right)
It is completely finished though, for OpenGL. The only thing that hasn't been done is adding the option to the ingame menu.
You can shamelessly steal it, if you'd like: here's the original post of it (https://openxcom.org/forum/index.php/topic,1185.msg10923.html#msg10923)
-
Does the way you made it permit the cursor to enter the black bands without turning invisible?
-
Yes, BattleScape and GeoScape specially designed for maintain wide screens.
If you have interest about solution this problem, this branch changes absolute coordinates to relative:
https://github.com/redv/OpenXcom/compare/fix_mouse_coord
But, in my opinion, maintain wide screen is much more important.
I like, how looks the game on wide screen)
I have tried setting the base X resoltion to 356 to see it. Geoscape is just ugly: the background and buttons are moved to the right, letting appear a wide black band on the left, and if you zoom once the globe exceed the black band. I don't understand the way it has been done. If you really wanted to do it this way, you should have changed the background picture to make it wider.
-
slightly off-topic, but perhaps related (or at least the active guys here might know where to look for the problem):
I'm currently enjoying playing at "baseXResolution: 640 baseYResolution: 400" with "displayHeight: 800 displayWidth: 1280" windowed mode, giving me large battlescape and geoscape globe while having a large-enough menu. all non-scaled screens are centered, which looks good, except for the battlescape "HIDDEN MOVEMENT" screen, which is... off. screenshot is attached.
screen001: "Press button to continue" looks fine, everything's centered
screen002: "HIDDEN MOVEMENT" has the pop-up window extending down to the bottom of the window, filled with grey space where the image ends, and the text centered vertically within that window, resulting in the text sitting too low on the screen - probably a secondary effect to the pop-up using the wrong Y coordinates.
-
Ouch.
It hurts a bit...
-
@juju dredd: what hurts? the huge screenshots? I'm sorry, but scaling them down wouldn't really make sense in this context, I'd think.
-
@juju dredd: what hurts? the huge screenshots? I'm sorry, but scaling them down wouldn't really make sense in this context, I'd think.
No, the grey band, it looks rather ugly...
-
screen002: "HIDDEN MOVEMENT" has the pop-up window extending down to the bottom of the window, filled with grey space where the image ends, and the text centered vertically within that window, resulting in the text sitting too low on the screen - probably a secondary effect to the pop-up using the wrong Y coordinates.
Added pull request https://github.com/SupSuper/OpenXcom/pull/627
-
Added pull request https://github.com/SupSuper/OpenXcom/pull/627
thank you! :)
-
Great job ;)
-
I wish you guys would figure out which code is the better one before making a pull request, because it just makes me confused after looking at all these forum discussions, if I should actually merge stuff or not. :P
-
Hello,
I don't understand. I received an automatic message from Github, and according to the link inside it somebody has merged my branch. But I thought you told me the way I was doing it was wrong. It was rather clear to me that you would refuse the branch...
-
From the discussions around here it seemed you had the better method, even if it wasn't perfect, so better have something than nothing. If someone comes up with a better way they can just submit a "fix".
-
Okay. I compare what I have done with Redv's proposition:
Juju Dredd, I looked your code. I think simplest way to do what you want, just add ten strings to screen.cpp:
https://github.com/SupSuper/OpenXcom/blob/master/src/Engine/Screen.cpp#L277
void Screen::setResolution(int width, int height)
{
makeVideoFlags();
if (Options::getBool("keepAspect"))
{
if (!_fullscreen && width * 200 / height < 320)
width = 320 * height / 200;
BASE_WIDTH = BASE_HEIGHT * width / height;
if (BASE_WIDTH & 1)
++BASE_WIDTH; https:// shouldn't be odd
}
...
This code does exactly what you need.
The way I was doing it is changing the scaling so it uses only part of the window. It was rather simple but it has two drawbacks:
- it is impossible to draw the mouse cursor in the black bands. Or cursor should be drawn after scaling the picture. This would be wrong because cursor would not be scaled, as a purist I would hate that.
- not-opengl scaling should be reworked, because I am currently doing it using a supplementary buffer for adding the black band which is obviously not efficient. The problem is it seems to me unnecessarily complex to update not-opengl scaling.
The way Redv propose to do it is rather different, it is adding black bands before scaling the picture. Mouse cursor is then automatically drawn in black bands and not-opengl scaling doesn't need any update. The problem is it has other impacts I have mentioned there (https://openxcom.org/forum/index.php/topic,1514.msg13927.html#msg13927).
After examining Redv's proposition, I started to think using it as a base was a lot simpler than trying to improve mine.
So what I plan to do is doing another branch which rollbacks my previous one and then implement Redv's proposition. Do you agree with this?
-
Sure, as long as something works in the end. :P You can easily perform "rollback commits" with Git.
-
Sorry for bump, but I wanted to ask about something
Will there be an option to clear the black bands every frame? If you've got the Steam overlay going then you get a HOM effect on the black bands where notification boxes persist
Otherwise, it works great! (except for the option not being in the in-game Advanced Options)
-
Sorry for bump, but I wanted to ask about something
Will there be an option to clear the black bands every frame? If you've got the Steam overlay going then you get a HOM effect on the black bands where notification boxes persist
Otherwise, it works great! (except for the option not being in the in-game Advanced Options)
It's me who is sorry, I have no time at the moment...
The way letterboxing is done will be completely redone.
Currently, it adds black bands after picture is enlarged. If you read the topic, another method has been given by redv, but I had no time to develop it so far because it requires some work. It consist in adding black bands before enlarging picture, it should solve your problem.