next »

[happymonster]

15th November 2015 - D-Pixel version 0.951 released

• A couple of crashing bugs to do with tilemaps and large images, and also with invalid keyboard shortcuts crept into the 0.95 release - now fixed
• Added + and - keyboard shortcuts when in a canvas window to increase or decrease the zoom level
• Altering a grid size slider now automatically recalculates the tileset from the image
• Tilemap analysis made much faster
• Changes to the brush tile drawing feature. You can now press the right mouse button to grab the current tile straight away (or hold and move to grab a multiple amount of tiles). This replaces the old versions where you would have to cancel drawing with the right mouse button and then select a new tile with the left mouse button.
• Fixed visual error where box cursor wouldn't appear when highlighting multiple tiles in brush tile copying

[surt]

Awesome! Everything I whinged about looks to be working fine now.

I just discovered that I can toggle snap by right clicking on the grid tab button, that's neat.

Is there a tool hidden anywhere that allows replacing every colour in the image with another colour without changing the palette? Ideally something like Pro Motion's non-isolated fill, just select tool and click on a pixel to replace all pixels of the same colour. It could give the regular fill tool a friend as it's looking rather lonely at the moment.

[happymonster]

Glad it's working properly now!

There is a colour replace (and a colour swap) paint mode, but you'd have to apply it to the whole screen.

The fill options are very limited right now, I have a lot I want to do with that part of the program as well. At the moment I'm kind of filling in missing functionality in one place, then another, etc..

Thanks for testing, I do appreciate it!

[Kasumi]

Here's an odd bug. Same file as the one I sent you. I'm on freehand draw mode, paint mode range, grid brush, tile mapping on, 8x8 grid.

I'm not entirely sure what other settings would matter, but let me know what other info might be helpful if you can't reproduce it.

Anyway, changing the palette on certain tiles transforms others. A tile that is NOT identical to the one I'm changing the palette on not only gets its palette changed, but also has its graphics changed to the tile I'm editing.

Shorter, a different tile gets made identical to the one I'm editing.

GIF:


The change is subtle. Note the bottom right of the tiles that change with the one I'm painting. They have two grey pixels that get transformed into one green pixel. The tile I'm editing has one gray pixel that should become green, which does work.

[gimymblert]

o

[happymonster]

Hmmm.. I'll have to look at that too!

Jimym: ?

[gimymblert]

subscribing coin it was

[happymonster]

Ah.. you must be a wizard!   

[surt]

A couple small things:

The default file filter in the load image dialog is "all files". Since AFAIK you can't open anything other than image files could we have an "all image files" filter which matches the extensions of all supported image formats and make that default? (And even better remember the last used filter and restore it next time.)

If I cancel the load image dialog the "saving workspace" message pops up even though nothing should be changed.

[happymonster]

I still have some things to fix, but for now:

18th November 2015 - D-Pixel version 0.952 released

+ Fixed a bug with tilemapping where the wrong tiles could get updated when tilemapping link was on
+ Fixed an issue where images with odd numbered widths or heights would get drawn in slightly the wrong position, causing half of the last pixel row or column to be obscured. This also affected the wireframe grid option in Grid Options
+ Crop tool incorrectly added an extra row and column to the selected area before cropping. Now fixed
+ Changed the 'All files' default option in the Load Images fileselector to be 'All Images' and only show the image files that can be loaded

Oh, I've also discovered MarkDeep so I'm using that for the website, it's easier to maintain and looks nicer.

[ewetcr]

Sry if this has been discussed previously, but will you add keyboard shortcuts?
For a faster workflow it would be great.

First timer here using the program, it felt a bit out of control and couldn't know what was happening at a point .
I'm loving the interface and the dithering tools so far.

[Kasumi]

It seems to only update the very last tile edited. Say I click two tiles. All tiles that match those two are changed to reflect this edit. Say I click and drag across two tiles. Only the tile the mouse was on when click was released gets edited. Gif, as usual:

[happymonster]

ewetcr:

There are some keyboard shortcuts in there already, but it's not comprehensive.

Kasumi: Hmmm.. yes didn't think of that!

[happymonster]

Actually thinking about it some more, I think this was done because of how to deal with the situation where the user edits part of tile 1, then moves another another tile, which is also tile 1 and edits over that. How does the program deal with that? as the edits are only applied at the end of a drawing operation for speed at the moment.

Maybe I need to make it apply the edits when drawing, but before finishing..

[surt]

Find the list of tile coordinates the draw operation intersects then for each tile coordinate in list apply draw operation to referenced tile with relevant offset and clipping.

[happymonster]

Ok, that sounds workable. Does ProMotion do something similar?

[surt]

No, Pro Motion is similarly borked. It has a separate pattern tool which does this, but it cannot be used in conjunction with tile map images.

I've implemented this functionality in my own abandoned editors and it's always worked for me. Also useful for wrapped editing.

[Kasumi]

I think Pyxel Edit keeps a separate image for both the canvas and tileset, and just works hard to keep them in sync. I'm not entirely sure if it's this system or something unrelated that allows it to have real time updates on all tiles that match the tile the pen is touching while you're actually drawing.

I'm only aware of this being its underlying behavior because I once found a bug where the tileset and canvas got out of sync. Here's a gif of that bug, which may give some insight into the pyxel way of doing things:


If I had to guess based on that gif, it applies the pixels in the drawing operation to all the same visible tiles in the canvas "view" in a temporary buffer. Sounds like what surt described. When the drawing operation is complete, it commits the pixels to the tiles, then replaces all edited tiles in view again with the actual tile with the change committed, not temporarily. The out of sync tiles I'm drawing on only become white when the drawing operation is done, and that's also when the tiles in the set change to reflect what I drew.

edit: When undoing the changes in that gif, the tiles on the canvas stay white.

I've considered making a program like this because my needs are so specific, but not useful to the general population like my 16bit color woes. I'd have to think more on it to try to give solid advice.

[happymonster]

Thanks for the explanations both of you.

I'll have to think about how best to do this. Sounds like Surt already has done something that works before. Why haven't you done your own usable paint program Surt?

[surt]

Well, I've started probably over a dozen.