Scale can't be less than 1.0

[SolsticeSpectrum]

Even tho it's a float, setting it to less than 1.0 like 0.5 results in an error

Also scale 1 is now bigger than before, here's a comparassion

[crgimenes]

I believe I fixed the scaling issue. The problem was converting float to integer.

As for the size, I didn't see any difference on MacOS. Unfortunately, I don't have other operating systems with a graphical environment to test. However, I printed the size of the sprites. The cat has 32x32 px by default, scale 1, 64x64 scale 2, and 16x16 scale 0.6 (adorable)

[SolsticeSpectrum]

@crgimenes umm I think having scale as float if it's intented to be converted to int anyway is redundant, unless there is a plan to have fractional values in the future. (it works as intended with older ebiten)

The fractional values cause this now (caused ebiten)

scale 1 is still larger than several commits ago (caused by ebiten) However i believe the problem is that it's getting upscaled for some reason which it shouldn't do for scale 1

[SolsticeSpectrum]

This is the commit that breaks scale 1 https://github.com/crgimenes/neko/commit/90afd38d45fdbdad9e2e68f7058139ccfb2df6b4 Commit before that works as expected

EDIT 1: After commenting ebiten.SetWindowFloating(true), I also found out that it's not caused by that line, nor var loaded so it is probably caused by one of the libraries

EDIT 2: Okay I just isolated the issue switching this back to 2.6.7 fixes the issue

[SolsticeSpectrum]

I opened an issue on ebiten https://github.com/hajimehoshi/ebiten/issues/2951

EDIT: For the time being, I commented these

//X11ClassName:      "Neko",
//X11InstanceName:   "Neko",

so I could downgrade ebiten and I use title and WM_NAME to target the window

// i3wm
for_window [title="Neko"] border none
for_window [title="Neko"] sticky enable

// picom
shadow-exclude = [
    "name = 'Neko'"
];

Fractional values are no longer problematic with ebiten downgrade

[SolsticeSpectrum]

I believe ebiten 2.7.0 has some sort of minimum set for the window size which causes this behavior

[crgimenes]

I cannot investigate now, but I don't see a problem with temporarily downgrading the Ebitengine. I created a new version with this change.

[SolsticeSpectrum]

I managed to pinpoint the specific commit of ebitengine which causes this https://github.com/hajimehoshi/ebiten/commit/5774cf808f82903148eaf9bcae3beba880978df7

The reason why you @crgimenes don't experience any issue is because this commit essentially doesn't change anything for mac It only sets whatever is the default on mac for other platforms but it seems like using mac defaults might not be a good idea

[crgimenes]

@DarkReaper231 I just saw that apparently the bug has been resolved, and we should soon have a new version of Ebitengine (https://github.com/hajimehoshi/ebiten/issues/2951#issuecomment-2041082753)

I'll close this issue for now. Thank you for being so helpful!

@hajimehoshi Thanks to you for the excellent game engine and the improvement in Neko.

I'm happy that little Neko, a toy project made out of pure nostalgia and with no refinement, was helpful in any way, even if it was to break things (typical of cats 😀)

[SolsticeSpectrum]

@crgimenes you can use the commit hash d6f7b50387d2488c84ee43c3e8c181b78a2f419e to have the fix in neko until 2.7.1 rolls out Just do go get github.com/hajimehoshi/ebiten/v2@3136de4958eb355702c93c8e5d5ce66d39c7e0f7

[crgimenes]

@crgimenes you can use the commit hash d6f7b50387d2488c84ee43c3e8c181b78a2f419e to have the fix in neko until 2.7.1 rolls out Just do go get github.com/hajimehoshi/ebiten/v2@3136de4958eb355702c93c8e5d5ce66d39c7e0f7

Done!

[hajimehoshi]

You can reenable X11ClassName and X11InstanceName, right?

[crgimenes]

You can reenable X11ClassName and X11InstanceName, right?

Jeez! I completely forgot about that! Done!