Fandom

Pokémon Essentials Wiki

Map tiles with >0 priority are offset slightly at high zoom factors

  • ERR1
    ERR2
    Most taller objects in the game keep having a line cut through them near their tops. I checked the tilesets and also checked the tileset image files and they didn't have these lines.

    Also, the two desks at the back of the lab, the spaces in front of the drawers aren't passable.

    Nothing has been edited, I've been playtesting as soon as I loaded the program.

      Loading editor
    • I have the same problem when I change the resoltution ingame. Don't know how to fix :c

        Loading editor
    • This is a known bug. It occurs when playing at a high zoom factor. There is no fix available.

        Loading editor
    • Since this is such an obnoxious issue, I spent some time digging through the code. It looks like there's some rounding issues with forcing the window into fullscreen that cause tiles of different priorities to be rendered at about 0.5 pixels too high and too left. I believe this has to do with the fact that the game renders tiles with priority 0 separately than tiles on higher priorities.

      Since "no fix" isn't really very helpful, I've come up with a workaround:

      Change the priority flag on all non-ground tiles to be at least 1. So buildings, fences, signs, etc. should be at least on priority 1. If they don't span multiple tiles or don't require higher priority for any reason, it won't matter. Essentially, make sure groups of tiles (i.e. buildings) are either ALL on priority 0 or ALL on priority 1 or above.

        Loading editor
    • You just have to look at the screenshots to realise that this problem is not "priority tiles are shifted left and up by a pixel". The pixels within priority tiles still line up perfectly with everything else, showing that nothing has been shifted - their sprites' coordinates are fine.

      The actual problem is that each priority tile "bulges" out by a single pixel in the left and up directions, and is cut off one pixel short in the right and down directions. The bulge takes its graphics from the leftmost and uppermost strips of pixels from the tile being drawn, not any adjacent tiles, meaning it doesn't bleed over into other tiles. This at least implies that the src_rect of that priority tile's sprite is working properly.

      Note that this problem only occurs at non-integer screen zooms greater than 1.0. Screen size XL (screen zoom of 2.0) looks perfectly fine, but screen size L (1.5) and likely full-screen mode (depending on the size of your monitor) display this problem. Note that the bulges and cut-offs are a single pixel wide regardless of the screen zoom; I tested a zoom of 5.5, and they were still only a single pixel thick.

      So the priority tile's coordinates are fine, and its src_rect is also fine. This (as far as I'm aware) only leaves the actual rendering of the sprites onto the screen, which isn't something that's in the scripts. I can only guess that this rendering thing has rounding errors somewhere. Any rounding errors caused by the zoom being 0.5 disappear, probably because they're so small.

      This problem actually applies to ALL sprites, not just priority tiles. You can observe this in the Professor's intro, with Oak's and Marill's images also being affected (they have pixels which touch the edges of their sprites). It also applies to priority 0 tiles, but they're all drawn on a single sprite ("layer0") that is larger than the screen, so you can't see its edges to witness this problem.

      As this problem is a rendering issue, which isn't part of the scripts (I don't know where it actually is, maybe RGSS itself?), I can't access it to fix it. Odds are it's not a difficult thing to do, though.

      In the meantime, I suppose I'll just remove the options which result in non-integer screen zooms. The best thing we can do right now is to simply avoid situations that cause this problem.

        Loading editor
    • To be honest, if removing the non-integer zoom factors means losing fullscreen, I'd rather keep them and just use my workaround to fix this error. That seems to be an adequate fix for the problem, from my experience.

        Loading editor
    • It doesn't. It just means that the non-black part of full screen mode will be a bit smaller (if you experienced this problem in full screen mode). Full screen mode's zoom factor is calculated based on your monitor's resolution, and isn't a fixed value - it's simply the largest it can be while still fitting the whole game on-screen - I'll just make it avoid values that aren't integers.

        Loading editor
    • Gotcha, sounds good, thanks.

        Loading editor
    • A Fandom user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.