C/C++ Runtimes feature request

plament

I'm using the C++ runtime but I guess the same apply for the C runtime as well. In my case I am building the rendering engine in a way that requires fast access to the attachments. Right now the only way to identify an attachment is using its name. So right now all attachments are in:

std::unordered_map<String, Attachment*>

I think will be nice to have some runtime generated int IDs and some method such as:

int Attachment::getID() const;

In that way the map will work faster. Also there will be no need to implement custom String hash function because right now String has no hash function so it is unable to add in unordered_map out of the box.

plament

Mario

You shouldn't need to look up attachments for rendering. The attachments are resolved when you set a Skin on a Skeleton, which in turn will set the Attachments on Slots. During rendering, you traverse the draw order Slot array, and do a field lookup on the Slot. Could you maybe show your rendering code so I can get a better idea about what you are trying to do?

plament

Sure. Actually I am trying to match Attachment with UIImageView. My map right now is of type std::unordered_map<String, UIImageView*> (sorry that mistyped it in the question) so later when traverse the slots in my render loop I can find which image view corresponds to the particular attachment.

The end goal is to have rendering where each attachment is mapped to UIImageView object and during the animation the engine just moves/rotates/scales the image views. I am well aware that this is not the typical implementation of a rendering and will work only for RegionAttachment so no mesh deformations nor more advanced features as well. However using such rendering engine seems the only viable approach to my problem and I can handle the limitations.

Mario

The address of an attachment never changes after loading, so it can serve as a unique ID within your std::unordered_map. Would that work for you? The issue with assigning IDs to attachments is that i'd be a runtime thing, e.g. implemented via a static counter variable. Upon construction of an Attachment, that counter would have to be fetched, assigned to the attachment under construction, and incremented. The increment is a bit problematic, as it'd require a lock so multi-threaded construction of attachments keeps the monotone ID invariant of that counter in place. I'd rather not implement locking in the runtime if possible.

plament

It is good to know that the address never changes. I think it might make sense to generate the IDs when exporting the skeleton to a json or binary alongside with the name but it is not a problem to not have it at all. I was just curious how hard will be to have some IDs. I am aware that maybe my use case is very specific 🙂

Anyway I was able to resolve the issue by creating subclass of RegionAttachment which has ID and using that subclass in my custom AttachmentLoader so my rendering works with the my RegionAttachment subclass. Hopefully soon will be able to show usage of Spine in a slightly different context 🙂

Thank you for the help!

Mario

Emitting an ID on export would change our serialization formats, something we want to avoid at all costs. Your solution is a good one!