Oh excellent. I was just wanting this myself. Looks like I gotta update my runtimes.
EDIT: Cool, I think it's working (C Runtime). Of course I had to push it beyond 100% too: https://vine.co/v/MqVp5zPMEqQ
Oh excellent. I was just wanting this myself. Looks like I gotta update my runtimes.
EDIT: Cool, I think it's working (C Runtime). Of course I had to push it beyond 100% too: https://vine.co/v/MqVp5zPMEqQ
Shiu написалPersonally I use Sketchpad Pro to draw characters in, then save as PSD and open in Photoshop to do tweaking.
Yes! Sketchbook Pro is great. I used it on a project several years ago, back before they added canvas rotation. Boy do I wish it had Canvas rotation way back when.
Just thinking out loud. I realize there's way too much else to do, but I'd hate for this to come up too late.
So I'm going to have animations a year or two from now; Lets say I've got a whole bunch. One day I discover that "oh crap", my texture size is too small. I go through, doubling or quadrupling all my exported texture files. Fire up in Spine to re-run the texture packer, and .. oh boy, things just exploded in my face!!
I'd like it if I had a clear/obvious way to up-res my assets. If it was just texture files, I could easily hack my code to scale my coordinates (or with the old UVs, it would just work). But the way the Spine workflow is, I need Spine to generate the Atlases from my components. I might be able to hack something still, as all components seemed to be scaled about original image centers, but you really can't work in the Spine app after changing your asset sizes. Something like a global image scale in the Spine editor file might do the trick (plug in 2.0, or 0.5, etc).
This basically happened on Mobile. We started with tiny 480x320 iPhone screens in mid 2008, and hit 2048x1536 iPad 3's in early 2012 (less than 4 years later, we needed 4x the resolution). I lucked out doing the art for my 2008 game with 1080p HD in mind, but I wasn't expecting to have a 5" 1080p phone in my pocket a few years later.
Fast forward to today, 4k is real. If I wanted to, I could go out buy a bargain 4k TV for ~$1500, or a good one for $4500. That's pretty dang high-res, maybe too much, but we have companies like Samsung threatening to release 4k phones next year (CES just a few weeks away). Like it or not, 4k is a thing.
So really, all I'm saying is it shouldn't be much of a stretch to want to be 4k ready.
For performance reasons, it makes sense to work in 2k. The laptop I work on is not 4k; It's not even 2k. But having a clear way to go to 4k and beyond would be comforting.
Nate написалI hate you guys.
Thanks Nate!
Yep! I realize there's waaaay too much to do, but I had to bring it up.
Well in the case of Street Fighter, you can just look at the image to see all the kinds of boxes. Every box there means something:
Not seen in the image are filled blue and green boxes for throws and projectiles. There's also a flag to say whether a box is not affected by projectiles (or only affected by projectiles). I'm sure I'm missing some too.
But basically, you can have a lot of boxes.
On a related topic, I actually want more bounding volume types. Polygon boxes are "fine", general purpose and all, but Circles, Capsules, and Oriented Bounding Boxes are useful too (not to mention cheap to calculate collisions for). Especially given that we make things out of multiple images in Spine, it's reasonable to expect I may want a collision box for every image in the body. If I need to use multiple boxes anyway, they may as well be extremely cheap to calculate collisions between. We can't exactly deform polygon boxes.
Right, I've been browsing the forum and just come across mention of folks using "Longer#Names" to sneak in properties of things. I've even come across similar suggestions. Still, this information is closely tied to animations themselves. Specifying damage values in an animation is understandable not ideal, but specifying what parts deal and do damage, send and receive other messages, is important. It does look like a lot of cases can be worked around using "Longer#Names", but this is still not ideal.
Bit of a bump, but this is exactly what I'm looking for now.
I want to be building animations with fully swappable components. Switch out the head, the tail, etc, where the geometry of each can actually be different. Skinning works for artwork changes, but not for skeletal changes. Plus it's all or nothing with skins. The above feature would technically allow me to have body skins, head skins, etc.
Oh boy, I can see this leading to a very big Spine file.
Adam написалa checkbox named "do not export"
Yeah, this is something I would like too. Either to simplify a complex rig, or for making more sophisticated dummy/proxy objects that you only use for building the animation.
Hi,
Guess I may as well get my forum badges.
I backed both Kickstarter Projects. mike@sykhronics.com, as either Michael Kasprzak or Mike Kasprzak (I forget which).
Regards,
Hey,
Generally speaking, I'd like to be able to do this:
Loading Image
http://forums.shoryuken.com/discussion/ ... itbox-data
https://sites.google.com/site/scrubfigh ... -hurtboxes
Create Bounding Boxes and assigning a property to them to say what kind of bounding box they are. Hitboxes, Hurtboxes, boxes that send messages (start blocking), etc.
Right now, bounding boxes can only be used for one thing.
Nate написалHaha, very cool documentary on the evolution of your runtime.
I also like your background.
Thanks. My go-to background is usually an off-black (dark red), but I've had this noise shader for a while that's just dying to be used.
Nate написалI'm quite familiar with having everything FUBAR and trying to figure out what transforms are bad, etc. It's all worth it when it comes together in the end! :party:
Indeed. I got to do ports to a lot of different devices, many which don't even exist anymore, and the process is always the same: Get those white boxes up, then get them to draw right.
And yeah, you get to see interesting glitches along the way. Sometimes, they go disco. :rofl:
Loading Image
Just in case anybody else is porting Spine to their own SDK (native OpenGL, Direct3D, or whatnot), here's some glitched images and thoughts on what was broken then fixed in the next image.
Loading Image
Loading Image
Loading Image
Loading Image
Loading Image
1. No texture
2. I forget exactly, but something with the UVs
3. 4 Vertices are being added, but render mode was Triangle Strips not Quads (which is deprecated in current OpenGL, and unavailable in OpenGL ES and Direct3D FYI)
4. Alpha blending not enabled.
5. Triangle Strips with 6 vertices per sprite, when it should have be Triangles (not strips)
Loading Image
Loading Image
Loading Image
6a. Rigid Texture (pixely). Is the texture filtering mode. In OpenGL this is GL_NEAREST, and what you want is GL_LINEAR.
6b. Texture fringe (along edges). Can fix either by modifying the artwork (including color in the 100% alpha areas, even though it's transparent), or by using a pre-multiplied alpha blending mode (and multiplying your RGB channels by the alpha value).
7. (6 not fixed until next image) Test art assets contain 2 glitchy looking transformations (used by Spine devs to test blending features). Edit the JSON animation file if you want to remove them.
8. Done. Spineboy.
It was red yes, but in my case it affected the face too... probably more than anything.
Here's a shot from when I was trying to track down the problem.
Loading Image
Looks like your blending might be off. Yours looks a bit too neon to me (additive?).
Hey,
Using the SFML C++ library as reference, I now have Spine animations playing in my codebase. Here's a Vine:
Anyways, I noticed the Atlas has a function newAtlasPage which you overload to load your textures from disk to VRAM, but there's no function/hook I can use to clean up (no deleteAtlasPage).
Great work BTW. Loving Spine.
PS: The disappearing Torso and Interpolating-to-Red head in the animation file took me a while to track down. Good thing JSON files are so easy to read.
Hey,
Just a minor feature request. I use a non standard keyboard layout (DVORAK), so CTRL+Z isn't a one handed gesture. That said, many apps have little Undo/Redo buttons in the UI, so I compromise by using those. It would be nice if Spine also had such buttons.
Regards,
Mike Kasprzak