I don't know if this has been mentioned before but, "it would be cool"(tm) if spine supported this:

http://stackoverflow.com/questions/12414708/correct-glsl-affine-texture-mapping

http://www.bitlush.com/posts/arbitrary-quadrilaterals-in-opengl-es-2-0

I've animated a few meshes now and keep bumping into the "affine texture warping" issue:

 Loading Image

Edit: this is relevant to the runtimes also as the UVQ texture coordinates need calculating.

Any thoughts?

Cheers,

T.

Majicpanda a écrit

One more question to add to this. If we plan to have say 30 enemies attack a player all at once with 4 players in multiplayer is there going to be anything to watch for performance wise on PC/OSX?

We will be using the essential most likely to begin with, but how much a performance increase would there be with meshes on the Pro version and will it be needed for something like this with 30 or so characters on screen at once? I say on screen, but would any off screen be taking up cycles as well?

Hiya.

Just check if off screen and don't process?

You'll more than likely have a screen bounds check anyway yeah?

T.

That sounds like a good feature.

Hello.

The guy that I'm working with has just had a weird error when exporting.

His skeleton was named the same as one of the images he was using as an attachment. Plus, he was exporting to the same directory. (I know :giggle: ) So the the export process ended up deleting the png attachment image and the atlas file was 0 bytes.

I know it's a stupid error (operator error), but maybe some kind of dialog to warn the user that they're about to do something stupid would be in order.

Cheers,

T.

Cheers!

Yeah, been at it (game dev) for 25 years now, from assembler to C# / Java, tiny projects to 3 year epics. Just not a huge fan of the style, it's making it more complex than it has to be. :angel:

God I'm getting old.

Cheers for that, good to see how others do it.

Yeah (re multimap in c file), I haven't added my stuff to the c file.. I just copied the structs to my cpp file. Again, this isn't ideal (hence my request for the header exposed structs), but I'll settle for it.

IMO (just sayin' ) I don't like the Spine-C runtime code. Yeah, it's all very clever and all that, with the emulating of inheritance etc, but it's not very readable / extendable. Would much prefer a proper C++ implementation.

I'll make do with what I have though. I don't have time to maintain / write my own C++ implementation over and above my current duties.

Hello. Probably a question for Nate (or whoever did the Spine-C runtime).

I want to get a list of attachments when using Spine-C.

I can use the code that's in spSkin_getAttachment:

void spSkin_getAttachment (const spSkin* self, int slotIndex, const char* name) {
   const _Entry* entry = SUB_CAST(_spSkin, self)->entries;
   while (entry) {
      if (entry->slotIndex == slotIndex && strcmp(entry->name, name) == 0) return entry->attachment;
      entry = entry->next;
   }
}

It's easy enough for me to hack up a solution using the above, but the spSkin_getAttachment function needs the "spSkin" and "Entry" structs that are defined within the source file rather than the header. So, any solution I come up with needs to be in the Skin.c source file (which branches the runtime and creates a ball-ache when the runtime changes in the future i.e. all my changes need to be folded back into the official runtime if it changes).

Is it possible to move the struct defines into the Skin.h file? So I can just include the file and have a, say, SkinExtensions.c / cpp file that doesn't change Skin.c?

Cheers,

T.

This is what I've come up with in case anyone wants to use it... Nothing complex, but the issue still remains that it's hard to extend the Spine-C runtime system with minimal merging / branching.

typedef struct _Entry _Entry;
struct _Entry {
   int slotIndex;
   const char* name;
   spAttachment* attachment;
   _Entry* next;
};

typedef struct {
   spSkin super;
   _Entry* entries;
} _spSkin;


//get all the attachments for the given skin / skeleton
void spSkin_getAttachments(const spSkin* skin, const spSkeleton* skeleton, std::multimap<zString,zString>& attachmentsOUT)
{
   const _Entry* entry = SUB_CAST(_spSkin, skin)->entries;
   while (entry)
   {
      spSlot* slot = skeleton->slots[entry->slotIndex];
      attachmentsOUT.insert(std::make_pair(zString(slot->data->name), zString(entry->attachment->name)));
      entry = entry->next;
   }
}

Anyone have any ideas about this?

Hello.

What is this option meant to do?

It doesn't appear to make any difference whether I have it checked or not.

Cheers,

T.

1. open spine-boy project
2. enter create mode
3. double click any attachment
4. crash

Spine Launcher 1.8.20-full
Windows 8 x86 6.2
Java 1.7.0-u6-unofficial Oracle Corporation
OpenJDK Server VM
Up to date: 2.0.22
Licensed to:
Spine 2.0.22 Professional, LWJGL
NVIDIA Corporation
GeForce GTX 550 Ti/PCIe/SSE2
4.4.0 NVIDIA 344.11
Started.
An unexpected error has occurred:
java.lang.IllegalArgumentException: Invalid selection: xD added to xy selection
   at qo.c(SourceFile:136)
   at zh.a(SourceFile:235)
   at yt.a(SourceFile:60)
   at qo.b(SourceFile:55)
   at lx.b(SourceFile:101)
   at ly.b(SourceFile:240)
   at cV.b(SourceFile:195)
   at lz.b(SourceFile:298)
   at cV.b(SourceFile:169)
   at o.b(SourceFile:96)
   at o.b(SourceFile:96)
   at av.e(SourceFile:326)
   at ah.run(SourceFile:224)
   at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:251)
   at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:711)
   at java.awt.EventQueue.access$000(EventQueue.java:104)
   at java.awt.EventQueue$3.run(EventQueue.java:672)
   at java.awt.EventQueue$3.run(EventQueue.java:670)
   at java.security.AccessController.doPrivileged(Native Method)
   at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76)
   at java.awt.EventQueue.dispatchEvent(EventQueue.java:681)
   at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:244)
   at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:163)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:151)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:147)
   at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:139)
   at java.awt.EventDispatchThread.run(EventDispatchThread.java:97)

Sorry to semi hijack this.. but...

Is it the case then that there will NEVER be dynamic parenting in Spine?

Ah ok.. cheers.

That works fine, I don't have any FFD keys.

Thanks!

Hello.

Not sure if I'm missing something here.

I have my character rigged up and animated and wanted to now add some different coloured skins to it.

The different coloured skin images are identical to each other apart from the skin tones, highlights etc.

The question is.. Do I need to re-rig / re-weight these images / attachments for each skin?

Is there any way to copy the weighting / mesh from the existing mesh to the new one?

Cheers,

T.

Pharan a écrit

Thanks so much for you work on this, tonyc! It's a huge help!

-NOSKIN tag?

Aye, just include the string -NOSKIN (minus no skin) on the folder name in your Photoshop project and the layers within won't be made into skins.

e.g. I have the layers "leftarm" and "rightarm" in the folder "arms-NOSKIN". The slots "leftarm" and "rightarm" are exported to the "default:" skin instead of "arms:" because of the -NOSKIN tag. I haven't fully tested skins inside -NOSKIN folders yet so BEWARE! :o

Hello.. I've updated the main post with my latest version.

I found the ignore layer bug and fixed it.

The latest version checks if the layergroup / folder name in Photoshop has a "-NOSKIN" tag in it and doesn't create a skin for that layergroup / folder. It's handy for keeping your Photoshop files in order and not having millions of layers in the root of the doc.

Also, the script will now remember what your options were last time round and use those.

Use it if you want.

Enjoy!