A few questions to developers who use it...
Poll: SpinApp (13 member(s) have cast votes)
Which format for saving pictures would be more useful?
Macintosh PICT (current)
(3 votes [23.08%])
Percentage of vote: 23.08%
PNG
(10 votes [76.92%])
Percentage of vote: 76.92%
So, I'm asking developers of plugins what they think currently of SpinApp, what it does well, what features you think it needs, and would you consider me switching over from saving in PICT to PNG a good thing.
I have always wondered why it saves as PICT since I see no reason whatsoever to do so (can EVNEW even import PICTs?). After making a sprite you still need to import it into your plug (most likely as an rlëD) so using PICT files as an intermediary format is useful... how?
As for masks, extracting one from the sprite image is obviously not an ideal way to make one (it should be created separately by the developer). It might be useful for some, however EVNEW does this anyway by default (as I understand) so there's probably not a lot of use for it in SpinApp as well. Also, the source image may contain transparency data, in which case it would be better to extract a mask from that rather than the black of the image. What I would suggest though is to simply save one image but preserve the transparency of the original (be it OPAQUE, BITMASK, or TRANSLUCENT). Then it's up to the user to decide what to do with it.
Features? I added a feature to it myself once, for a highly specific purpose 
This post has been edited by Guy : 26 February 2009 - 11:12 PM
Any chance for the source under GPL? It can't be that complicated, but it's a pain to rewrite already. I'd grant a credit.
@Guy: EVNEW can import PICTs, and does so rather gracefully.
I think .pngs or picts would be fine for the images we work with through SpinApp, though being able to select which it uses would be good too.
If you add a feature that adds the ability to turn a color to alpha, I wouldn't ever use it. The graphics I make are all done with keeping the alpha mask intact in mind, which is converted to an alpha mask semi-automatically by SpinApp. Additionally, if you're making your own graphics and using SpinApp to put them together, I don't see a situation where you'd ever need to use such a feature either.
QUOTE (Nonconventionally Creative @ Feb 27 2009, 12:25 AM) <{POST_SNAPBACK}>
Any chance for the source under GPL? It can't be that complicated, but it's a pain to rewrite already. I'd grant a credit.
Better idea: how about source under MIT or BSD which will not result in severe wrath, courtesy me?
QUOTE (Guy @ Feb 26 2009, 03:15 PM) <{POST_SNAPBACK}>
Features? I added a feature to it myself once, for a highly specific purpose
What did you add and how?
QUOTE (Nonconventionally Creative @ Feb 26 2009, 04:25 PM) <{POST_SNAPBACK}>
Any chance for the source under GPL? It can't be that complicated, but it's a pain to rewrite already. I'd grant a credit.
No... because my code is terrible and because I don't want to bother with figuring out how any of those licenses work.
Anyway I've done a few fixes related to SpinApp so I'll post it here for now, if you think I messed up something, please tell me.
SpinApp 7
I added an ability to change the frame size of an existing sprite grid. This was back when I discovered roid sprites have to be at least 50x50 to work at higher resolutions so I needed to pad the smaller sprites out to a larger size. Dissecting the sprite and enlarging each frame manually was seriously tedious and seeing as SpinApp already had the basis for working with sprite frames, I decompiled it to add in this feature. Hope you don't mind
QUOTE (Guy @ Feb 26 2009, 09:09 PM) <{POST_SNAPBACK}>
I added an ability to change the frame size of an existing sprite grid. This was back when I discovered roid sprites have to be at least 50x50 to work at higher resolutions so I needed to pad the smaller sprites out to a larger size. Dissecting the sprite and enlarging each frame manually was seriously tedious and seeing as SpinApp already had the basis for working with sprite frames, I decompiled it to add in this feature. Hope you don't mind
Heh, that sounds like a lot of work to me, so I wouldn't try it, but if you want to, I'm not going to stop you.
A one-step solution for increasing frame sizes actually is something I've wanted in the past (when designing shield and engine flare graphics for sprites originally made for EVO, for instance), so I'd be happy to see that. Being able to auto-generate a mask using a key color of my choice would also be nice, though that's not so onerous to do with Photoshop, GraphicConverter, etc.
What I would really like to see, though I know this would require a completely new version of the program, would be to import 3D models, spin them, and put out the sprite sheet. That's my only complaint with SpinApp as it stands - it only works with a still image. Basically, it would have to do what the old movie to rle app did. Right now, my only real good way of putting 3D looking sprites into EVNEW is to create the model, run it through Celestia, put a transparency I created with 10 degree angled lines on it over my screen, and take screenshots at the appropriate intervals, then photoshop out the parts of Celestia that I don't want. I created a model of the Defiant from DS9 and it took me quite literally an entire weekend. There's no real good way to render the model in Blender so that it exports in a way that EVNEW can understand as a sprite sheet, as best I know.
QUOTE (krugeruwsp @ Feb 27 2009, 09:41 AM) <{POST_SNAPBACK}>
Basically, it would have to do what the old movie to rle app did.
It currently does this, except the it has to be a sequence of images, not a movie. So if you drag 36 images onto SpinApp and each has a name of like Frame1.png through Frame36.png, SpinApp will correctly create a spin out of them. After all, I used SpinApp to stitch the sprites in this screenshot together:
Sorry for the double post, but I wanted to bump to get a final opinion on the new version 7 which I just finished. Changes from the last attempt at version 7 include correctly determining display settings depending on operating system, and a better description on how to use SpinApp on the initial window.
Download it here:
SpinApp7
QUOTE (IT 000 @ Mar 8 2009, 03:13 PM) <{POST_SNAPBACK}>
First off, I love spinapp. It's a time saver and sure beats the tedious work of spinning it manually. Good job creating it.
Thanks, it's always good to hear that one's work is appreciated.
QUOTE (IT 000 @ Mar 8 2009, 03:13 PM) <{POST_SNAPBACK}>
Second, I found a glitch that whenever I spin my .pngs Spinapp changes their color, for example if I spin a dark blue, it will come out dark red.
Odd, I've tried many images and I have as of yet to encounter this bug, could you send me the image that you're working with?
Ships like this one are easier to fix. I just go to photoshop -> Hue and Saturation -> Add or Subtract 118-120 hue.
It doesn't effect grays and blacks, just colors. Which is odd considering the hues appear to be somewhat 'inverted'.
This post has been edited by IT 000 : 12 March 2009 - 09:19 PM
I just tested this on Ubuntu Linux 8.10 x86 and it worked just fine.
I used:
Sun's Java6 and Java1.5 from the repositories
Sun's Java1.4 from a manual install. I got some errors, but that was probably unsatisfied library issues, and the final image still saved and appeared correctly.
From a programming perspective it is apparent that someone's reader or writer is swapping the RGB masks. This means that red and blue will swap and green will remain the same.
This is most likely a Mac-implementation issue since Mac users are the only ones liable to be stuck with 1.4, anyway. (No slam intended, but it's the truth).
