An interim update (pacing grows slower as i stepped into trial and error territory).
Just wanted to share this technique for arranging and editing sprites (in the context of bg overlaying sprites) that i've found to be really useful/effective:
Overview of my workspace:
In my previous post, i bashed the slice tool for not being versatile enough. I take that back.
Setting up the tool for optimal spritework is quite easy:
- Untitled-1_03.png (7.9 KiB) Viewed 10298 times
1) Set it to fixed size, h16 w8 (or what you need). Go on and make templates so you don't need to manually enter the numbers from project to project.
2) Under ctrl+k -> slice tab, unselect all the intrusive HUD elements so you only see the bounding boxes.
3) Under ctrl+shift+alt+k, make a hotkey for showing slices so you quickly can toggle the view on and off.
4) In the slice toolbar, click "hide auto slices" (all the excess slices PS needs to make for the user slices to function.)
Tips for editing:
1) I find it very useful to have the "slice select" tool selected and, when i need to generate a new slice, simply hold control to toggle it temporarily to slice tool
2) When viewing slices, the pencil unfortunately 'snaps to slice'. There might be an option to turn this feature off, but for now i just toggle back and forth.
3) In the
slice select toolbar, click the "slice options" icon. From there, you can add metadata and alter the filename of each individual file that's going to be output. I find it useful naming them RR_S_P where R is row number, S is sprite on that row, and P is priority. You could add exact sprite positions to the filename, too, and mark if they're used in several positions.
Export and import:
1) Use save for web (legacy) - maybe there's some other way. Since the slice tool featureset was originally developed for webdesign work, it doesn't support a bmp file container, which kind of blows. Your reasonable options are GIF and PNG.
2) Then find or write a nonlossy batch file converter. I've yet to do this.
Anything beyond this point under this header is untested since i'm not yet done with sprite ordering.
3) Import them in NESST. Marking a cell in the attribute table should import it starting there, not overwriting previous imports.
4) Once they're sorted as they would appear on a nametable, hit 8x16 interleave. NESST does the job for you.
The rest should be straightforward.
So, what's the benefit? Apart from being able to clearly see where sprites are, slice metadata is kept in its own layer system of sorts. That means that you can move sprite boundaries as you please without touching your raster layers, making it easy to identify optimal placements where sprites can be of the most use, as opposed to strictly keeping at a grid.
-You can also simulate a preview of sprite priority by sorts by sorting overlapping sprite slices in its own ineherent layer system (note of warning*).
-You can then edit your pixel art independently and without regard to sprite boundaries. Anything outside the boundaries will be cut from output (that's a great feature in itself), but you're free to surpass it and test things out without having to move sprites around. Move sprites to match.
-It also means i don't need to keep that many layers, which reduces the common 'oops, i edited the wrong layer' syndrome i seem to be having.
Pitfalls:
*It IS a webdev tool, and an oldschool one at that. On a webpage, images don't overlap (if they would it'd take a lot longer to load a page because of redundant data). PS' "save for web" export function will sub-slice any intersecting slices into smaller ones and discard any overlap.
-As mentioned, it only saving gif, jpeg and png blows. They mean well, but an arbitrary limitation like that is annoying. Besides, their not-included bmp export has optional RLE-compression, so if file size matters, what gives? Browsers not supporting a unified BMP RLE standard?
-You might still need a little bit of raster layer management to make sure your slices export with the right content.
Current workaround:
-Select and export all non-intersecting/overlapping sprite slices first. They should be in the majority.
-Then individually select and export the overlapping ones.
OR
-copy the content of a slice into its own layer.
-export layer as ...
You could probably make a script out of option 1 to do the work for you.
Other strategies/tips that doesn't have to do with slices:
1) It's helpful to keep a black layer at half or 75% opacity between your sprite layers and your backgroundlayer and toggle its visibility.
2) I found the most helpful/least intrusive way to use a 8x8 or 16x16 grid is having it set to style: dots, gridline: 16px, subdivisions: 2. This way, i get both the 8x8 and 16x16 grid without it being in the way for seeing slices and pixels. I still keep its visibility hotkeyed. Again, PS is defaulted to snap pen to grid if it is visible. I'll have to look into that, because it's not helping 98% of the time.
3) You could keep every sprite in a separate raster layer, give it a thin drop shadow under layer effects to visualize sprite overlap and priority, but having 64 layers like this is disorienting and human error prone. Keeping them like this means you can export from layer, but you need to be mindful of the 'layer canvas'.
4) make a gray horizontal 1px line which will function as a "scanline ruler" in a layer, set its blending mode to difference and move it pixel for pixel downward to se how many sprite hits you get per scanline, instead of trying to wing it. I should in fact do that right now.