DaleyPaley

I am trying to adapt the SFML example for my own OpenGL codebase.
I always get a crash on this line:
if (attachment->getRTTI().isExactly(RegionAttachment::rtti))
It's the getRTTI() that's the problem.
It seems that the Attachment 'type' is the base virtual type, not any derived class.
This is all a bit above my C++ skillset. Is there a compiler flag that I need to set to get it to work?
I'm using xcode on mac btw.
DaleyPaley
  • Mesajlar: 2

Mario

Please post the crash log and ideally a sample I can use to reproduce the issue. Does our spine-sfml-cpp project work for you?
Kullanıcı avatarı
Mario

Mario
  • Mesajlar: 2965

DaleyPaley

Thanks for the reply.
I can't find any log that will give you any decent info, just this kind of thing:

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0 SpineTest 0x10da07a8c spine::SkeletonDrawable::draw() + 332 (DakkoSpine.cpp:75)
1 SpineTest 0x10da08aa9 DakkoSpine::draw() + 25 (DakkoSpine.cpp:334)
2 SpineTest 0x10da67e57 main + 263 (main.cpp:33)
3 dyld 0x11a1244fe start + 462

Yes, your spine-sfml-cpp works fine. When setting breakpoints at that line I mentioned, the 'Attachment* attachment' variable in the spine-sfml-cpp project has the 'type' (spine::RegionAttachment*) whereas in my project it is type (spine::Attachment*) which is the virtual base class and doesn't have the getRTTI() function. That's why it's crashing. The problem is that I don't know how to fix it.
My knowledge of rtti is lacking, so I am not sure how the program knows the Attachment* is actually a spine::RegionAttachment*
I suspect it is a simple compiler setting, but I am not sure. I have compared all settings between my project and yours, but I couldn't find anything that might be causing it. I notice you have -fno-rtti, so I'm not sure what's going on.
I'm trying to load the owl example file, if that helps. But I have tried other files with the same result.
To make a project sample would be difficult because I'd have to extract a lot of proprietary code, so I'll save that for a last resort.
Thanks

Edit: When the skeleton is being loaded, the attachment pointer knows what type it is. But when drawing and retrieving the attachment, it forgets the type and defaults to spine::Attachment.
DaleyPaley
  • Mesajlar: 2

Mario

We have our own lightweight RTTI implementatiom so we don't have to rely on the C++ RTTI. This is why -fno-rtti works.

I'm afraid I can't tell from the stack trace what's going on, as it doesn't match line numbers in our source files. You say Attachment doesn't have getRTTI() but I don't see how you could compile yournproject if that was the case. The compiler would give you multiple compilation errors when compiling e.g. SkeletonDrawable.

Are you sure the skeletons are actually loaded without error? To me, it seems like the attachments may be null, which would explain the crash. What Spine Runtimes version are you using? And what version of the Spine Editor was used to export the owl? If you use the JSON exported owl you can see the editor version at the top of the JSON file.
Kullanıcı avatarı
Mario

Mario
  • Mesajlar: 2965


Dön Runtimes