tombmonkey

I don't think I can spare time to make height maps for all the images, since I'm already crunching hardcore to try and get a project finished before the year is over. I made enough maps to complete the standing and walking animations, I didn't know normal maps required alphas, can't you make normals using the height maps in the files? I painted them to get a volumetric look, and they certainly looked well in crazybump preview window. The effect is good even when normals where made from just 1 height map. Or, could you just load the head normal map and place the head spinning alone with a couple fixed position lights so we can see if in fact the normals adapt well to rotation. In your example this is not clear since the light is always the same, and the normal mapping is a bit confusing. I'm sorry for being a pest, but I'm on the fence if I should back sprite lamp since I'm on the poor side and I can't afford to buy stuff I won't end up using. If it actually works like you suggest and it can be used with skeletal animation then we are in for some crazy looking stuff coming from indies. And bwwd seriously, if you are not interested in this, just stop posting about it.

Here is the file with normals: http://www.sendspace.com/file/zf2hsx I know it's probably gonna look hideous for reasons like: the character wasn't designed to work with dynamic lighting, it's hard to get a decent normal map with just 1 height map (this is why sprite lamp is awesome for 2D artists) and because I rushed the making a bit; but I'm still very curious to see how it looks. Maybe Mike can move all the sprite lamp discussion to its own thread in the open topic section of the forum.

Trixtor you seem to understand more of this than most of us. Just a question, if each individual part of your fat guy had a normal map, could you calculate the lightning so that it makes sense? From my understanding of normal maps, if the arm for example has a normal map, if the light on top of it, and you rotate the arm, the "top" part of the normal map would be always illuminated, no matter the rotation.

Replace the word "frame" in your quote with "image". I think that answer is written in the context of frame-based animation. For the kinds of animations we're doing here, a lighting profile for each body part should be enough. (It seems sort of similar to how Double Fine's Broken Age handles lighting.) But as others have said, handling that is more a feature request for an engine than for Spriter. Umm no, think about it, sprite lamp depends on having iluminated images from all 4 angles to get a good effect, if you where to make these 4 for a body part for use in spriter, as soon as you rotate the body part the lighting will be all wrong and sprite lamp will produce an erroneous normal map, the body parts will be hit by light in all the wrong parts and the 3D effect will be lost and become a mess. They are going to integrate sprite lamp to spine so I'm curious is they do something inside sprite lamp to fix the issue I mentioned above, since you would need to recalculate the normal map every time a part is rotated.

So, unless your game has very few frames of animation, have a lot of people to work on assets or have all the time in the world, sprite lamp is quite useless regarding animation, specially with work from software like spriter where the main purpose is to have animations running at high fps and cut corners regarding manwork. On the other hand, I see this to be quite handy to create some nice lighting effects in backgrounds and other non animated assets, again it depends on the art style of the project.

From what I saw on the video, you could use spriter combined with sprite lamp together to get those results, instead of having them add more features to spriter, which is more in need of optimization than new features. Thanks for bringing that up to my attention, quite interesting and could easily be combined with spriter to get good results, too bad I'm too much of a crap programmer to even hope to be able to use normal maps.

KFII try using CCleaner to fix your registry.

I'm getting very low frame rates with b5.9. I used fraps to get this measurements, on b5 I get an average of 15 fps on the port, on b5.9 I get an average of 7 fps. This is very strange since it seems to be locked at that speed instead of being a hardware issue, since I can disable showing bones and sprites and it will stay set at 7 fps. I'm measuring using the rat file I sent to mail@brashmonkey.com due to a different situation. Also, do I have to keep the "missing image" images that get created on the new version? I got a bunch of these from a few files I moved, but the old location is not being used on any animation.

Holy sheet no wonder it took so long, that's a lot of new stuff; far more than what I thought would be added. Besides the resize function what is missing towards 1.0?

Are there any changes in the sclm file format that could make a b5 implementation stop working? Or I'm safe just by not using any of the new features? If there are then I will have to sit several upcoming versions.

Simple one, the ability to lock animations so they can't be changed. Much like the lock in photoshop. At this point I'm working with spriter almost fulltime, I got both of my clients to implement it within their engines so I'm pumping animation like mad. I usually copy and paste poses a lot to save time, sometimes my animations will get messed up and I don't know whether it's me changing them accidentally or if it's a bug or something. I have had to edit my .sclm files with notepad to fix messed up animations so much that it isn't even funny. I have noticed that animations tend to get messed up after a paste fails: copy from one animation, paste into another and the pieces will get pasted in wrong positions, with wrong scales and wrong rotations; the only pattern I have managed to find is that it usually only happens when I'm pasting to an animation whose first frame is pasted from another animation, and the first frame isn't the first frame of another animation (maybe not all necessary data is being copied to suffice being a first frame?). Anyway, if I could lock animations at least I could know if it was actually me dragging stuff around of pasting frames where they shouldn't be. I have come across a lot of once in a while bugs, which I don't report simply because they happen a few times and never more, and I have no clue as to what caused them. One of the set of characters I'm currently working on is rather complex, some reaching almost 30 pieces, for these using onion skins seem to trigger a lot of bugs which don't happen with simpler characters; bugs like: incomplete onion skins(not all parts are drawn), onion skins frozen on screen, all the character becoming the color of the onion skin, character gets stuck in position (when moving something it will jump back to it's starting position when the mouse is released), again, most of these have only happened to me a handful of times, and restarting spriter or reloading the file fixes them.

Is there any particular reason your game HAS to be pixel art? There are infinite amount of styles you can resort to that are not pixel art. I often like to look at either flash games or cellphone games for inspiration on economic styles, normally, it's better to adapt the style to what you can do, instead of being limited by what you can't.

At this point, to me, bwwd is looking like a lonely guy because stickman doesn't have a forum. That or a desperate chump posting his work in every place he can in hopes of getting some work (you are on spriter forums, it makes no sense posting the stuff you made on another software over and over and over). He seems to think that his animation style is the end be all of animation, and we should all either work like him or admit our inferiority. He comes to a skeletal animation software forum to say that bones are limiting and the software is crippled because it doesn't accommodate his workflow. He deems direct playback useless because he got 4 characters with a handful of animations and no variations each running on a cellphone. In over half his posts he mentions stickman and how great it is. I think we already know why they don't like him over the spine forum. It's safe to assume that almost everyone with animation experience on this forum has worked with another software at some point, yet this guy is the only one who keeps talking about other programs, steering the conversation away from spriter over spriter's forums. I have a license for Toon Boom Animate Pro, and I deem it the best animation software on the planet, and I would use it if I wanted png exports, yet you don't see me wailing over and over about how great TB is and that spriter should be like it or it will be just a crippled tool. I think it's safe to assume that most of us here are here because of what spriter can do, not because of what it can't do. In almost all other software's forums I'm used to seeing a rule about not talking about other software, I always thought it was a dumb rule, until I saw bwwd and now I wish this forum had such a rule, if you are on spriter's forum talk about spriter or gtfo.

I've look at it a bit, as well as Game Maker, and I think I'm going to go with Unity when 4.3 and the native 2d tools are released. I'm mainly worried about being limited, and I think unity will give me the most options, and I'm not shy from coding altogether. Then yeah, unity is the most powerfull of the bunch, but also is $1500, so unless you are going the yaaarrrrr way you are looking into a considerable investment. Construct is the best when getting something running fast with ease, gamemaker is far more powerful than construct due to some recent developments, but it's drag and drop is nearly useless. XNA is discontinued and it already doesn't run on newer devices, so don't go near it, you would be wasting your time. Torque2D is very powerful, but not as much as gamemaker. Then there's multimedia fusion, which is extremely weak, but incredibly easy to use.

Cool. If spriter ever gets that kind of deformation I will make sure to give you a heads up.

Then, if you are happy using rendered png's, my question would be why not keep using stickman? or use an actual animation program like after effects, anime studio, toon boom or even flash? that or using XSI or Max or Maya for the 3D if blender is as buggy as you say (it's not). For me, I would rather have them use their effort and time implementing features that will actually play a role in spriter's strengths (real time playback) instead of catering to people who either don't want to buy or don't want to learn an animation tool that suit their needs (toon boom can be quite expensive, but it's oh so awesome). Good luck getting that to run on a phone, or having large characters in hd resolution, or having an installer that doesn't compete in size with a AAA game, or getting a huge amount of characters on screen, or not eating all the available vram with only a handul of characters, or animating background elements "etc and all this weird stuff". And yes, I know a lot of animators think that animation without deformation is stiff, and they are also sensible enough to use a software that supports it, like any of the ones I mentioned above.

You may do well with 4 keyframes and curves, I personally need lots of keyframes for switching and detailing of the animation, and specially so that everything doesn't happen exactly at the same time (how would you key secondary animations with only a handfull of keys?). Also, spriter's intention is real time playback within 2D engines, show me any 2D engine doing the kind of deformation you make on stickman (hint:rayman engine is 3D, all Vanillaware games are 3D, vector images don't count) extra points if it's actually a publicly available authoring tool. Implementing such kind of deformation in an engine like gamemaker, construct or cocos2D would be so hard that at such point you are better off using a 3D engine with 3D animations disguised as 2D, like rayman and vanillaware games. If you definitely must have that kind of deformation, then I recommend using blender for animation and unreal as the game engine, both of them are free and will get you exactly the results you want: massive deformation potential of pixel based images and real time playback.

They will add sound sampling in B6, so you can set up the cutscenes in spriter using the sound.

They already know about the issue with deleted sprites. In theory, it has been fixed for the upcoming B6 release.

Switching images is a far more simpler way of using traditional animation in spriter, and the onion skins will display the proper image.

The option to show the object properties tab is not present in the window option from the file bar. So if I close it the only way of getting it back is right clicking any other tab, which can be confusing. I think the option to show the object properties tab should also be in window.

Frame by frame, very carefully. Currently there's no other way, they said they will add features to be able to do this in the future, but currently there are none.

We can't see anything if you post only the scml file, since there are no images to look at. You would need to post the scllm along with the folders and images in your project.

Good idea, and since deformations are already in place it shouldn't be incredibly hard to assign image points to bones, I think.

Next release, supposedly coming within a week: viewtopic.php?f=2&t=12651