phaser
phaser copied to clipboard
phaserjs
[Spine plugin] Atlas file is not read properly unless it starts with a newline
Version
- Phaser Version: 3.52 and 3.55
- Operating system: Windows 10
- Browser: Chrome 91
Description
When using the Spine Plugin that is bundled with Phaser, the atlas file is required to start with a newline to be read properly. If this newline is not provided, it will skip the first "page" of the atlas format and a black box with a green cross (probably chrome placeholder image) will be displayed as the spine attachment.
Yes, currently in the atlas file, the texture filename requires a newline before it to be parsed as a texture filename. I don't know if this newline is required but it is generated by the spine export and esoteric say the format is 'based' on the libdgx atlas format which doesn't appear to say that - but it is said that a newline should separate pages.
The atlas loader in the spine plugin correctly parses the file and pulls out the texture filenames, regardless of whether the file starts with a newline or not, however it doesn't trigger the texture file loading, this is done in the onFileComplete method and that code also parses the atlas text and there it does require a leading newline.
I could update this I guess, but as Spine itself always includes the newline I'm curious where these non-newline files are even coming from?
I came across this oddity a while ago when I wrote a util to merge/split atlas files. Decided it was what it was, these files are hardly ever created by hand. Having a leading newline meant I could cat atlas files together, then the page separator was always present, maybe its something to do with that.
@orjandh did some software tool create the .atlas you had a problem with?
The animations were comissioned, but I am pretty sure they use a newer version of the Spine software.
Ah, yup just tried it, the spine V4 export does not have a leading newline in the .atlas file, whilst exporting from the V4 editor to target V3.8 does maintain the leading newline.
Latest Phaser V3 only handles spine V3.8 exports. @orjandh the quickest solution would be for you to try your anims re-exported at 3.8, depending on their construction and V4 features used, this may or may not work. Failing that, re-work the V4 anims until they export at V3.8 correctly.
Or investigate using the V4 spine runtime in Phaser3.
I will keep that in mind for next time. I have been modifiying most of the data files to make them work.
If the atlas reader is a part of a spine runtime that is maintained by someone else, then I understand this will be a unnecesarry change.
Some hints about the .atlas format changes in V4 here http://en.esotericsoftware.com/forum/Spine-Unity-3-8-to-4-0-Upgrade-Guide-15981#p70717
Ah, yup just tried it, the spine V4 export does not have a leading newline in the .atlas file, whilst exporting from the V4 editor to target V3.8 does maintain the leading newline.
Interesting - to me that implies quite clearly that 3.8 files should have newlines at the start. As the Phaser Spine plugin doesn't support v4 at all yet, I'm comfortable leaving it like this. Will revisit it when / if we upgrade to the v4 runtimes.
Closing as I'll cover this change when we release a Spine v4 version of the plugin.
sounds like V4 plugin is on the horizon. I hope this is an additional plugin so gives a choice of using either v3 or v4.
It sounds like a good idea to support both. Maybe we simply can do
- phaser/plugins/spine/dist/3.8/
- phaser/plugins/spine/dist/4.1/
I'll be amazed if the runtime APIs haven't changed as well, rendering some current calls in the plugin / SpineGameObject / SpineContainer broken in Spine 4. I doubt it will be as simple as just splitting the dist folder. Probably have to split the entire plugin src and maintain two versions.