Fyrox icon indicating copy to clipboard operation
Fyrox copied to clipboard

Editor window doesn't display properly

Open AntarEspadas opened this issue 2 years ago • 19 comments

After initializing a new Fyrox project with fyrox-template init --name fyrox_test --style 2d and running the editor with cargo run --package editor --release I encountered an issue where the editor window wouldn't display properly, with the window being cut off by black bars (See image below).

I'm on Arch Linux. Any help would be appreciated.

image

AntarEspadas avatar May 11 '23 21:05 AntarEspadas

What is your desktop environment and display server? If it's wayland, try on the X11 and see how it goes.

IceGuye avatar May 12 '23 04:05 IceGuye

I made a quick fix (?), could you please check again on latest? (Use this guide to update the engine).

mrDIMAS avatar May 12 '23 14:05 mrDIMAS

I use xorg with KWin.

The fix does not seem to have worked for me

image image

AntarEspadas avatar May 12 '23 15:05 AntarEspadas

What will happen if you try to resize the window manually, will this fix the bug?

mrDIMAS avatar May 12 '23 16:05 mrDIMAS

The problem persists regardless of window size

image image image

AntarEspadas avatar May 12 '23 16:05 AntarEspadas

Do you have hi-dpi monitor or maybe you have system scaling more than 100%? I'm trying to collect as much info as possible to find the actual cause of the bug.

mrDIMAS avatar May 12 '23 17:05 mrDIMAS

That's it! I use a custom font dpi of 85, reverting to the default fixes the issue.

With that said, I would rather not have to change my configuration just to run the editor.

AntarEspadas avatar May 12 '23 18:05 AntarEspadas

With that said, I would rather not have to change my configuration just to run the editor.

You can run the fyrox editor with an environmental setting:

QT_FONT_DPI=96 cargo run --package editor --release

IceGuye avatar May 12 '23 19:05 IceGuye

This does not seem to work. While specifying the dpi with QT_FONT_DPI=96 seems to work on other applications, like Dolphin and Firefox, it doesn't seem to have any effect on the editor

AntarEspadas avatar May 12 '23 20:05 AntarEspadas

Thanks! Now I understand what I did wrong - I didn't take DPI scaling into account when creating/resizing GL surface. I'll try to fix this today.

mrDIMAS avatar May 13 '23 11:05 mrDIMAS

@Naratna could you please re-check if the bug is fixed?

mrDIMAS avatar May 13 '23 15:05 mrDIMAS

Unfortunately, this does not fix the issue

AntarEspadas avatar May 13 '23 17:05 AntarEspadas

Could you please run the 3rd_person example and check if the issue also reproduces there? I cannot reproduce the issue (I'm on Windows), so it is kinda hard for me to find the actual cause.

mrDIMAS avatar May 13 '23 18:05 mrDIMAS

I'm getting the same issue on Ubuntu Linux, and I also have DPI scaling. (I'm using the "nightly" from github.) FWIW, It seems that I can interact with the UI in the black parts. Like, I can drag the inspector into the black area and back again. It seems like all the controls are there, but they're getting clipped somehow. (I'm too unfamiliar with Fyrox to confirm this.)

I get the same issue with the standalone editor, too.

I've confirmed that QT_FONT_DPI= 96 or 100 or whatever has no effect; and that setting the DPI scaling to 100% system wide fixes the issue

$ gsettings set org.gnome.desktop.interface text-scaling-factor 1.0

FWIW, setting the scale factor to .99 causes the black area to shrink. So, yeah, it's likely a scaling issue. fyroxed_bug_text-dpi-scaling

jpaugh avatar Jan 30 '24 05:01 jpaugh

Could you please run the 3rd_person example and check if the issue also reproduces there? I cannot reproduce the issue (I'm on Windows), so it is kinda hard for me to find the actual cause.

Where would I find that example? I couldn't find anything in the fyrox source or the website referring to that.

I did find that my shiny, new project looks just fine when I execute it with the executor package, as well as the platformer example and fps example from the book. The problem seems to be limited to the editor application itself --- or maybe the UI code? (The RPG tutorial had an issue where the whole screen was blank, and changing the text scale factor had no effect.)

The images below were all taken with a text scale factor of 0.8 (80%).

  • Freshly init'd game fyrox_no-bug_new-templated_game

  • 2d platformer tutorial fyxrox_no-bug_platformer-example

  • FPS tutorial fyrox_no-bug_fps

jpaugh avatar Jan 30 '24 05:01 jpaugh

I found a workaround that should help others out. Basically, I set the scale factor to 100% until the Fyrox editor loads, then immediately set it back to 80%, even while Fyrox is running. The editor doesn't glitch, even when I resize it / maximize it.

I made a bash function to do this for me; and if you're using bash and Gnome Desktop, you can use this function directly. Others can probably adapt it to their window manager and shell.

  1. Add the script below to your .bashrc file.
  2. Open a new shell (or otherwise reload .bashrc)
  3. Use the fyrox-edit command instead of cargo run --package editor
  4. Adjust the sleep_seconds variable to the minimum value you can reliably get away with, and reload the shell after each edit. In my experiments, I am able to get it as low as 0.3. It re-scales my GUI fonts back before the editor even finishes loading the scene preview, so that's probably as close as I can cut it.
fyrox-edit () {
  local sleep_seconds=2.0
  # Cache the build to avoid a pre-mature timeout
  cargo build --package editor --release

  # Schedule the DPI settings to go back to normal after a few seconds
  __restore_text_scaling "$sleep_seconds" &
  sleep 0.1 # Pre-empt race condition, that probably never happens (TM)
  # Set scale factor 1.0 for Fyrox and proceed
  gsettings set org.gnome.desktop.interface text-scaling-factor 1.0
  cargo run --package editor --release
}


__restore_text_scaling () {
  # Reset scale factor to the default after a few seconds
  local sleep_seconds="$1";shift
  local correct_scale_factor=$(gsettings get org.gnome.desktop.interface text-scaling-factor)
  sleep "$sleep_seconds"
  gsettings set org.gnome.desktop.interface text-scaling-factor "$correct_scale_factor"
}

Edit: I updated the script to keep cargo/fyrox running in the foreground, so you can shut it down with Ctrl+C.

jpaugh avatar Jan 30 '24 06:01 jpaugh

@jpaugh Hi, I did yet another potential fix for the editor. Could you please check if it works? I'm on Windows and it works fine here.

mrDIMAS avatar Jan 30 '24 17:01 mrDIMAS

Unfortunately, that didn't change the outcome. I tried by adding the nightly build to a fresh project (built with the released fyrox-template 0.10.0), and also tried running the standalone editor directly from the latest on main (811a1342).

I did some more analysis with the first run. The screenshot at the bottom is with text scaling set to 80%. I also recorded the editor's stdout. Didn't see anything notable there, but it's attached (run.log). FWIW, the window_size setting seems to be mostly correct in the settings.ron, although it's a few pixels smaller from the size of my screenshot. Probably comes down to window decoration (i.e. border and the title bar).

BTW, I also had to fix a compile error in the project as generated. The editor/src/main.rs passed two arguments to Editor::new() instead of one. I just removed the loop argument, per your merged change. It might be due to using a non-nightly version of fyrox-template, but the generation step is magic to me, so IDK.

fyrox_bugfix_compile-error

fyrox_bug_screen-glitch

jpaugh avatar Jan 31 '24 03:01 jpaugh

Thanks so much for your support! I'm personally comfortable with the workaround I suggested, and I might be able to dig in a little more and debug things after I figure out how to build my own UI in Fyrox. :crossed_fingers:

jpaugh avatar Jan 31 '24 03:01 jpaugh