-
Notifications
You must be signed in to change notification settings - Fork 5
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.
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
Screen size different from render size on 4k monitor #20
Comments
that's probably DPI scaling? there's fields on the core to adjust it. I thought I had fixed it, but I guess not? It would be helpful if you could give more information about your monitor resolution and scaling, etc., and whether you're using Xorg or Wayland? I have tested on a hidpi scaled Xorg Linux and also on macs, both of which seem to work. Clearly I overlooked something, let's try to figure it out. |
Xorg no Wayland here.
No scaling on Xfce settings (just 1x in other words). Any other info you might need? I think I had a similar issue with dvui (a zig based immediate mode ui), but I can't remember off hand how we fixed it, darnit. |
Thanks for the details. Yeah, I think I see the issue, it's fractional scaling. Right now I assumed all scaling would be integer. But there's not really anything preventing fractional scaling from working either, so it should be an easy fix. |
@wilsonk can you please set this in your entry point before reng initializes, and send all the logs? I want to see what happens with the window size and scaling calculations.
|
Hmm, I have tried putting that statement at every single line of the quickshd example to no avail. Then I tried changing core.d initializer at line 103 to .debug_, recompiled the lib and the example with --force...no change, only INFO debug informaiton is produced. I literally don't know what else to even try, sorry? |
can you go to core and window and just add a bunch of logs to see what it's detecting as the scale DPI, window size, screen size, then go to scene and print out the render target size |
ok, so I should clarify some things. there are some overlapping things that can be confusing: in raylib we have:
please see:
|
It would be really helpful if you could figure out how to share your reng logs. Here are mine, on a HIDPI macOS display, for example: note the following:
|
please check the |
Strange, can you not see this INFO output in the screen capture at the top? I can if I zoom in a bit...but anyways, here it is in a clearer form:
|
based on that, it seems both render size and screen size look correct no? one thing that might be useful: in the core find where it draws the scene render target, then ensure it's drawing it to the correct screen bounds: in screen space the rect should still be 960x540 also please check that the render target itself is the right shape there's also a possibility that the lack of fractional scaling is on raylib's side, but I'll have to double check |
Yeah it looks like the render and screen sizes are right and it looks like the calculation for fractional scaling is being done correctly for the window.dpi_scale variable (=1.375), as 1320/960 is 1.375. So now I guess dpi_scale just needs to be applied everywhere that it would be necessary? I guess...? It seems like the nuidemo should be grabbing the dpi_scale and applying it correctly but that doesn't seem to be the case...argh! Here is what David and I did on dvui, but that was with SDL: Looks like things might be even worse on windows?: According to raysan5 scaling is pretty broken as of April: |
Sorry if I am bothering you with this stuff :) I am getting different sizes on almost all examples between render and screen while using a 4k monitor on linux.
So I end up seeing this type of thing where the port is different from the full window size. It is very apparent on the pong game, as I can't see both players and all edges (this is with a very low level card, but I doubt that matters):
Seems to work fine with MacOS on the same 4k monitor, however. I would test on windows, but the build is failing with glfw3_mt.lib missing with mingw64?
The text was updated successfully, but these errors were encountered: