Anyone know how to get the system's supported resolutions in bge?

Charles_S · July 29, 2017, 6:18pm

Currently in my game (demo, really) you enter the resolution manually in text boxes.

My brother pointed out that this is probably going to be awkward, dangerous, and error prone, and that it would be much better to just have a drop down list of resolutions the computer you’re playing on supports.

The drop down list is easy, but interrogating the computer for the supported resolutions… no clue. Even pure Python doesn’t seem to have a platform independent solution to this.

Anyone got any ideas for doing this in the bge?

Nicholas_A · July 29, 2017, 6:37pm

What I do is have a list of resolutions like res = [(1280, 720), (1920, 1080)] and so on. The user can then select the resolution then just use bge.render.setWindowSize(width, height)

pqftgs · July 29, 2017, 7:08pm

The current meta is to list common resolutions + have an option for current desktop resolution.
You’re right there doesn’t seem to be a built-in cross-platform way to do it. Options:

Integrate a third party library.
Determine OS with platform.system() and run platform-specific code.
Prepare an offering to the BGE god.

Some quick Googling found this:

Only problem is that it doesn’t get tested on MacOS. But a person could totally fix that.

Example attached.

(BTW the zip has to be extracted otherwise paths are messed up and it wont find the module)

EDIT: Nvm I forgot about bge.render.getDisplayDimensions()
Nothing to see here…

Attachments

resolution.zip (85.1 KB)

Cotaks · July 29, 2017, 7:19pm

It doesn’t really matter, the resolution that you can set is for windowed render, you can not set the internal render(or i missed something).
so running fullscreen at 800x600 has the same quality as running it in 1920x1080.

With that said i’m using a handmade dict with resolution and simply use an index with arrow buttons to click trough them.
if you need the dict look in my sig, game launcher, most if not all resolutions are there, use it as you like.

pqftgs · July 29, 2017, 8:10pm

loud annoying buzzer
Nah it’s definitely a thing (just tried it to make sure I’m not crazy) and having the wrong aspect ratio will make it all stretched. A person might want to decrease fullscreen resolution to squeeze out more performance, although I’m not sure how much that actually does these days…

Side note: I guess desktop resolution powers of 2 could be considered compatible. Or anything with the same aspect? Or not. PTSD flashback
Side note #2: I also guess there’s bge.render.getDisplayDimensions(), but on Linux it returns the sum of all monitors unless you’re on UPBGE. I suppose you don’t really need that lib after all.

Charles_S · July 29, 2017, 8:17pm

@Nicholas_A: That’s what I figure I’m going to do if I can’t find the preferred solution. Easy.

@pqftgs: @point 1: I saw the same package. Not sure I really want to go that direction. @point 2: I like this idea, I just won’t be able to test it for anything other than Winblow$. @point 3: I have no goats left tho.

@Cotaks: I think the difference is between running with [p] from within blender and exporting to an executable. I’m sure I can change the true resolution of the game engine just fine with the exported engine, but I do, indeed, see no change when run from within Blender.

pqftgs · July 29, 2017, 8:45pm

Cotaks · July 30, 2017, 5:02am

@Cotaks: I think the difference is between running with [p] from within blender and exporting to an executable. I’m sure I can change the true resolution of the game engine just fine with the exported engine, but I do, indeed, see no change when run from within Blender.

loud annoying buzzer
Nah it’s definitely a thing (just tried it to make sure I’m not crazy) and having the wrong aspect ratio will make it all stretched. A person might want to decrease fullscreen resolution to squeeze out more performance, although I’m not sure how much that actually does these days…

so look at this and tell me that you say it works…

at first i thought it was my driver that didnt scale it, so i told my driver to stretch it out, same result as in the video. the resolution is not working properly for fullscreen.

#edit
how i see it:

pqftgs · July 30, 2017, 8:26am

Well that is definitely not what happens over here. Must be a Windows vs Linux thing.

Charles_S · July 30, 2017, 6:14pm

Derailing the thread, but I don’t really mind…

So, I just spent the last hour or two confirming that it does, in fact, appear to fail to properly use fullscreen resolutions set from within Python scripts. This is true when run with the “stand alone” or with “export game.” My first thought was that we may need to set/clear the Python api equivalent to stand alone player’s “desktop” button, but I tried some things and that doesn’t seem to be the problem. I’m not exactly sure what the deal is now. This should probably be reported as a bug, if it hasn’t already been.

I’m on Windows 7 btw.

Charles_S · July 30, 2017, 6:29pm

Back on topic:

Since I doubt there is a solutions to the original question, I think I’m just going to do a list of resolutions.

I realize now that IF the user can change the aspect ratio of my view into the game it may be game breaking. So I figure that it would be best to lock them into 16:9; so all the blue resolutions here. That is only 8 entries, which should be every 16:9 screen size ever made.

…If only we have a solution to the new problem, however.

Cotaks · July 30, 2017, 7:21pm

as for reading out supported resolutions, i have no idea if that is currently possible.
But you can grab the current screen resolution with:


bge.render.getDisplayDimensions()

More info in this thread:

Charles_S · July 30, 2017, 7:57pm

@Cotaks " […]you can grab the current screen resolution[…]"

Sure. Problem is reading the current resolution is mostly meaningless really. The only way reading the resolution would be valid is if you already have something working, implying that you already know something about the user’s system.

The whole point of supporting adjustable resolutions, IMHO, is first and foremost to let the user run at their choice of safe resolutions. The reason for choice would be the performance trade off, and running what’s native to the screen to avoid stretching artifacts. But the “safe” operation comes first, and here’s why.

A resolution that the system can’t display will typically show a blank screen with no way to change it. It’s “unsafe” in the regard that the user is permanently locked out. That’s why 99% of games give you a countdown popup asking you to confirm that the graphics settings are working. They do this so the game can automatically return back to what was working in the event the user can’t even see to be able to do that themselves.

Currently looking at bge source to try and get a clue as to what’s going on with the resolution not respecting Python api settings. At a glance it looks like KX_PythonInt.cpp, line 1329 is the problem. Observe…


...
1322
1323    static PyObject *gPySetWindowSize(PyObject *, PyObject *args)
1324    {
1325        int width, height;
1326        if (!PyArg_ParseTuple(args, "ii:resize", &width, &height))
1327            return NULL;
1328    
1329        gp_Canvas-&gt;ResizeWindow(width, height);  &lt;--- Resize "window," are we maybe assuming something here?
1330        Py_RETURN_NONE;
1331    }
1332
...

The wording of that method suggests that it may only ever work for windows, not fullscreen. But that’s just my knee-jerk, off-the-cuff assessment. Need to examine that methods source still.

Edit; actually (lol) the python api function/method is also named similar…

Cotaks · July 30, 2017, 8:36pm

Sure. Problem is reading the current resolution is mostly meaningless really. The only way reading the resolution would be valid is if you already have something working, implying that you already know something about the user’s system.

Why? you start your game, first thing you do is " test = bge.render.getDisplayDimensions() " then set " render.setWindowSize(test[0], test[1]) ".
Now you running at the resolution that is perfectly save for every user on every operating system (windows/mac/linux).

The whole thing with the source code, no idea never looked into it. and resizewindow does not have to be windowed window, fullscreen as what blender does is just border less window, it is not a True full screen setting. And as pqftg stated it works how it should on linux, so another strange thing.

Charles_S · July 30, 2017, 10:02pm

Why? you start your game, first thing you do is " test = bge.render.getDisplayDimensions() " then set " render.setWindowSize(test[0], test[1]) ". Now you running at the resolution that is perfectly save for every user on every operating system (windows/mac/linux).

Disregard what I said, it was meaningless to the context. (I am/was doing… like… six things at once.) I wasn’t really paying attention I guess, so I misread “bge.render.getDisplayDimensions()” as “bge.render.getCurrentResolution(),” a non existent function that would return a resolution which BGE already set up just fine. I felt interrogating BGE for that resolution info to set up that same resolution again would be quite redundant.

Getting past my misreading, I still don’t see too much use for getDisplayDimensions() beyond screen space calculations.

BGE already seems to do a decent job finding the best safe resolution, and that is almost always native. If it already finds 90% of system’s native resolution, should we really be trying to reinvent this particular wheel? I figure that if BGE can’t figure out the best safe resolution[s] by itself, then getDisplayDimensions() probably isn’t going to return anything meaningful either.

(… I had typed out a point about performance here, but it adds too much signal to noise for one post.)

My whole issue is providing a choice of resolutions that BGE has deemed safe, so the user has options for performance trade off. It’s really too bad BGE doesn’t seem to provide this in the Python API.

and resizewindow does not have to be windowed window, fullscreen as what blender does is just border less window, it is not a True full screen setting.

I really don’t mean to be so disagreeable with you (apparently!?), but I don’t think this claim is entirely true.

When I launch the standalone player in a non native resolution, my screen blanks, reinitializes, and then displays in the new resolution. This series of events only happens on my system when the actual broadcast resolution from the videocard changes. It switches more or less instantly when the resolution is a borderless window with sub-native resolution.

So I have strong reason to believe that the BGE has the capability to run the GPU output at the chosen resolution when in fullscreen mode. Can you demonstrate that it is, in fact, windowed fullscreen instead? Id be open to a different set of evidence.

I KNOW I have had the exported BGE running in 800x600 fullscreen before… wondering why it doesn’t work now. Standalone Player button respects it’s resolution settings, just not when set in the BGE.

… needs more investigation to be sure. Probably just not setting it up right or something.

Cotaks · July 31, 2017, 2:47am

I KNOW I have had the exported BGE running in 800x600 fullscreen before… wondering why it doesn’t work now. Standalone Player button respects it’s resolution settings, just not when set in the BGE.

it is because i said in post #8, the picture.

The embedded player resolution is the resolution the game gets rendered in (physical resolution)
The standalone resolution is the virtual resolution that we can adapt to our likings.

simply set embedded to 800x600 resolution and keep the standalone at 1920x1080, now you see you get a fullscreen 800x600 resolution stretched to the standalone resolution 1920x1080.

Also if it was true fullscreen you wont get the results as in the video i posted, this indicates a borderless window that gets rendered at top left of the screen(not true fullscreen). But… if you check fullscreen option and then run the standalone you get a stretched resolution (and this is true fullscreen).

So after some more testing, it gives me a strange behavior. while python read out the fullscreen and set the fullscreen, it is bugged somewhere down the path. because if you use the fullscreen checkbox of standalone player, and then set the resolution to 8000x600 you get your stretched screen.

It seems that the fullscreen in python don’t get called/rendered.
I will make a new thread about this and add a video to show this behavior because i think your topic gets way off topic.