itch.io

This may be due to the update from pre 1.0. The layout system got changed and 1.0+ layouts are not compatible with pre-1.0. Try going to C:\Users\[USERNAME]\AppData\Roaming\Pixelorama\ and deleting the layouts folder, and launch Pixelorama again.

Hmm that's weird. Did this break after an update or are you a new user? Can you try going to the Window menu, Layouts and select another layout to see if it works? Alternatively, try deleting any extensions you may have, close and launch Pixelorama again, and download the extensions again,

Hello! Yeah this may be a multi-monitor issue. You can try clearing Pixelorama's settings to see if that fixes the issue for you. You can do that by deleting the "config.ini" file found in C:\Users\[USERNAME]\AppData\Roaming\Pixelorama\ if you are on Windows, ~/.local/share/Pixelorama/ if you are on Linux, or /Users/[USERNAME]/Library/Application Support/Pixelorama/ if you are on macOS.

Hello! You can export your project as multiple png images, one for every frame, or you can export all of your frames into a single spritesheet, which you can later import to Unity. More info about exporting here: https://www.oramainteractive.com/Pixelorama-Docs/user_manual/save_and_export#exp...

The difference between itch and Steam is quite significant. Right now, the daily average of sales on Steam is 5 (although these last few days it has gotten lower, 2-4 per day), while on itch we get 0-1 donations per day, with some rare days getting 2 donations. During April, 22 people have donated on itch, which resulted in $175 gross revenue (itch lets people choose how much money they want to donate, so some people give less than the default value which is $9.99, and some give even more). On Steam, Pixelorama has sold 265 copies during August, resulting in $2400 gross revenue. Of course we will get less than that due to the 30% cut that Steam takes, and August was a good month because it was just after the Steam release, so from now on the amount of copies sold will become less and less (unless Pixelorama gains more popularity).

If Steam had a pay what you want model like itch has, we would probably see a lot less sales, so it's not very fair to compare the two, as people can get Pixelorama from itch either completely free, or by donating a small amount, but in Steam they have no choice but to pay. But in general Steam has more people, and it has tools like the discovery queue which can bring more traffic to your Steam page (once you have reached 10+ reviews), and that helps. Our Steam page currently has double the impressions than our itch.io page in the last 7 days, but weirdly enough it has less actual visits than our itch.io page. Could be that the two platforms are counting visits differently, Steam only counts unique visits, but I'm unsure how itch counts page visits.

If you want to publish an app on Steam, go for it, you will most likely see more revenue than on itch.io. Just keep in mind that you have to pay a $100 fee for every Steam page you publish, but you will get that back once you reach $1000 in revenue. And it might be a good idea to have a period where your Steam page is public and you lead people there to wishlist it, before actually launching it.

Thank you for the reply! Right now it seems that there is no way to merge the two layers and have them be the same as A, but we will keep this in mind and change it in a future version.

As a temporary workaround, you can go to the View menu and disable "Display Layer Effects". This will disable the previewing of layer effects in the canvas, but they will still be applied in the exported images. Layer effects are currently hindering performance, we're currently considering ways on how to improve that.

Hello, thank you for the feedback!
- We could look into creating a custom file browser that has thumbnails, but for now you can enable native file dialogs from the Edit menu, Prefrences, under the Interface category. This option will use your operating system's file browser.
- This will be fixed in the next update!
- This is an interesting observation. Right now, when merging two layers together, the layer above keeps its opacity, and the layer below also keeps its own opacity, which makes the top layer appear to have less opacity than it used to. What would be the correct behavior instead?

The rest of the ideas all sound useful and we're noting them for the future. For .gif importing, it's technically already possible if you have FFMPEG installed, and you put its path in the Preferences, under the Startup category, but eventually we'd like to add .gif importing without having to rely to FFMPEG.

Thank you very much for the feedback!
- Do you have any example projects that we can use to replicate the performance issues? Or at least can you let us know how many layers and frames your project has? Posting your device's specifications (such as the operating system, CPU, GPU, RAM etc) would also be helpful!
- Gaussian blur is coming in the next update!
- That is a good idea, noted!

Hello! I think I may have fixed the issue. The fix will be available in the next version (1.0.3), but if you want you can download the nightly version to confirm whether it has indeed been fixed. https://nightly.link/Orama-Interactive/Pixelorama/workflows/dev-desktop-builds/m...

Hello, thank you so much for reporting the issue! I tested a project with 256 frames, and there is indeed a significant performance decrease in v1.0 compared to v0.11 when changing any kind of setting in the export dialog (which includes the amount of rows/columns in a spritesheet). This is due to the new layer blending system that supports blending modes, which did not exist in v0.11. However, it is possible to make this faster by simply caching the blended frames once when the export dialog appears, instead of re-blending them every time something changes. I am currently working on this and it should be available in the next version, so you shouldn't experience any slowness when changing the number of rows/columns.

As for the 6 rows turning to 12 issue, I cannot seem to replicate it. If you have any exact reproduction steps, it would be very helpful!

Hello! There's no blur tool at the moment. As for themes, the only way to achieve this would be by creating an extension with Godot that adds a custom theme.

Hello, this may be a performance issue caused by the new group blending. If you have any group layers, try setting their blend mode to "Passthrough".

Thanks for the bug report! Unfortunately we don't own a Mac to test it, but we'll keep the issue in mind in case we find a fix.

Thanks for the feedback!
- This is a nice idea, noted.
- Are you using a custom shortcut profile? If so, it may have been broken if you have updated from 0.x to 1.x. Try deleting it from the Preferences and creating an new one.
- This is now possible in today's update!

Hello, thank you! Yeah we plan on adding it eventually!

Hello! You can use the bucket tool and change its mode to "similar color" in the tool options. And thank you for the bug report, it will be fixed in the next version!

Hello, thanks for the bug report! The palettes should be at `AppData/Roaming/pixelorama/Palettes/`. It seems that, for some reason, Pixelorama is not able to save palettes in your computer. Do you have an antivirus installed that is perhaps preventing Pixelorama from saving files to AppData?

Also, can you check if the folder inside AppData/Roaming starts with a capital letter? It should be "pixelorama" and not "Pixelorama" as it used to be in versions 0.x, but Windows is not case-sensitive and can't tell the difference,.

Hello! You can use Control + the left and right keys to move between frames.

Thank you both so much for your kind words! They really make our day!

Thank you so much!!

Hello! This may be a problem with your device not being able to run Pixelorama. If it's easy, can you post your computer's specs? Like its operating system, CPU and GPU.

Hello, thank you for reporting! This is most likely an issue with the macOS version of Chrome and SharedArrayBuffer, which Pixelorama 1.0 requires. While there's not much we can do right now, in a future version this will not be required anymore and Pixelorama should run fine again. For now, it's best to download the desktop version.

Thank you so much for the kind words and for recommending Pixelorama! We're glad that you have been using it for so long!

Hello, thank you for the bug reports!
- Is the bottom layer locked or invisible?
- Are you moving the mouse cursor into the canvas? Doing so results in input fields to lose focus, otherwise that shouldn't happen. Do you have exact steps that result in them losing focus?
- This is weird, we will investigate it.

Hello, thank you! Technically yes, but the user interface is not optimized to be used on small touch screens, like phones. It might work well on tablets though.

Pixelorama has certainly come a long way!

That is awesome to hear, good luck with your game!

Thanks for the bug reports! The first bug seems unrelated to the move tool, the opacity changes no matter what tool is selected the moment the user selects multiple layers. This bug has been fixed and the fix will be included in version 1.0.1!

As for the second bug, it's a known issue and we're still trying to solve it.

That sounds like a permission issue. Are you using the Flatpak version? You may need to confirm that Pixelorama has permission to access the file system. An easy way to configure Flatpak permissions is with the Flatseal application.

Hello! Can you provide more details? Do any errors appear when you try to save projects? As for your palettes, did you update from v0.11.4 to v1.0? If so, the palettes from previous versions no longer work as we wrote on the v1.0 devlog post. If you got them from somewhere else, you need to re-import them, otherwise you can export the palettes as images from v0.11.4 and import these images into v1.0.

Thanks!

Thank you!! 💚

Thank you so much!

Thank you so much, glad you like it!

Thank you so much, we really appreciate your support!

Thank you so much!

Hello, thank you so much for the feedback! Due to the way palettes work, right now they can only work in the desktop versions, but it should indeed be possible to make them work with the web version also. We will look into it!

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, thank you for the feedback! Are you referring to the draw tool's brush size? Due to the nature of pixels, in even sizes, it's not possible to have centered pixels, so a 2x2 brush size will always be drawn when the mouse cursor is one of its four corners.