Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines

Thank you very much for the feedback!
- I can't seem to reproduce this issue in my tests. Are there any exact steps that need to be done (besides the enabling the fill shape option and double clicking) in order for it to crash?

- Unfortunately this seems to be an issue with Godot's `Window` node. In order for popup windows to close when users click outside of them, the `exclusive` flag needs to be disabled and `popup_window` needs to be enabled. But this has the side effect of the issue you described. I'm not sure if this intentional behavior from Godot's part and I might report it to them, but for now we either have to choose whether we want popup windows not to close when clicking outside and fix the issue, or leave them as is.

- Good point, they have been increased from 4 to 16 now. The change is not visible but the draggable area has indeed been increased. We could increase it more if that's not enough.

- Raw color is meant to be used for HDR, which Pixelorama does not currently support. Values higher than 1 are for HDR, which is why they have no effect. We're keeping raw mode mostly because it may be useful to choose color values that are in the range of 0-1.

- Noting it for the next version, as 1.0 is currently in release candidate and don't want to accidentally break anything 😅.

- That is a nice idea, although my main concern is that the number buttons (like 1, 2, 3, etc) could also be used for more things, such as quickly selecting frames, or even swatches from the palette. We should eventually decide which of these functionalities are more important so we can map the number buttons to it, and the rest could be combinations with other keys such as `Control` and `Shift`.

- This was a recent change, the currently selected user interface element becomes unfocused when the mouse cursor enters the canvas. This was done in order to fix issues with the keyboard arrow keys affecting the user interface when they should be affecting the canvas (either moving it or moving the active selection if there is one and a selection tool is selected). I could look into making some UI elements be exceptions to this behavior.

- This is a limitation of the layers are being blended in 1.0, which is also responsible for previewing their movement when using the move tool. Eventually I want to experiment with another way of blending layers, so this issue could be fixed then.

hello, thanks for the responses

1. sorry, i was mistaken. the program doesn't crash - it freezes, particularly on larger drawings. it does unfreeze if you wait long enough, so just a cpu/memory limitation/problem or somethin.

3. 16 seems to be enough

8. i see. i'd also like to add a related problem i've noticed: the preview does not update until you move far enough. it seems to snap at a certain number of pixels, and it scales the bigger the canvas is.