How Might Integer Coordinates Work If At All

[zicklag]

I'm not 100% ready to dig super deep into this, but I wanted to open the discussion to get any extra context that might help if/when I get into this soon.

For Bevy Retro, the library that I want to use RAUI with, because it is focused on delivering low-resolution, pixel-perfect games, it uses integers for all of it's screen coordinates, which are relative to the low-resolution framebuffer that the scene is rendered to. I would like to be able to use i32 coordinates for the UI like I do for the rest of the game, if possible, but I don't know exactly how that would work with RAUI which by default uses f32's for all of the coords. I noticed that there is a Salar type that is either f32 or f64, but it's obviously a very different thing to switch to i32 from there because of the decimal point.

Do you see any way that it would make sense to use integer coords in RAUI or does it just make more sense for my backend RAUI renderer to round all of the coordinates before rendering or something like that?

When it comes to things like animations and lerping, it might make more sense to use floats anyway, so maybe it is better just to use floats for the UI anyway.

Honestly I'm not 100% sure its the best idea to use integer coordinates for Bevy Retro either, but I had a "feeling" like rounding floats would get me in trouble one day for some reason. I guess that's slightly off topic, but if you have any thoughts on whether or not that is even a good idea I'd love to hear it @PsichiX . 😁

[PsichiX]

oh actually that you mention it, i had similar problems with few pixel based demos, i've played with the idea of integer coords and abandoned it because there were problems on the layouting side, precision related bc of multiplying and dividing big and small numbers, a lot of mess iirc (integer idea was bad from the get go but i wanted to test it anyway to confirm that it is problematic).
then i've played with rounding scalar numbers and i've found out that if you leave all virtual-space coords calculations as it does now, and round coords only on the renderer side then all values are prefectly aligned with pixels - i've working example in oxygengine, i'm even working with it at this very moment, i'm not sure i've published helper type yet but what i essentially do is i get these type of rounding methods:

#[derive(Ignite, Debug, Copy, Clone, PartialEq, Eq, Serialize, Deserialize)]
pub enum UserInterfaceApproxRectValues {
    Exact,
    Round,
    RoundDown,
    RoundUp,
    RoundInside,
    RoundOutside,
}

impl Default for UserInterfaceApproxRectValues {
    fn default() -> Self {
        Self::Exact
    }
}

impl UserInterfaceApproxRectValues {
    pub fn calculate(self, rect: Rect) -> Rect {
        match self {
            Self::Exact => rect,
            Self::Round => Rect {
                x: rect.x.round(),
                y: rect.y.round(),
                w: rect.w.round(),
                h: rect.h.round(),
            },
            Self::RoundDown => Rect {
                x: rect.x.floor(),
                y: rect.y.floor(),
                w: rect.w.floor(),
                h: rect.h.floor(),
            },
            Self::RoundUp => Rect {
                x: rect.x.ceil(),
                y: rect.y.ceil(),
                w: rect.w.ceil(),
                h: rect.h.ceil(),
            },
            Self::RoundInside => Rect {
                x: rect.x.ceil(),
                y: rect.y.ceil(),
                w: rect.w.floor(),
                h: rect.h.floor(),
            },
            Self::RoundOutside => Rect {
                x: rect.x.floor(),
                y: rect.y.floor(),
                w: rect.w.ceil(),
                h: rect.h.ceil(),
            },
        }
    }
}

then in renderer i grab virtual-space rects from processed layout, convert them from virtual-space to ui-space rects using coords mapping and that ui-space rect i put to this approx.calculate(ui_rect) and result is pixel perfect coords. this type contains different kinds of rounding behaviours but i usually just go with Round variant :D

(this code uses Rect from oxygengine, not from RAUI, because at the time approx.calculate(rect) is called i operate on engine rects, but you can change these to RAUI rects. maybe this approximation type should be added to RAUI as a helper tool?)

---

• virtual-space - everything that is calculated in RAUI coords space
• ui-space - game (usually screen) coords space

[zicklag]

OK, cool. Thanks for the insight.

I'll have to try moving Bevy Retro to using floats for it's game object too to see how that works out.

maybe this approximation type should be added to RAUI as a helper tool?

It seems nifty, but maybe like most people would just .round() so I'm not sure how much it helps. 🤷‍♂️ I wouldn't know. :)

[PsichiX]

i'm not sure if moving bevy-retro entirely to scalars would be good idea either, i think we could discuss it on your repository board tomorrow, i have few things i can share with you about transformations in both scalar and integer coords, different transformations might work better with integers, other ones with scalars

[zicklag]

Oh, sweet! 😃