Jump to content
Spriter Forums

Recommended Posts

Posted

Please change stretching in the viewer to only change scaleX and scaleY.

Right now it changes both the scale and the actual x/y values. This doesn't really make sense to me why it would do this.

So for now I can only do scaling on the left in the "Objects In Frame" window by changing the numbers there.

Thank you

C2tP

Posted

Ok here's a few other things I would like to see.

1. Grid (super easy)

draw some more lines on the canvas (main view). this helps give perspective of how big you're making something.

Custom grid spacing would be nice too. And it would be an awesome bonus if there was a photoshop style thing where you can create guide lines by dragging from the ruler.

For instance say my game is in a specific resolution...say 800x600, and i want my artist/animator to make this end game score animation that takes up the whole screen and involves a lot of scaling and such. It'd be nice to set some lines to represent the actual game's canvas(800x600) so he can animate to fit. (instead of mousing all over the place to see the cursor position at the bottom)

2. Quick hotkey (or just do it automatically) to open of the image information in the "Objects in Frame" viewer.

If i click a bone it pops up all the bone information (x,y,scale,angle,etc)

but if i click a texture, first i gotta switch windows on the left side, then scroll up/down to find the selected image, then click the little expand arrow.

It's a pretty big pain when im going back and forth between images/bones to look at their info

3. Display width/height somewhere in the image data area (next to all the x/y/scaleX/scaleY/angle/etc stuff)

If you do a lot of scaling...i want to know EXACTLY how many pixels (width/height) my image is using. Not only for general ease of mind, but if you expand and then contract I want to *make sure* that it's back to it's original width/height.

This seems straight forward by making sure scaleX/scaleY is back to 1.0f but when you add bones into the mix, its not as easy to read. Like a bone could have a 0.56344 scale X which might offset the image scale X to 2.54567 or some random number...which obviously isn't very readable.

Just displaying the current tweened height/width would be enough for me...but hey could also be cool to auto adjust scaling by entering width/height into that info box.

So if i just type in 64x64 it will adjust the scaling to that it will draw at that size (be the scaling 1.0 or 2.54567356).

Thanks again!

C2tP

Posted

Ok I'm kind of spamming now but I got one more.

I would like to see a way to propagate a newly inserted item (bone or object) to all future keyframes (from the point you inserted).

say you have a big long animation...its long and awesome and works great.

then you copy that animation and basically use it to create another set of animations for a different character...only this one has a hat.

When inserting an object, you should have an option to propagate the hat through all frames.

if i have 8 animations with 50 keyframes each and i want to add a hat.... I think in its current state I'd have to go through all 400 frames and add the hat manually.

Granted, I'd have to go through the animations and animate the hat, but seems like a big time saver and headache-reducer if I can throw in the hat object, click apply to all frames and bam! got a hat on every frame.

Seems like a pretty simple and straight forward addition that I think a lot of people would use.

Thanks again,

C2tP

Posted

Hi

I'm a professional game developer for 20 years and we've just found spriter - and totally love it for our 2D animation needs. And will probably use it for our up coming projects. We like it because it's lightweight, quick and easy.

we've read thru the entire 11 pages of feature suggestions and here's our list

1) Atlases - of major importance for render speed e.t.c. - currently we have to munge using a tool we're writing.

2) Generic Triggers and attributes - much like the sounds I guess u have planned - but just having triggers/values for various uses - collision, events e.t.c.

3) Quad mesh weighted blending - for automatic squishing e.t.c when using bones

4) Scripting - exposing internal functions - so it's easy to extend to a bigger feature set.

5) Pre-built Skeletons and Example animations walk/run/jump cycles e.t.c.

6) a Tiny c++ lib to load, render and manipulate animations (blending animations sets - much like slerps and squats in 3D).

Yes we're writing our own - but it would have been so cool to have some tiny libs ready for this.

I think that if you had 5) and 6) - this sell like hot cakes, coders would love to be able to plug this in quickly and get something moving on the screen with minimal effort.

It's great as it is - and we look forward to future developments!

Shabby

Posted
1) Atlases - of major importance for render speed e.t.c. - currently we have to munge using a tool we're writing.

2) Generic Triggers and attributes - much like the sounds I guess u have planned - but just having triggers/values for various uses - collision, events e.t.c.

I think these are probably the most important.

I definitely want to add generic triggers. These can be used for numerous things and should be considered required for 1.0

scripting sounds cool but can definitely come later.

A first party c++ lib would definitely be icing on the cake for selling purposes, but ya some people have made some public APIs(good job grimfang :D ).

Also there are so many engines and different languages out there it'd be more overhead for Brashmonkey and I think their dev time might be better spent on just the editor. Leaving API to community might be the best decision.

Honestly though most people I think will want to change and adapt it to their own engine or whatever so a generic API can only go so far. (great if you want to use it as a base though!)

Also implementation in c++ took me one afternoon starting from scratch with reading in the XML to drawing and animating so even if you do your own implementation you should be able to punch it out quick I think.

Posted

I think character maps are a very important feature that would get used right away. Being able to use the same animation for multiple different characters or swapping body parts seems more important than atlases (an optimization), at least. I could make an interface for those features in the C++ API directly, but I'd rather make it compatible with the planned SCML spec.

Honestly though most people I think will want to change and adapt it to their own engine or whatever so a generic API can only go so far. (great if you want to use it as a base though!)

A well-designed generic API is one that lets you do that without code changes to the actual library. If there are clear, flexible, and comprehensive interfaces to the data, you do not need to break the API to make it fit your engine. I just need community input to map out those interfaces fully.

  • 3 weeks later...
Posted

Easing functions would make the program much more complete. Easing functions makes transitions between states more controlled. For example Universal Tween Engine uses these and it is Apache 2.0 license so it could be added to your software http://code.google.com/p/java-universal-tween-engine/. I am not sure, what language you are using, but there should equivalent libraries for other languages also. There is demos in the provided link to see how the concept works.

At first phase these functions could be set from menu, but I hope that eventually these could be set visually from the editor, similarly to Adobe Flash Professional.

Posted

Do not know if already suggested, but this is a biggie for me.

On export, it would be nice if we had more options.

Example:

Export X and Y height, let's say, we wanted a 512x512, it would be easier on us if we could just type that in.

Instead of increase and decrease size of the window, give us a square we can move. This way, it is easier for us to move it around the image.

Allow us to make a sprite sheet. Like the upper example, allow input on how many tiles on the x, on the y. Render on the x, once full, move down one on the y.

Those are the only things I noticed. Keep up the good work!

Posted

Contraints for bones could be useful (limiting the extent that joints can bend to simulate natural joint restrictions.)

Perhaps an "inverted order view" to make it easier to edit segments behind the primary parts.

This could be difficult, but how about "render to sprite sheet" as an option?

Posted

A rather simple one which I think would enhance the workflow greatly: Let us pan the screen space by holding down the middle mouse button. I'm not sure if I just missed something but it doesn't seem to be supported, which makes for some unnecessarily clunky controls I feel.

  • 3 weeks later...
Posted

1. Make shortcuts configurable.

2. Allow to snap the rotation, scale and position of an object.

For example:

-Rotating can snap to nearest multiple of 30deg

-Scaling can snap to the nearest multiple of 0.5 or until it collides with another object

-Position can snap to a grid or another object

3. When zoomed in and moving an object, it doesn't snap to a pixel - you can move it by less than a pixel. It should snap, or at least you should provide it as an option.

4. When a bone is selected and a sprite is overlapping with it, when I click on the bone again I don't want to do nothing - I want to select the sprite! The same applies when a sprite is selected and the bone is not.

5. Why can't I change the size of bone hierarchy window to a smaller one? It's minimum size is too big.

6. When I drop the sprites on canvas while zoomed in the sprite I'm dropping is not on the zoomed in canvas, it should be so I can see where I'm placing it.

7. I want to set that default pivot point of my sprites is center (I can see a checkbox ''default'' but it's disabled).

  • 2 weeks later...
Posted

It would be great to be able to add graphics that are not in the folder or any subfolder or the spriter file, even if is not on the 'File Palette' but added through a file open popup.

That could look in a SCML file like this:


We're currently having to do a lot of copy files trickery to overcome this limitation and the bug that makes 2nd level subfolders resources not load properly in current a4...

Kind regards,

Pablo

  • 2 weeks later...
Posted

Sorry, there are 12 pages and I didn't look through them all. Here are some simple suggestions. I'm an ameture at this kind of software so I might miss some of the details. So I did take it as a newb and maybe needs to be more apparent for ease of use :D

1. Absolute numeric field control.

Able to controlt he base size for bones and sprites from the field. I find most of the changes I try to make don't effect anything.

2. Animation flip. It would be great to have an in tool option to just flip an animation. So that we can have a Run Right, then just duplicate and flip and then have a Run left :)

3. bone pivot lock

While I'm trying to move bones I find that I often make minor slip ups and move the bone. It would be helpful to just lock the pivot point to the parent. I often ctrl z to undo, but this is just convience :)

Posted

As a professional animator I have 4 requests (in order of my suggested importance) that would make this the ultimate gaming engine. I truly believe that adding these features would blow the competition out of the water.

1) Deformation - I saw in your videos that your guys are considering adding a deformation type tool. It doesn't need to be that complicated during the beginning of your project. To get the ball rolling I suggest adding the ability to manipulate only the 4 corners of every limb image. Having the ability to manipulate the images to the extent shown in your videos is great, but I think you will be very happy with what animators can do with just manipulating the four corners. (might be easier to implement aswell)

2) Easing - Easing in your tweens helps tremendously when attempting to make your animations look more believable. A simple -100 to 100 option(similar to flash) is sufficient. -100 being ease in and +100 being ease out. Maybe an option to have both ease in and out in a single tween would be helpful too.(just a thought)

3) Dynamically adding sprites - This one is obviously harder to implement, but maybe consider it for a future tool. The simplest way i can think of it is a single color that you can draw and erase to dynamically add limbs/sprites/whatever. It doesn't need to have all the whistles of a painting program, just something that allows you to quickly add elements that you can later take to a separate painting program to make pretty. (Great for prototyping animations).

4) Offsetting Limbs - (This might already be possible, not sure) When animating characters without a skeletal structure (a lot of flash animation is done this way) it would be nice to offset the animation of separate limbs via shifting the keys over a few frames. This can help speed animation workflow. (Common in many animation programs)

Thanks for hearing me out!

Posted

Hi janimator00,

1) Deformation is definately something Edgar and I are both very much excited about and intend to get in after the release of 1.0. We can't guarantee how soon, but its definately one of the big ones on the list of future features.

2) Easing for the tweening is another one that will definately appear as soon as we can get it in. We know how important that one is.

3) Dynamically drawing in sprites from within Spriter for the sake of creating placeholder "sketches" of the sprites you need for new animations has been a features I've dreampt of since my very first clunky Spriter prototype... This is another feature we want to get in after 1.0 is released...its just a matter of time after we get in all the already listed 1.0 features.

4) I think I know what you mean by "offsetting limbs"...You mean offset their timing from one another by being able to have seperate key frames per object (bone or sprite) which you can easily drag along the timeline independantly. If thats what you mean, you'll be happy to hear this is another feature we alswys planed on and finally had a cance to put in.. unless I'm mistaken, it should be in the next build release.

thanks everyone for all the great suggestions,

Mike at BrashMonkey

Posted

If you look at Spriter's keyframe system, it's like animating with a really small grid. If you look at 3ds max way of doing keyframes, you can clearly see the exact spaces in between keys. I'm saying that it would be REALLY nice if there would be an option for using that type of "fps" system instead of the "ms" way :P. I actually haven't seen a single animation program where they use ms as the default speed thingy... Anyway, I think it would boost the workflow for most of us animators that are kinda used to that system.

Hope you get what I mean :I

  • 2 weeks later...
Posted

The only feature I can think of right now that would be super cool is a Blender plug-in that lets you make the animations using Blender's interface. I imagine that would never happen, though. XD

Posted

What I'd like to have soon is the ability to export all frames (including inbetween frames) as a png sequence, not just the keyframes. Other than that my main wish would be deformation like the puppet tool provides in After Effects. That would be most useful for me. I know that's already planned, just wanted to +1 that.

Posted

Hi GDRKR,

Unless I'm mistaken, the next build will allow for specifying a frame-rate and will auto export the apropriate number of frames!

And yeah, Deformations is something Edgar and I have always been excited about and plan to add, but that most likely has to wait until after the release of 1.0

cheers,

Mike at BrashMonkey

Posted

@ Tap,

Spriters data format is open, so its certianly possible for someone to someday program a convertor or exporter which would export animations made in blender into the Spriter format. Right now we have to focus on making Spriter itself as good and sucessful as possible... but the more we suceed in making Spriter popular, the more and more likely exporters and converters like this are to be made by the respective communities.

cheers,

Mike at BrashMonkey

Posted

I must admit didn't read all the 13 pages of this thread... but there is 1 feature which would be essential in my opnion: to be able to use a single image as a source for "sprite parts".

Otherwise I may fear Spriter may actually cause a huge performance loss because of all the texture swapping going on on each character.

Is this a planned feature? I couldn't find anything anywhere about it - and in my opnion this is something essencial...

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...