screen_width() and screen_height() return window size, but not fullscreen size
When in fullscreen mode, screen_width() and screen_height() return the size of the window, but not the size of the full screen. It would be useful to return the actual available space for drawing.
hmm, this may be a very serious bug, thanks for reporting!
Unfortunately, I can't really reproduce it:
use macroquad::prelude::*;
fn window_conf() -> Conf {
Conf {
window_title: "Window Conf".to_owned(),
fullscreen: true,
..Default::default()
}
}
#[macroquad::main(window_conf)]
async fn main() {
loop {
clear_background(BLACK);
draw_rectangle(5., 5., screen_width() - 10., screen_height() - 10., RED);
next_frame().await
}
}

This rectangle takes all the space available :(
Could you give a reproducible example and some info about the platform you are on?
Thanks for your quick response.
Actually, my example is rather complicated (see nacl42/reveal).
It seems, that when I start my example several times, then two out of three times, the full screen size is recognized, while for one out of three times, the smaller window size is returned. Since you reported that this shouldn't occur, I switched my window manager from XFCE to GNOME, and surprisingly everything works fine there. So this seems to be a problem with xfwm4 and not necessarily with macroquad.
I can confirm this happens randomly on Kubuntu 20.10 - maybe one time out of 20. A quicker way to repro is something like this:
use macroquad::prelude::*;
fn window_conf() -> Conf {
Conf {
window_title: "Window Conf".to_owned(),
fullscreen: true,
..Default::default()
}
}
#[macroquad::main(window_conf)]
async fn main() {
dbg!(screen_width());
assert_eq!(screen_width(), 1920.0);
}
Run it multiple times until you get a failure.
I can confirm this happens randomly on Kubuntu 20.10 - maybe one time out of 20. A quicker way to repro is something like this:
use macroquad::prelude::*; fn window_conf() -> Conf { Conf { window_title: "Window Conf".to_owned(), fullscreen: true, ..Default::default() } } #[macroquad::main(window_conf)] async fn main() { dbg!(screen_width()); assert_eq!(screen_width(), 1920.0); }Run it multiple times until you get a failure.
is it the same value after a few frames? Maybe window manager is doing weird things while stretching the window?
Yeah, seems like after a few frames it starts reporting the correct fullscreen size. It still complicates things for me though because I need to create render targets with the correct size during init so I'd need to resize them later.
Since this probably can't be fixed cleanly, would it make sense to use some kind of ugly workaround? I am thinking macroquad could wait a few frames and check the window size before giving control to user code (the contents of main).
- It would only do that when fullscreen is requested so there'd be no additional startup time for non-fullscreen games.
- In my tests, when the size is wrong, it always corrects itself on the 3rd frame (interestingly, never earlier - it's either correct from the start or 3rd frame) so there could be a max timeout of say 100 ms to be sure.
- It could use some magic value for
window_widthandwindow_heightthat is sure not to be fullscreen on any sane device (e.g. 1x100 px), then it could check whatscreen_width()andscreen_height()return so that it could give control to user code even before the timeout elapses if startup time is a concern.
Still occurs in 0.4.14 on Windows, with this MWE:
use macroquad::{conf::Conf, prelude::*};
fn conf()->Conf{
Conf{
miniquad_conf : miniquad::conf::Conf{
fullscreen : true,
..Default::default()
},
..Default::default()
}
}
#[macroquad::main(conf)]
async fn main() {
loop {
let (width,height) = (screen_width(),screen_height());
draw_rectangle(0., 0., width, height, GREEN);
draw_text(&format!("{width},{height}"), 10.,40., 40., BLACK);
next_frame().await
}
}
The reported (width,height) is 2048x1152 (my screen is 2560x1440)