FyroxEngine / Fyrox

3D and 2D game engine written in Rust
https://fyrox.rs
MIT License
7.81k stars 357 forks source link

Editor window doesn't display properly #453

Open AntarEspadas opened 1 year ago

AntarEspadas commented 1 year ago

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

IceGuye commented 1 year ago

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

mrDIMAS commented 1 year ago

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

AntarEspadas commented 1 year ago

I use xorg with KWin.

The fix does not seem to have worked for me

image image

mrDIMAS commented 1 year ago

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

AntarEspadas commented 1 year ago

The problem persists regardless of window size

image image image

mrDIMAS commented 1 year ago

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.

AntarEspadas commented 1 year ago

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.

IceGuye commented 1 year ago

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

AntarEspadas commented 1 year ago

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

mrDIMAS commented 1 year ago

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 commented 1 year ago

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

AntarEspadas commented 1 year ago

Unfortunately, this does not fix the issue

mrDIMAS commented 1 year ago

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.

jpaugh commented 10 months ago

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 commented 10 months ago

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

jpaugh commented 10 months ago

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.
mrDIMAS commented 10 months ago

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

jpaugh commented 10 months ago

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 commented 10 months ago

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: