Sprite Layer

Thndr

Sep 5, 2013 at 4:55 am

This suggestion is something that would probably take a while to implement, but I think it would be useful.

I suggest 2 types of layers, a tile layer and a sprite layer.

The sprite layer would change the tile window to a sprite window, showing multiple sprites of different sizes

To edit a sprite, a sprite editor window should appear and you can adjust the size just like a normal image document.

The sprite window should allow naming of the sprites for easier export and internal organization
The placement of the sprite for export should have the upperleft corner tracked and have the size and name of the sprite. (Depending on the number of sprites, this can either be smaller or larger than a normal tile layer's export size*depending on how many tiles*)
The image file for export>spritesheet would have the sprites organized in the most compact way in pngs with ^2 sizes (64,128,512...), different sprites should be

This would allow a more diverse way of making images as well as provide more centralised use of PyxelEdit vs PE+Other programs. It is a lot to ask for and there are other things more important, but it's something that I think should be thought about.

Danik

Sep 5, 2013 at 10:17 am

While it would be nice, I'm afraid it would be too much work and complexity for too little benefit.
I would like to keep the number of systems as low as possible, so if I can change the current way it works to fit peoples workflow better I would prefer that. I'd love to discuss how the workflow in PE can be streamlined because that is one of the main goals of the application.
What is it in the current workflow that you need to go outside PE for?

Thndr

Sep 6, 2013 at 1:20 am

Well with how I make images, PE at the moment isn't suited for much other than tile work for me. (It's really great at tile work though)

---
One of the major things for even a single document image is the marquee support (which I know you're working on). With fully functional marquee cut/paste support and having it not bug with the tile sections then I could deal with that as that'll make things much more accessible.

---
The sprite suggestion is sometimes you want to add to a tiled image a sprite. Currently you'd have to draw the the sprite but be at the mercy of the tiled functions. I figured if you had a sprite-repository like you do with a tiled one (with the repository holding the sizes of each sprite) and stored sprite locations like you do with tiles, but with absolute X/Y coordinates, it would make things like manipulating sprites on canvas easier.

The sprite edit box suggestion is because the normal canvas is tile based so you can't be expected to put a sprite on there and edit it (Unless of course you use the maruqee tool to select the area needed for the sprite and then add the selection to a sprite-repository).

The suggestion's details were mostly a convenience for sprite organization and creation within PE, but nothing necessary. More of a use for having PE also contain object/sprite locations on a layer to be exported as JSON/XML to use. (currently I just make tiles with object identifiers in them, and have the engine recognize the tile-number range)

---

There are also a few minor things, like right-clicking an area that leads to the transparent BG pattern gives a black instead of transparent color. However my current workflow doesn't have layers so I'm used to having a BG color to put in to "remove" pixels so that I might have to get used to selecting the eraser. (Most of my work is in PSP 4.12, which is very ancient but more powerful than MSPaint.

Another solution is that once full copy/past functionality comes to PE is to also include a way to fill an single color area with transparency. This would actually make it so that my tools can work seamlessly together as if i need a sprite I can open the document, copy/paste it and then make the BG transparent (or add an option that deletes all of a single color in a layer or selection.)

I don't want to divert your own image of what you want to software to end up as as I'd rather have a fully fictional piece of software with a single purpose than a multi-functional one of lesser quality. Heck looking at it most of my issues can be worked around with proper marquee(In progress) and copy/paste support, or even just "Import from clipboard to layer" (although I'd prefer the ability to copy/paste in the program)

Simon

Sep 6, 2013 at 5:49 am

I see it the same. Keep it focused.

But a working marquee tool with copy/paste would help me too with the whole sprite thingy and the workflow overall.

I think this should be one of the first things done right in a future build :)

Danik

Sep 6, 2013 at 6:48 am

Thanks Thndr, that feedback is really valuable.
Since I work on the application alone and haven't been able to do much user testing (it's hard to find people to test on since it's a niece application) I sometimes forget about the obvious problems.

I have been thinking of having some kind of object support, where you can place objects with attached graphics and properties. This was meant to place items or triggers for levels, but could also be used to place (static) sprites at arbitrary positions. Maybe there could be a list of objects similar to the layers list, where you can select an object to edit in a separate window. You could then place instances of the objects in the canvas (not sure if they should be placed in layers or directly in the canvas...). As you say this data would be exported in XML/JSON.

And yeah, I really need to get my ass working on the marquee tool. :)

BTW. You can fill with transparency by holding Ctrl with the bucket tool.

Thndr

Sep 8, 2013 at 3:19 am

Glad you had a similar base idea about objects.

I kind of hope once everything is more fleshed out to use it as my main pixel tool

Thanks for letting me know about the transparency

javis

Sep 13, 2013 at 10:01 pm

I would like to see this feature implemented too.

It would be really nice to use the same environment to draw objects and tiles, to share the same palette and see how the sprites looks in front of the tiles.