This is a a personal preference, but I really like to be able to draw with the left mouse button and pick up a color with the right button (as most pixel editors allow you to do).

I like how you can choose tools for each button, but if I choose to draw with left and pick up with right, it only picks the background color and I draw with the foreground color. That is very annoying.

A solution would be if you allow the user to click the color picker a second time, it turns to the other color (from red to blue in this case) indicating that you pick up the foreground color instead of the background color.

Alternatively, you could also allow to switch to a mode where you only have one color instead of a foreground and background color.

Stretch goal:
Pixelorama is a tool for game developers. Many game developers are using auto tiles for their levels to maintain their sanity.
Here is a 47 tile setup:

And a 16 tile setup:

They are fairly easy to use(in Godot and GMS2 at least). But the real challenge is in making them.

Pixelorama can have a simple option to enable a 'reference background/template':
47 tiles:

16 tiles(Please dont mind the numbers at corners, this is the only image I could find):

There should be an option to select the size of individual tile(16x16, 32x32 etc.)
Again, a stretch goal. Would be nice to have, and very useful too.

Hello I've been making a "simple" pixel painting app in Godot 3.1.1-Stable over the past 3 days (found here->)
https://github.com/Mainman002/Goodle

I didn't search too far into how I could contact you so I just came here (sorry for opening a conversation issue Lol)

currently my version is faking more features then actually editing images directly like yours does. I just saw your redit post and was blown away by how you managed to edit pictures like that. Anyway I doubt that you'd be able to use any of my code but feel free to check it out, maybe you might get some inspiration on a few things ;)

I'm currently looking for ways to increase the performance of my simple pixel editor with hopes of having a canvas around 32px-64px and so far faking things with each pixel being an object just isn't gonna work XD

if it's alright with you could I try and learn from your program and just grab the basic canvas draw / maybe import image optimizations? I'll try to stay away from your other features as I only want to optimize what I already have vs changing it completely

I think #41 added some new nodes in the scripts but forgot to commit the actual nodes. These nodes don't exist:

 	add_palette_button = find_node_by_name(root, "AddPalette")
	remove_palette_button = find_node_by_name(root, "RemovePalette")
	palette_option_button = find_node_by_name(root, "PaletteOptionButton")
	edit_palette_button = find_node_by_name(root, "EditPalette")
	palette_container = find_node_by_name(root, "PaletteContainer")

Hello,

i notified that the Pixelorama eats 2 cpu cores while in idle completely.

I have a laptop with Intel Core i7 7600U (2 Cores - 4 Threads) running Fedora 31.
Pixelorama is permanently at 50-60% in htop, for comparison the godot editor at only 5%.

Save now always remembers the last saved file. This means that if you save a file and then open another one and try to save, the suggested filename and location will be the previously saved file.
Same thing with export and save as.

As of 02f5bd0 (and before this), running Pixelorama from Godot generates this error:

ERROR: recognize: res://default_env.tres:1 - Parse Error:
   At: scene/resources/resource_format_text.cpp:1186

This is because default_env.tres is an invalid file.

An example of what'd be valid file contents:

[gd_resource type="Environment" load_steps=2 format=2]

[sub_resource type="ProceduralSky" id=1]

[resource]
background_mode = 2
background_sky = SubResource( 1 )

As this appears only to be meaningful to 3D worldspaces, this has no visual impact on Pixelorama.

Hi,
Selecting some part of a drawing and moving it outside canvas, crops the image.
Other pixel art tools don't show this behaviour, so i think it would be nice not to cropping the image when outside canvas.
Perhaps the image itself should be bigger (or grow) and the viewport of the selected resolution.

If this is wanted, and i get some guidelines of where to look, i could give this change a try.

Not really a bug more like a feature request. The middle mouse button works alright but can be tiring when using a mouse. I find in other painting apps that holding the Spacebar to pan can help reduce mouse clicking fatigue.

(this being said idk if the Spacebar is being used / will be used in other features, but it would be nice to have alternative keymaps for panning)

This would really make this worthwhile using over other tools, as it would allow us to create and edit sprites directly inside godot without leaving the ide

At the moment when you create another image it doesn't ask to confirm and if I have something not saved in background all the work will be lost.
I suggest to open a yes or no dialog to confirm the action, or implement multiple tabs, one for each canvas

The color picker that is currently in Godot doesn't have HSL color selection.
I suggest creating a custom color picker that includes this feature.
As a bonus it could maybe bypass #10 but that is not guaranteed.

This is how color picker looks in Pyxel Edit as a reference (the shading part on the right could be an inspiration for the future 😄):

Is it possible to distribute this as a Flatpak?

Hi, love the tool. I would like to see a few things added/changed/updated:

• Add to the sliders (brush size, onion skin) checkboxes for 1,2,3, and 4. Anything bigger could be added using the slider.
• On adding a new frame, retain the zoom factor instead of zooming out.
• Turn the pencil, eraser, etc buttons into graphical icons and put tooltips over them.
• Default FPS should be 6 or 12 instead of 1 IMO. I do like the fact you can draw while it's animating.
• Don't know if there is a hotkey for moving to the frame and then selecting it automatically for editing, rather than how it is now when using the arrow keys and then hitting enter to edit it.
• Somewhere on top of the selected frame, have three small button overlay popups - delete frame key, clone frame and then insert a new empty frame.

Hi,

it would be nice when everybody could see what is planed for what release aka please use Milestones.

You seam to work on multiple things at the same time, and the actual released version of Pixelorama is 0.5, but you already mentioned that something is planed for a version 0.7 in another issue.

So, (rhetorical question) how long is the way to 0.7 or 1.0?

EDIT: metaphorical question -> rhetorical question

It's not very comfortable to use Ctrl+* to shortcut in MacOS. It would be better if Pixelorama will support Cmd+*
I'de like to fix it in this week

This would be a pretty straightforward fix.

The offending line: $QuitDialog.popup_centered() (Main.gd, line 202 as of 1f2d840) (https://github.com/Orama-Interactive/Pixelorama/blob/master/Scripts/Main.gd#L202)

Fixed, per Godot's recommendation: $QuitDialog.call_deferred ("popup_centered")

Godot 3.1.2 flags it up as an error, despite the program still running, and it should not be assumed that it'd work as-is on future versions (or indeed, all platforms).

Hi!
I've noticed a blending issue regrading the circle blended brush. It is related to this godot issue: godotengine/godot#31124 but is probably not going to be solved in godot.
The following image shows the issue:

At the right, you can see the result of using the brush as is now. Transparent edges become dark if they are blended over a transparent backgraound. I implemented a custom function in gdscript to use instead of blend_rect, and with it we can get the result at the left, which in my opinion is way better (although slower). I also tried fixing the issue in godot in a custom build, and gives similar result than the one of the left, but as i said, i think this won't be fixed in godot because of performance (someone explained it to me on irc).

So i think the possible solutions are:

• Using custom blending function in GDScript (I can PR the one i made)
• Using custom godot engine build with the fix (a hassle, but will perform better i think)
• Wait for it to be fixed in godot.

Add russian localization

Hello! I would like to recommend rather simple UX improvement, namely I recommend moving color preview down, placing it in between RGBA sliders and color picker itself.

How would this change be beneficial?

1. In vast majority of software that utilizes color pickers there is nothing else above (or at least nothing interactive that might require user attention) color palette. As the result, a lot of people might instinctively ignore this part of the window on their first contact with Pixelorama.

2. By placing color preview right between color picker and color RGBA sliders, sliders become easier to use as user can keep an eye on both sliders and current color preview at the same time without need to "jump" over large space that color picker creates.

3. As color preview is placed in a spot that is easy to notice even without having direct attention on it, user will be able to notice undesired transparency settings "on the occasion" of adjusting color hues.

Concept preview:

Something that would be interesting to have would be rulers and guides. GIMP has them, even Godot's editor has them (see gif below).

Since Godot has them, does that mean there is an easy way to make something like this in Pixelorama? I tried searching through the Control nodes but I couldn't find anything related to that. Any ideas?

Right now the color picker exist only as a separated tool, the request is to be and a tool that leaves inside the Draw tools, Pencil and Bucket and pick colors by holding down the Alt key and pressing the left mouse button for the left color or the right mouse button for the right color.
This will improve the workflow tremendously and possible this is the reason that almost all the drawing apps have something similar.

Right now it's possible to move selected pixels with a shift button but it would be nice to be able to copy the selection with a ctrl button too.

With a pencil on a left mouse button and a color picker on the right it would be nice to be able to quickly pick a color for a pencil with the picker.
My proposal is to bind one of the keyboard buttons to switch colors while it's being held and to switch them back when released. I think that with a current "switch colors" functionality it could be an easy feature to implement.
I also propose that it could be ctrl button, because shift in this case shows a line guide and alt button is in the most of Linux distributions used for window manipulation.

It's common to keep all the frames inside a single file, this means that standing frames, walk frames etc are going to be in the same file.
The problem is that right now there is only a single button for setting all the frames to be played in loop mode or ping-pong.
So the solution is to be able to organize the animations.
A fine example of this can be seen in aseprite : https://www.aseprite.org/docs/loop/

Since Pixelorama is built using Godot, it would be relatively (compared to being built in some other framework) easy to add options to export Godot resource or scene files, which would greatly streamline the process of adding sprites to a project.

Hi!

I saw that someone ( probably @Schweini07 ) already registered the "pixelorama" name in the snap store. This is great!
I have already a working snap version of pixelorama 0.6 and I would like to share it with you so you don't have to waste your time reinventing the wheel.
HERE there is the compilable base ready to be snapped with snapcraft .
To test the snap in a linux distro you only have to unzip the file , cd in it and launch snapcraft and sudo snap install pixelorama_0.6_amd64.snap --dangerous.
As you can see the ziped file contain only a "files" directory (containing the same files in your [Linux 64-bit].zip download) and a snap directory containing the snapcraft.yaml file.

I hope this will help you share your great app.

Thank you for your great work.
Regards,
AC

Can i request feature for reference image like in krita ?

Is it just me or is the transparent part of the blended brush being drawn as the same solid colour as the rest of the brush?

Can you allow to draw anywhere in Tile View mode, not just the canvas.
Currently, I can only draw on canvas which makes it a little confusing.

Allow to draw outside the canvas, on those 8 surrounding blocks

Currently frames change in the drawing area when you play an animation so you can draw in motion. It is not possible to select a single frame and edit it while playing the animation in a preview to see how it's changes affect the animation.

Implement rotsprite for sprite rotation
See https://forums.sonicretro.org/index.php?threads/sprite-rotation-utility.8848/ for implementation details

Pixelorama remembers exported values and this is great, but it remembers and the last exported name.
I think for the name it will be better if the name of the prohect (.pxo) is used.

Hello again! I would like to recommend small QoL improvement that is automatic alpha overwrite. How would it work? Whenever user is selecting a color using color picker palette (not Color Picker from Utility Tools) Pixelorama would check if currency Alpha channels equals 0 (full transparency) and overwrite this value with 1 (no transparency) whenever a color is picked.

Please note, that this behavior would only be expected to happen while Alpha equals exactly 0. Overwrite should not be triggered on any alpha values higher than 0, as it might (and most likely would) annoy people who are aware of their transparency settings that are most likely intentional.

How would this change be beneficial?

1. It's very unlikely that user is trying to use color picker on full transparency on purpose. In most cases this situation will only occur when user was using transparent pencil to remove some existing pixels or when user accidentally used Color Picker Tool on transparent pixel before prior to accessing Color Picker. Both cases imply that Color Picker has been opened in order to replace already transparent "color" with non- or less-transparent alternative.

2. In case when transparent color was picked on accident (either with Color Picker Tool or as result of playing around with sliders), automatic transparency overwrite will reduce annoyance and time that user would have to spend at trying to figure out whats wrong, especially in case of beginners.

3. It would be overall Quality of Life improvement even for already experienced users, as it is still one action less to take.

How would this change be harmful?
I can't think of any situation in which this system could backfire in any way. If user is intending to keep his transparency settings at absolute minimum, there is no reason to even touch color picker in the first place, as absolute transparency is color-less.

Is suggest adding a palette to one of the side panels. Currently Godot color picker has one but it's not really ideal for efficient drawing.

It should be possible to add new colors, edit existing colors, copy and move them on the palette. Palette could be stored in the .pxo with the image. Exporting and importing to image formats could be also a nice feature.

How it looks in Pyxel Edit but it is very similar in other editors too:

I've noticed a very weird bug that leads to a crush when using the fill bucket tool.
Steps to reproduce:

1. Select the bucket tool
2. Change the selected color
3. Add it to the preset colors (the palette)
4. Change the color again
5. Click on the canvas to fill
6. The pixels get filled as normal, but Pixelorama crashes.

I haven't discovered why this happens, and it doesn't seem like a problem with my code, because the colors get filled, which means that it's not the flood fill algorithm's fault. This also means that the frame gets drawn, but the next one leads to a crush. I'm starting to think whether it's a problem with Godot and the Color Picker itself, but if any of you has any other ideas, let me know!

As of right now, the program lacks a variety of selection tools, such as selection by color, select similar area (smart selection), freehand selection, ellipse selection, lasso etc.

But even for the rectangular selection, issues are visible. For example you cannot add another rectangle or remove an area within your already selected area. Other programs let you use rectangle selection, then press shift and add another rectangle to your selection. Or press control and remove a rectangle from your selection. Something similar should be implemented and be used for future selection tools too, maybe with different keys (instead of shift and control).

Furthermore, it would be nice to have some tool options for the selection. For example a clear "copy" and "cut" or "move selection" and "move content" button that you can press instead of using the shortcuts. Another useful addition would be a "copy visible" button, which practically copies not only the current layer's selection but every other visible pixel from the rest of the layers, above or under the selected one.

Lastly, a personal preference, I would like the outline of the selection to be animated, moving lines to indicate that something is going on within that area with the fancy outline.

A selection sub-menu on the top bar could also be added with more general selection options. The copy, cut, copy visible etc could be placed there, as well as invert selection, expand selection, clear selection, select all etc

Overloaded Edit: Adding a list of selection tools that would be nice to be added, because I like lists.

• By color selection tool
• Magic wand selection tool
• Elliptical selection tool
• Lasso selection tool
• Polygon selection tool
• Paint brush selection tool

Pixelorama db29c1a

Just press play button in animation

This is rather long-term suggestion due to Pixelorama being in early phase of development.

It could be a nice idea to incorporate Pixelorama (at some point hopefully huge) community into creation of its splash arts. Some people might be already familiar with such concept as I'm pretty sure that Photoshop does this with their splash arts too.

Basically, members of our community could submit creations they made with Pixelorama and the best looking art would become Pixelorama splash art for next minor release. On top of that, authors name would be displayed on the splash art itself and within "About" information page, possibly with some link to their portfolio or project page. Then once time comes for next release, the cycle would continue with another Pixelorama artwork from another artist.

The only issue is that Pixelorama must follow MIT license, meaning that art itself would have to be published on MIT license as well. However, I feel like it wouldn't discourage as many people as it might feel like. Moreover, since there is no way to get around this issue we could just embrace all it's aspects by publishing artwork project file alongside current release. This way Pixelorama users could not only see what kind of amazing art can be made (like the one on splash art) but also peek inside splash art project to see how it was made in the first place. You could access current splash art project file from within "About" section next to author credits.

If Pixelorama would manage to reach the point of being capable of hosting own website, such approach could even transcend into some kind of "Hall of Fame" in the future, where all splash arts would be published alongside creator information and project files.

Hi! Idk if this problem is on my side, but when i pulled last changes and try to run it i get this:

What could be happening?

I tried implementing an undo/redo system which worked, until I implemented the layer system. I gave up on it ever since so I could focus on adding new features, but it is a vital feature to have. And now that there are so many features compared to the past, it's going to be even harder. Any help would be appreciated, whether it's just ideas of what to do or even pull requests.

Hi!
Sometimes, when picking a color, the color picker from godot picks the color of the lineout:

IDK if this can be solved easily.

I've tried only with .gpl palettes and I noticed that some colors are not imported correctly

It is not realy a bug but a future not implemented...
Load a .pxo and press save, the program will open the default file dialog without name and dir.
Make the program to remember the location of the loaded file.
Do the same for Save as, cause usually save as is used for itterations or alterations that belong to the same category (dir).

Description

When Godot is opened, and then Pixelorama is opened, KDE Plasma treats Pixelorama as one of Godot's windows. This only happens when Godot is opened first.

Steps to Reproduce

1. Open Godot
2. Open Pixelorama

Behavior

In the taskbar, Godot will have a green plus on its icon, meaning that there are multiple windows open under Godot.

Clicking on the Godot icon gives me the option to either bring the Godot window or the Pixelorama window to the foreground.

Expected Behavior

Pixelorama is treated as it's own application.

Additional Information

• Godot version: 3.1.2.stable.flathub
• Pixelorama version: 0.5
• KDE Plasma version: 5.17.4

There could be another option for the paint bucket tool to -instead of filling with a specific color- fill with a pattern. It would also be nice for the user to be able to add their own patterns somehow, maybe similarly to how custom brushes work.

Undo Redo needs to be freed to prevent leak

WARNING: cleanup: ObjectDB Instances still exist!
   At: core/object.cpp:2069.
Leaked instance: UndoRedo:2088
Orphan StringName: UndoRedo
StringName: 1 unclaimed string names at exit.

To prevent leak it is enough to add at the Global.gd class in _exit_tree undo_redo.free():

diff --git a/Scripts/Global.gd b/Scripts/Global.gd
index 1d0f7fb..041ac7b 100644
--- a/Scripts/Global.gd
+++ b/Scripts/Global.gd
@@ -457,3 +457,6 @@ func blend_image_with_color(image : Image, color : Color, interpolate_factor : f
                        else: #If color is transparent - if it's the eraser
                                blended_image.set_pixel(xx, yy, Color(0, 0, 0, 0))
        return blended_image
+
+func _exit_tree():
+       undo_redo.free()

When the users have selected a part of the sprite, they can only draw inside of that part when using the normal pixel brush. However, I haven't managed to do the same with custom brushes because they are images that are being added to the main image layer, and not individual pixels like the pixel brush. As such, I'm not sure how to restrict the brush image's pixels to only draw inside the selection.