-
-
Notifications
You must be signed in to change notification settings - Fork 155
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Potential inset orientation issue. #865
Comments
The only nice thing I can say about how it currently works is that it matches how nearly all paint / image editing programs work, as well as tile editing programs such as Tiled. So there is still a sort of consistency here even thought it's overall inconsistent with how Nu does other spaces. |
CC'ing mapeditor/tiled#249 (comment) since this is the issue that once again brought the subject to the forefront of my mind. |
Maybe we just accept that this will be a problem until the end of time? 2D authoring programs will always have their Y's inverted compared to engine representations. Included in that space are also tile editing programs like Tiled. This inconsistent frame representation is pretty much accepted as-is in the 3D authoring and engine space. However, it's a real problem because even to this day, there is a minor enhancement I'd like to add to Omni Blade's map generation code that I just can't wrap my head around due to this aspect causing a little too much cognitive load for me to carry comfortably - and thus remains unimplemented. |
The best way I can describe this phenomenon is that inset is currently in 'authoring space' or 'paint program space'. In terms of the engine itself, it seems weird and inconsistent. But in terms of using it in tandem with image authoring, it can be a lot more intuitive. We still don't have enough information about which way to go to take action on this issue, so it remains unclosed. |
Currently, it appears that 2D inset values reference texels with top-left as origin whereas it would make more sense in many cases (and be more consistent with other systems) with bottom-left as origin. Let's consider modifying the sprite rendering pipeline to change this.
The text was updated successfully, but these errors were encountered: