Skip to content

Resolution adjustments #68

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
RobertCochran wants to merge 5 commits into
base: main-MC1.21.1
Choose a base branch
from
+31 −2
Open

Resolution adjustments #68

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
3ac7b71
OpenOS: limit boot resolution to 80x25
RobertCochran Aug 23, 2026
1307d87
Add GPU function to check which side may be limiting capabilities
RobertCochran Aug 23, 2026
86f71d9
OpenOS: add --max flag to resolution
RobertCochran Aug 23, 2026
a57140a
Remove useless comment
RobertCochran Aug 23, 2026
b4f738d
Revert "OpenOS: limit boot resolution to 80x25"
RobertCochran Aug 23, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 12 additions & 2 deletions src/main/resources/data/opencomputers/opencomputers/loot_disks/openos/bin/resolution.lua
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,17 +1,27 @@
local shell = require("shell")
local tty = require("tty")

local args = shell.parse(...)
local args, ops = shell.parse(...)
local gpu = tty.gpu()

if ops["max"] then
local w, h = gpu.maxResolution()
io.write(w," ",h,"\n")
local limiter = gpu.capabilityLimiter()
if limiter then
io.write("(Limited by ",limiter,")\n")
end
return
end

if #args == 0 then
local w, h = gpu.getViewport()
io.write(w," ",h,"\n")
return
end

if #args ~= 2 then
print("Usage: resolution [<width> <height>]")
print("Usage: resolution [<width> <height>] or resolution --max")
return
end

Expand Down
19 changes: 19 additions & 0 deletions src/main/scala/li/cil/oc/server/component/GraphicsCard.scala
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -436,6 +436,25 @@ class GraphicsCard(val tier: Int, val vramScreens: Option[Double] = None, val vi
result(math.min(gmw, smw), math.min(gmh, smh))
})

@Callback(direct = true, doc = """function():string or nil -- Return which of GPU or screen is limiting display capabilities, if either""")
def capabilityLimiter(context: Context, args: Arguments): Array[AnyRef] =

@RobertCochran RobertCochran Aug 23, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not married to this name, and honestly half-think it needs a better one. Suggestions welcome.

@asiekierka asiekierka Aug 23, 2026 •
edited
Loading

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cheesy, but, like, getTierConstraintSource()?

@Ocawesome101 Ocawesome101 Aug 23, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would adding a tier field or similar to each component be a more flexible way of doing this? Or the screen component could have its own maxResolution/maxDepth methods.

@RobertCochran RobertCochran Aug 23, 2026 •
edited
Loading

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would adding a tier field or similar to each component be a more flexible way of doing this?

I'm not sure it's useful in any other context to know specifically the tier of a component. In most other cases I am aware of, there are sane ways to do capability querying that don't involve needing to depend on comparing against hardcoded assumptions of said capabilities - it is possible to tell the different NICs and data cards apart from each other just by asking what they are capable of doing. This particular weird wart in the way that GPUs and screens don't do this is irregular among the rest of the components.

Or the screen component could have its own maxResolution/maxDepth methods.

This might be preferable. GPU and screen each get new methods called maxPossibleResolution() and maxPossibleDepth() (or similar) that always return the maximum each piece of hardware could support, so that maxResolution() and maxDepth() can keep their existing meaning of currently-possible maximum instead of theoretically-possible maximum.

// FIXME: Assumes that GPU/screen tiers do not differ only by color depth,
// which is *currently* valid but may not be in the future. It would be
// better to just use the tier values directly, but I couldn't figure out
// how to access the physical screen from the TextBuffer...
Comment on lines +441 to +444

@RobertCochran RobertCochran Aug 23, 2026

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This implementation is slightly gross in that comparing GPU and screen tiers directly would make it work correctly in all cases without making assumptions about how graphics capabilities scale in the mod. If we can figure out how to make that happen, that'd be a much better implementation.

screen(s => {
val gmw = maxResolution._1
val smw = s.getMaximumWidth
result(
if (gmw > smw)
"screen"
else if (gmw < smw)
"gpu"
else // Equal, so neither is limiting
null
)
})

@Callback(direct = true, doc = """function():number, number -- Get the current viewport resolution.""")
def getViewport(context: Context, args: Arguments): Array[AnyRef] =
screen(s => result(s.getViewportWidth, s.getViewportHeight))
Expand Down
Loading