soho54
-
Posts
24 -
Joined
-
Last visited
Content Type
Forums
Store
Gallery
Downloads
Posts posted by soho54
-
-
This feature is still coming I believe, but for now you can do a little work around.
Once you have your animation ready to go determin the FPS you are going to need, and then just add new frames at the correct times in the timeline. Then go back and remove the originals that fall out of sequence.
Check it out again, and re-tweak if needed.
Then you are good to go.
-
Just how large were the sprites you were using?
You could temporarily raise the display's resolution to something that will hold the images, and export your files this way. This is assuming you are not already using 2560x1440 or 2560x2048, you have access to a high-end LCD or CRT, and that either of these resolutions would be enough.
As you have found out you can't just alter the source image files, as it throws the Spriter location and movement coordinates off. I can't think of an easy fix for this. It should be possible to create script to convert the spriter data, but it will require some thinking.
If worse comes to worst, just use the Spriter Object Frame zoomed in enough to just fit the image (with a solid color background,) and create the frames manually with a screen capture application. It will take a bit more time, but it is doable in a crunch.
-
If it helps I was only rotating the angle of the calves and feet of the character using the Origin Dot leaver or bone Arrow rotation in the Frame window itself. I was selecting the individual sprites and bones in the bone hierarchy with sprites visible.
I was not adding or removing frames, just adjusting things in the run cycle manually to tweak out the puppet look.
The warping thing happened when I tried to adjust the angle of the head bone in two key frames using the Objects In Frame drop down menu for its fine control.
If I get a couple free hours I'll try to document it better and check out its reproducibility. As it is now I don't have much time, but I thought I would throw it out there as it kept occurring even after a few good measure program and computer restarts.
-
Bug present in a4.1 and 10-29 daily
I keep hitting a pretty regular bug tonight. After making more than ~2 dozen or so sprite and bone rotations in the Frame Window across 30 key frames I run the high risk of hitting an unrecoverable error. I will get either the sprites and bones in the area of the last change in a key frame being thrown around randomly upon hitting the Undo button, or if I manually rotate a bone in the Objects In Frame drop down list the bone plus all child items will be warped randomly in x and y scale in that key frame.
Tapping the Undo a few more times in either case will no longer fix things (as the similar issue with a4, but that one was corrected it seems.) It will in fact start corrupting earlier key frames if you keep pressing it until the Frame Window will start walking to the lower right corner on its own with each consecutive Undo press. (Yeah, I let it get to me after the third time... )
Remembering to save after every handful of changes seems to get around it though.
Working with Win XP
Using a character with 24 sprites, 12 bones (in two 3 tiered systems,) and swapping the images for 8 of the sprites with a group of 48 total alternates on a frame by frame basis. 32 Keyframes in the animation.
-
Thanks.
-
In Windows for bones you double click say "bone_005" in the hierarchy, and then just type in the new name.
With images you need to double click the name in the File Palette. This will change the actual files name, and it will use the new name when adding the sprite into the Frame again. It will not alter the the name for anything already used in the Objects in Frame list though. It will work fine with the mismatched name until you re-open the file, and at that time the any sprite under an old name in your OiF list will no longer appear.
In that case you need to fire up a text editor and change the SCML file manually.
-
Sometimes I get the odd Undo sprite rearrangement myself.
Normally another Undo click (sometimes two) will right things.
WinXP 32bit
-
Nice video.
The bone right click options were the key functional item I was missing it seems. I had been trying to figure out how to do a jumping animation without getting that floating feeling, and was fighting it out with the manual bone re-parenting and repositioning.
Four right clicks, and it's done. A nice "weighted" squat. Priceless.
-
Nice video.
The bone right click options were the key functional item I was missing it seems. I had been trying to figure out how to do a jumping animation without getting that floating feeling, and was fighting it out with the manual bone re-parenting and repositioning.
Four right clicks, and it's done. A nice "weighted" squat. Priceless.
-
This may still be a bit early, but why not...
This is a game I'm actively working on right now, and thanks to this past Thursday's build I was able to give Spriter a real trial run for the first time today.
I set things up using key frames for tweening in game, but I don't have a working importer (yet.) I just inserted a bunch of frames to the timeline at about a 30fps interval, and then deleted the off pace original key frames for this gif. This is what is causing the overly sharp transitions at the apexes. The speed of the arms and legs should be different there at the end, but it seems to have been averaged out here. Just noticed there is a color issue with the main bang as well. Anyway...
Click to Enlarge
This version is not using any sprite swapping yet. (Well other than the eye blink I added for testing.) I'll need to go back and add a couple of new feet sprites with bent toes to add the "push" to her step. I think I may need a few shirt swaps to give more of a flowing motion around the bottom too.
Here are a couple more WIP pictures using the actual current game content. I think I am happy with the new stuff, so I'll just go back and clean things up a little from here.
Click to Enlarge
These were my first attempts at building a level out of a bunch of individual sprites. The first is a quick pass with a bunch of alpha blending going on. The next is a values check with the same components from the first picture. I'm not really happy with the contrast separation between the characters and the backgrounds yet, but it's getting there. The last picture is composed of basically the same sprites only I removed the alpha, and added hard edges to all the background sprites. I got worried about overdraw for a while there.
Click to Enlarge
I hope to have some interesting animations to show off soon. You guys are going to love the A4 build...
-
I'm not so sure one needs to complain about the daily builds here... might want to keep it in the backer sections.
...For what it's worth, I didn't have any of the issues you did except the z-order/scale thing. -WinXP 32bit
...and for bones you hold Alt while clicking the left mouse button in the main view window. They were added last week. ;)
I want a finished (Pro) version yesterday as well, but I have to keep telling myself to leave it alone for now. They have been saying to expect the 1.0 version in December, so until January rolls around let's not release the hounds. They have plenty of time to button things up.
As long as the public builds keep showing improvement (and fixes) it's all good.
-
A3 is out now.
You just have to look a little futher down on the main page.
Here is some linkage: http://www.brashmonkey.com/forum/viewtopic.php?f=2&t=862
-
I'm testing it out on an old XP Home box, and it works fine here.
Have you tried uninstalling it, and re-installing yet?
Do you have any malware, virus, or firewall software running during the install and first opening? Comodo firewall gives me fits with these builds, so I just switch it off while running trusted programs for the first time.
-
Nice update. It seems to have fixed all my initial Alpha issues.
One question though... what happened to being able to move the objects a pixel at a time with the arrow keys? Is it because of the way the new bone system will be implemented? I only ask because I am still fine tuning the structure of my characters, and had initially set them up with this feature in mind as a fall back point.
-
Where are you saving your files? Do you get a different result when saving a file with only one frame then when saving a file of two or more?
I had a similar issue when reloading a file, but it was mostly resolved by changing the location of the "save" folder.
Deleting a key frame was causing me a few animation headaches, but no crashes in XP.
The more info you can provide about your setup the faster they can stamp out these bugs in the new build.
The first real release isn't do until December, so there will be a few bumps along the way.
-
Spriter doesn't actually support anything.
It just outputs a simple XML like data file that can be easily worked into most any framework. That's the beauty of it.
When the first kickstarter beta came out there was a handful of guys who made a quick importer for their framework of choice. A guy over on cocos2d-iphone.org made up a parser for vanilla cocos2d to prove to the guys over there how easy it was.
Video:
Code: https://github.com/talentless/spriter-cocos2d
This code will not work with the new Alpha builds "as is" though. There have been some changes to the file Spriter exports. You can still get the original beta from the BrashMonkey main site.
By the time final Spriter version 1.0 gets released (around December as of now) then there will be a mad rush by people to get to get support to their individual platforms. I can't think of a single game engine or framework where Spriter has not been brought up several times on their main forums. Once the final file format is cemented, and a stable version is released you should be able to find what you need pretty easily.
If you need it now, and you have the coding chops, you can take this code and the new SCML file info http://www.brashmonkey.com/forum/viewtopic.php?f=2&t=751, and roll your own parser for cocos2d HTML.
Hope this helps.
-
The guy that did the cocos2d demo put all the code up, so you can just pull it and make a few modification to work with the cocos2d-x calls. If you can use cocos2d-x you can handle this.
I can't remember where he put it up. I think there was a site forum where he talked about it, and he put it on github. Just google the Spriter cocos2d combination, and it will pop up. That's how I found it anyway.
-
The PNG export is in the free kickstarter beta version available on the main site. The program has a few quirks, but as long as you save a lot, and only need the functionality it has you would be good to go.
The feature is not running yet in the new alpha builds you can download in the forums, but neither is Undo and Save just popped up, so it hasn't been removed it just isn't ready yet.
-
Thanks guys.
Lucid, I hadn't checked today, but the email didn't go through. Error: ":
child status 100...The e-mail message could not be delivered because the user's mailfolder is full."
I just forwarded it out to mail@brashmonkey.com
-
Sure, I can send you the goods, but I think I only have Mike's email. I checked your profile, and didn't see an address there. (EDIT: Just saw your email in the A2 Beta thread, I'll send the files over.)
For what it's worth (and to help explain a bit more beforehand,)
I first tried the D: location (my storage/secondary HDD) as: "D:\GameDevelopment\Wendie's Game Scratch Area\Concept Art\Character Files\Little Girl A2" In that folder I had my test SCMLs, and a folder "Spriter" which contained the sprites.
I then moved things to: "c:\Program Files\Spriter" (program default save folder) The folder contained the SCMLs, and the image folder "Spriter" as well.
I have been using: "D:\GameDevelopment\Wendie's Game Scratch Area\Concept Art\Character Files\Little Girl" with the original BrashMonkey Spriter beta build, using the same file/image folder setup.
I have continued playing with it, and when saved in the C: location only the first save moves the highest ordered sprite to the wrong location, and duplicates the lowest. If you then fix things, and save again the position is not messed up again, only the duplication problem continued.
When animating, after a few frames the sprites seem to loose their place and move around. Much like the first beta did when you left tweening on, and changed something.
-----
By grouping I was referring to selecting multiple sprites in order to move them as one. In the previous version available from the site you could do this, and create a group on the right. I am still doing this in the newest beta, I just have to reselect and adjust the anchor/pivot point on the sprites manually each time.
The following picture shows what I mean exactly just to clarify, and also at the bottom of the Objects in Frame tree you can the the duplicated top sprite the "Rear-Hand.png" It has been duplicated and place at (0,0) in the frame/scene below the character feet.
-
Spriter 8/17/12 build
Using Win XP 32bit
Using my default character which includes 26 sprites.
If I save a single frame to the D: drive in the folder above the images when I load it back up the File Palette loads up correctly, and the Objects in Frame list will list the correct images and attributes, but the thumbnail image is absent. You can view the sprite details, but clicking to select a sprite will crash the program. There is also nothing showing in the Scene window.
If I save a single frame to the default Spriter folder I can reload the single frame, and everything comes up correctly with two exceptions. The highest Z level sprite is in the wrong location, and just under it the lowest Z level sprite has been duplicated.
Saving seems to work in the default directory as long as there is at least two frames, but upon reloading there is now a gap in the animation when looping. (There also seems to be an issue with two pivot points being altered during the animation slightly.)
Manually adjusting the scale in the OiF menu after using the Scene window tool crashes the program.
After grouping items the pivot points on the individual sprites get weird for a bit. Once I had the sprite start orbiting the pivot point and when trying to move them they would float back into the same relative starting positions. All the funny business goes away after activating another sprite, and then returning to the offending sprite.
Once I get over 11 items the Z order stops defaulting to the top randomly when new items are added.
-
To continue the transparency post...
It could also be just one global switch that makes all but the current active/working sprite is transparent while you are trying to position things. A continuation of the current selection method.
It might be an easier/faster hack.
-
I'm playing with my full character the new Alpha2 this morning, and one thing is apparent... there needs to be a way to manually activate a transparency on sprites individually in the "Objects in Frame."
The transparency levels already used when scrolling over the "Objects in Frame" to pick a sprite would be fine. Just add a check box next to the golden asterisk to enable the transparency manually, so that it will stay active while building your scene.
It is a pain to position the "deeper" positioned sprites relative to the forward ones in the present build. I am sure the eventual "bone" system will greatly help this out, but the option for manual fine tuning would always be a plus.
Photoshop to Spriter (Photoshop Plugin attached)
in Spriter Implementations
Posted
I just got the chance to try this out myself, and I have to say that this is pretty darn nice. A great time saver.
The isaacburns additions really puts this script over the top. You have just saved me hours of transfer and setup time.