New graphical option: Black bands to keep aspect ratio

[Juju Dredd]

How do I merge SupSuper last changes in my master branch and in my other branch? (on GitHub for the moment)

[redv]

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.

[Juju Dredd]

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...

[redv]

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

[SupSuper]

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".

[redv]

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

Code: [Select]

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.

[Juju Dredd]

(...)

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".

Sorry, I am simply too impatient because I am discovering OpenXcom...

[redv]

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?

[Juju Dredd]

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...

[Juju Dredd]

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...

[SupSuper]

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

Code: [Select]

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.

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.

[redv]

I was wondering how the hell you were manipulating const vars, then I noticed it was pseudo-code.

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.

[moriarty]

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.

[SupSuper]

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 ). 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.

[moriarty]

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?