Trumgottist
-
Posts
87 -
Joined
-
Last visited
-
Days Won
2
Content Type
Forums
Store
Gallery
Downloads
Posts posted by Trumgottist
-
-
If you're the only one using the program, the answer is yes.
-
-
I don't think so. Using bones is how you get that connection.
-
no one?
Maybe ask on a Construct forum? (I'm assuming such things exists - I know nothing of Construct.)
-
I can't answer that - I just wanted to give a solution to the problem that works with the current version of the program.
(But as a game engine programmer, I'm pretty happy with this limitation, as it matches how my engine handles all resources.)
-
a feature to stop us using multiple source folders?
You can use multiple source folders, as long as the Spriter file is at a higher level than those, so it won't have to back up the tree to find the images.
Here's an example of how two animations can share images while still having things neatly organised:
/project/goon.scml
/project/goon/body.png
/project/goon/hand.png
/project/tools/hammer.png
/project/hero.scml
/project/hero/body.png
/project/hero/foot.png
/project/tools/hammer.png
-
(I think this is going to be a normal issue for all Surface Pro owners)
Have you filed a bug report with Intel? Then hopefully, they'll fix their driver bug (I'm assuming that's what it is) in a future driver update.
-
You probably want to read this.
-
It's something that's been mentioned for the future, but right now the answer is: No, you'll have to calculate that yourself.
-
Dramatically simpler and still feature complete? I'm very interested!
-
I haven't started implementing Spriter support in my game engine yet, so any code is interesting, particularly if it's C/C++.
How does your code compare to the generic C++ API?
-
Take a look at this script for Photoshop. You may find it quite useful. Among other things, it will trim the sprites for you before exporting them as png.
And in the future, Spriter will be able to scale down animations too, so erring on the side of too large is better than discovering later on that you want larger sprites and having to re-do them.
-
Wouldn't the most important factor be the final target? I think somewhere between "as small as you can make it while still looking good" and "as large as you can make it without taking up too much memory" is a good choice. (I tend to aim closer to the first statement, as I'm making freely downloadable games, but to me "looking good" does require plenty of pixels.)
Yes, I'm aware that's a very vague answer. If you want a more detailed answer, you could tell us what you will be using your sprites for, and what kind of style you're aiming for. (Or, just wait for someone else to give a different kind of answer.)
-
If you've lost your serial number / product key, you probably need to e-mail Support@brashmonkey.com
-
B3 is the latest, so you'll want to upgrade.
-
Ok,got it.
The problem is that the blurry effect is "inside" Spriter before exporting.Is this only visible in Spriter and will be ok on the exported animation?
Yes. The blurring is caused by the way the image is drawn (the reason for it is simple antialiasing), and will not have any effect on the animation itself. Unless the game engine is doing some antialiasing of its own, there'll be no blurring.
-
Could you please elaborate on that? I am a graphic designer and not a developer so "language binding" is a little too much for me.
It means that Spriter works best if the game engine you're using supports it. Then you can use the original images and the spriter file, instead of exporting the animations as a series of PNG images. This has several advantages, including smaller file size, possibly greater flexibility, and that your problem won't be an issue because the rendering is done by the game engine.
-
Yes, it's due to the upscaling of the image. It won't have any effect on how the animation looks in your game (unless you're using exported images rather than the animation directly, of course). The developers have stated that this anti-aliasing will be optional by version 1.0, so your problem with blurry images will go away, eventually.
-
My particular situation is that Shiva does not support dynamically loading .png files, they need to be .jpg (no transparency :( ) or .tga. So, a .tga would be a solution to my current problem.
You could try a batch converting program, such as XnConvert.
-
MikeHeart: It's not called a beta yet. (Look at earlier threads for the history of the thing and reasons for delays.) Regarding documentation, it's not written yet, but if you look in the "Help and Tutorials" section in the forum, you'll find videos in the sticky posts at the top that explain how the program works.
(Oh, and dislike the program if you want, but that rude tone is uncalled for.)
-
It seems to work in CS4 too!
Opening the test file gave me some errors:
"This document contains unknown data which will be discarded to keep layers editable. […]"
and
"Some groups were found corrupted and repaired."
Running the script on that file gave me a Spriter file and accompanying png files, so that it looks the same as the psd file when it's loaded into Spriter. But I got no bones.
The problems with it are obviously the 5 nested groups limit you mentioned. Instead of a "root" group, I get an empty and hidden "root" layer. If I remove enough parts so that it fits in five nested groups, put the bones in a root group, and hide the bone layers, I do get bones. Odd looking (all horizontal - but I guess that's how it should be, as the bones in your sample spriter file looks the same), but functional bones.
So thanks! It is indeed working in CS4 too. The bone creation is less useful due to Photoshop's group limitation, but even without that, I'm sure that it'll prove useful!
- WasdfriKn, Quitleusere and Alealokato
-
3
-
Cool - I'll try it out.
-
Would it be possible to make this backwards compatible with CS5?
Or CS4, for those of us who can't afford to upgrade?
-
Cool. As a programmer, I completely understand.
<500 lines of code Spriter implementation
in Spriter Implementations
Posted
How's it coming along?