How to properly do resizing

[vorner]

I'm trying to create a kind of view of the game world. And I want to let the user use however large window they like, simply showing as much of the world/map as it fits and implement some kind of follow-the player or scrolling. However, it seems quicksilver somehow prefers games that have finite bounded world and makes it smaller and larger with the window ‒ and therefore somehow rescaling what one pixel means in the coordinates. I've eventually made it work with set_projection, but it took some amount of digging through the docs, as it is not entirely intuitive that this needs to be done (well, maybe for people who do gamedev longer than 4 weekends it is).

To demonstrate, this „world“ is just 40 000 blue dots in a regular square grid. I'd expect that when I resize the window, I see fewer or more of them. Instead, they get compressed or stretched and I get ellipses instead.

So my question is, does it make sense to have an example with resizing? Maybe if I add the set_projection here?

(This one is probably not good in other ways, it seems the rendering in a tight loop is hogging my system and maybe I should be doing something else than just naïvely place the circles one by one).

(Trying with linux, quicksilver version 0.4.0-alpha0.3)

use quicksilver::{
    geom::Circle,
    graphics::{Color, Graphics},
    lifecycle::{run, Event, EventStream, Settings, Window},
    Result,
};

fn main() {
    run(
        Settings {
            title: "Dots",
            resizable: true,
            ..Settings::default()
        },
        app,
    );
}

async fn app(window: Window, mut gfx: Graphics, mut events: EventStream) -> Result<()> {
    loop {
        // Clear the screen to a blank, white color
        gfx.clear(Color::WHITE);
        for x in 0..200 {
            for y in 0..200 {
                gfx.fill_circle(&Circle::new((x * 50, y * 50), 10), Color::RED);
            }
        }
        // Send the data to be drawn
        gfx.present(&window)?;

        while let Some(e) = events.next_event().await {
            match e {
                Event::Resized(_) => {
                    gfx.fit_to_window(&window);
                }
                _ => (),
            }
        }
    }
}

[ryanisaacg]

This is closely related to #594 and the 'window resize example' mentioned in #552. It's something that will be more convenient and better documented in a future release, and you're right that there's an ergonomic point there for now.

[ryanisaacg]

Let me know if ResizeStrategy doesn't solve this issue, in which case we can re-open it.

[vorner]

Thanks, I'll try to play with it a little. I suspect I might be missing a variant of the enum that does what I want (I just want to use the whole window without resizing the content and without any care of aspect ration ‒ something like if I resize a browser window, the page gets smaller or larger area to render in but the font stays the same), but I'll first check if one of the existing can be actually used for that.

[ryanisaacg]

Oh, I misinterpreted the issue text. You can listen for the resize event, and use the following code (or something like it):

gfx.set_projection(Transform:orthographic(Rectangle::new_sized(ev.size())));

[vorner]

As I said, I eventually figured something out (I also have scrolling, so I also set the top-left corner of the rectangle, resp the middlepoint).

My point about the issue was, figuring this out wasn't really easy and it took me some time (and getting a different-sized screen) to figure out I actually should. So I wonder if such use case should be also part of the ResizeStrategy enum, or if there should be some example with the view with this kind of resizing + scrolling or something (I'm fine writing it).