Issue with baking rotated sprites in editor about onelife HOT 3 CLOSED

Yeah... this is actually intentional, even if it seems a bit strange.

So... the non-90-degree rotations are being done by the graphics card.... the GPU can interpolate pixels, etc, to make the rotation look good and smooth. But the sprite-baking code works with the pixels directly, to make a pixel-perfect "bake", and that's currently only possible with 90-degree rotations. My code doesn't even attempt to do non-90-degree rotations manually, pixel-by-pixel.

In fact, the off-90 rotated sprites aren't used anywhere in the main OHOL content, or at least are used VERY sparingly. Because they look blurry, after being rotated/smoothed by the GPU, and they don't match the crisp lines of the rest of the artwork.

There was even one instance... I 'm trying to remember where it was... where I actually rotated the paper on the scanner to get a crisp 45 degree version of some sprite.... yeah, I did that for YewShaft, which is used on the Newcomen machines, and has to rotate at slight angles. The sharp-scanned version of the shaft created a bunch of shimmering aliasing when rotated slightly in this way, so the I re-scanned it a 45 degrees, and then rotated it 45 more to vertical, which made it blurry enough to fix the problem in the animation.

The problem here, of course, is that the editor LETS you bake a sprite with 45-degree rotations in it, and then SURPRISES you when the result looks different than what you baked. I'll fix it so that there are no surprises (it probably won't let you bake if any sprites aren't in 90-degree orientations, and will warn you about this in some way).

from onelife.

Yeah, I just checked, and there are 85 objects out of 4400 that have any rotated sprites at all:

19.txt
65.txt
119.txt
254.txt
256.txt
257.txt
262.txt
282.txt
302.txt
304.txt
316.txt
317.txt
350.txt
351.txt
353.txt
420.txt
421.txt
422.txt
429.txt
491.txt
536.txt
537.txt
538.txt
539.txt
599.txt
645.txt
705.txt
764.txt
840.txt
944.txt
1007.txt
1009.txt
1128.txt
1129.txt
1130.txt
1277.txt
1336.txt
1349.txt
1375.txt
1385.txt
1628.txt
1631.txt
1635.txt
1636.txt
1767.txt
1768.txt
1769.txt
1777.txt
1778.txt
1857.txt
1858.txt
2101.txt
2271.txt
2277.txt
2357.txt
2401.txt
2404.txt
2462.txt
2464.txt
2498.txt
2574.txt
2576.txt
3959.txt
4664.txt
4741.txt
4742.txt
4745.txt
4760.txt
4761.txt
4775.txt
4790.txt
4792.txt
4793.txt
4795.txt
4796.txt
4797.txt
4798.txt
4799.txt
4800.txt
4801.txt
4909.txt
4948.txt
4950.txt
4956.txt
4957.txt

All female humans do, surprisingly, for their nipples.

from onelife.

Also, note that baking has performance trade-offs....

It improves performance for objects with LOADS of sprites, by reducing the number of sprites that the CPU needs to manage and draw.

It reduces performance for objects with sprites that are spread out spatially, since the GPU will need to draw all the "transparent" pixels that now exist between the formerly-separate sprites. I.e., the "big sprite" now takes up a bigger square area, and if most of that square is transparently, this is a performance loss from the GPU's perspective.

Like if you had a tree covered with little leaf sprites, and those sprites were pretty much covering the whole area, with lots of overlap, then it's a big performance win to bake. The CPU won't have to manage so many sprites, and the GPU won't waste time drawing the overlapped pixels.

But let's say you had a big square frame made up from 4 separate skinny beams. Baking this would be a huge loss. You go from 4 sprites to 1 sprite for the CPU to handle, but you multiply the number of pixels that the GPU needs to fill by a factor of 50 or more, since the hollow area in the center of the frame is now part of the new, big sprite.

So you shouldn't always just bake, as a reflex.

There are also some times where it might be tempting to bake simply for convenience... like if there's a pretty complicated object that is going to be used a lot in other objects.... It can be a pain to "paste" a complicated object in and drag it around... I mean, you can define parent relationships so it holds together, but it's still very touchy.

from onelife.