WebGL support

[gatthias]

Hi there !

First things first, thank you so much for your work, this plugin is bananas.
Now, we needed WebGL support in one of our little Phaser games using Spine, and as we discovered this plugin doesn't handle it well so far: Scale and position weren't set and the whole rendering was flawed and invalidating regular Phaser object's rendering as well.

Putting a little work into the effort, I managed to make it :

• Compatible with Phaser WebGL rendering cycle without breaking anything (at least, not that I know of)
• Follow Phaser's Sprite (parent class) position and scale
• Take game's resolution into account (for both Canvas and WebGL)

The whole code changes aren't so heavy, but bit to much to post it here cleanly.

Would you still rather like a copy/paste or can I send a PR ?
And btw, I don't know how to PR a repo I'm not registered on, could you tell me how if you decide to go that way ?

EDIT: This is about the Spine-TS version on corresponding branch. So far I tested it with Phaser 2.8.3, and Spine 3.6.38.

Bye folks

[shibekin69]

Nice! Do the shearing / x-only and y-only scale transforms work perfectly, or are they wonky? See this for example of what I mean:

phaserjs/phaser-ce#149

[gatthias]

Hi ! Just tried your debug asset (scaling arrows), and it might be the morning but they look fine to me. Certainly nothing like the gif you sent on the other thread !
Tested it with Phaser 2.6.2 (example base), 2.7.3 and 2.8.3, with Spine exporter 3.8.38, CANVAS and WebGL.

I noticed a (unrelated) bug with 2.7.3 in WebGL though, where the whole asset-texture is drawn in addition to the animated mesh. Looks like Phaser is still rendering the inherited Sprite with it's texture-pack (which obviously shouldn't be rendered as such).
I might investigate this a bit, but it only shows on 2.7.3.

[AleBles]

I think @shibekin69 is talking about the official release that runs on the old spine runtime. As for the changes, I can accept them and add them (would be nice) but I'm not sure how fast these changes will propagate to a new release. I'd still love to PR/Add you're changes so more people may start working on the spine-ts implementation

[gatthias]

Oh right, indeed this would fix the issue :D !
At least this made me track another bug, the one I was referring to in my last post is in fact linked to gl texture bindings, so I'll try to fix it anyway. Even though I didn't see it happen with Phaser current releases, it might be this kind of sneaky ones...

As for the contribution, how can I send ? I create a fork repo from which you'll be able to pick or is there an easier way I don't know of (never did this yet) ?
Add what do you mean by new release ? Adapting modules layout, getting rid of oldSpine and so on ? Do you have kind of a release plan maybe ? I guess what I mean is I'd happily do it if it stays on a reasonable scope.

[shibekin69]

Yeah, those were exported from an older version of Spine (Essential, 3.4.02) and made to run with the current phaser-spine plugin (not the spine-ts one)

[gatthias]

Okay, then it's settled, with spine-ts this is a non-issue and works just fine. May I ask you what's missing in spine-ts implementation for you to do the switch over yet ?

As for the texture binding issue I mentioned, I just fixed it. Though I'm not sure it will stay in release, as it is highly Phaser 2.7 specific issue (bug?) which is fixed in later versions.

[gatthias]

Okay, I did some changes to lean towards spine-ts use only and polished a little. PR linked.

[gatthias]

Hey, I just noticed another bug with webgl. I used sprite position but not taking eventual camera movement into account. I'm on it.

[shibekin69]

May I ask you what's missing in spine-ts implementation for you to do the switch over yet ?

@opulisDynamics Oh were you asking me about this? If you were, well, I'm doing my animations using the Essential version of Spine. So going Pro and these lingering bugs is like a chicken-and-egg thing - there was no justification in upgrading and on features that can't be used. And I couldn't test out Spine-TS either because my animations are from an older version, and my implementations were done for the current phaser-spine. When I tried using the test build several months earlier, it wouldn't work for me. So if you guys can get this to finally work, I can try it out (at least with the Essential version features).

[gatthias]

Okay it should be good now. I kinda laughed at myself when I finally got it, well, you know the feeling.
I tried on the given example, and took care to have Canvas & WebGL rendering equivalents as it should. Tried it too on our own project with camera following player, looks good there too now.

And resolution is handled in both cases, though I might have not taken the right choice considering rendering position against SpriteBounds... I had trouble with debug bodies not taking resolution into account on another project, so I still wonder how it should really work.
So the current convention I took is the one which was matching with our game. As it may have arisen from some kind of byproduct, let me know if you know better how to handle the case :) !

And of course if you have time, please try this and let me know if any issue comes to mind.

Cheers

[shibekin69]

Awesome! How do I use this btw? Is it similar to the the current phaser-spine?

[gatthias]

@shibekin69 Well, I didn't use the old version so I'm not sure yet about eventual missing functionalities between the two, but as of instanciation and display I believe it should be the same.
Correct me if I'm wrong, and btw if there are goodies in old version missing here, do point it out ! We've only been using this lib for a couple of days, and as I said only the 'broken' ts branch, so I might be missing some nice features myself :)

All I know is there are some quirks between the README and actual code, eg ::setAnimationByName() not existing in favour to ::setAnimation(), but I believe it's mostly syntax related. I'll do have a look though, and wouldn't mind having more than a pair of eyes !

[shibekin69]

Maybe I'll try it out the new one later. The new Spine-TS should be able to support the newer features (which I haven't been able to try myself), so I don't think you're missing out on any goodies. As for speed, I've yet to compare the two. The older phaser-spine is workable enough, it just needs to have that x-only and y-only transform bug ironed out, but I don't know if that's possible.

[AleBles]

@shibekin69 My original Idea was too use most of spine-ts original code and have this lib just be a simple wrapper to wrap the renderer's supplied by spine-ts itself, a situation like that allows me to put very little effort into keeping this library updated. Looking to the changes from @opulisDynamics this still is very much true.

I also think I stripped out most of the original API in order to start working from scratch, my idea, however, was to make spine-ts a minor release so I'll be readding all those API calls and some other stuff and hopefull today (otherwise next week) I'll start prepping for release (come to think of it, for supporting the older version it'd be nicer to make spine-ts a major release, then we can easily still update/patch the old logics) any toughts on this?

[shibekin69]

Hmm.. keeping the old one separate might be a good idea, just in case spine-ts just won't work for some users. Like right now, I just tried the phaser-spine.js from the spine-ts/build directory, and the error I'm getting is immediate:

Uncaught TypeError: Cannot read property 'debugRendering' of undefined
at SpinePlugin.init (phaser-spine.js:7637)

This is upon trying to add the plugin into my preloader's preload() section:

this.Spine = this.game.add.plugin(PhaserSpine.SpinePlugin);

This works with the old version, and now the new one still won't work with me :(. I'm on Phaser 2.8.1.

[AleBles]

I'll start setting up stuff for seperate branches and spine-ts for a major release then.
As for the debugRendering I will have a look at it, together with all the kinks to sort out =)

[gatthias]

@shibekin69 You're right, spine-ts itself does provide the full bundle, but I was more thinking about eventual API changes (from phaser-spine perspective), missing helpers and so on.
I just noticed the examples on master-branch are different, I'll try to port them to spine-ts too, it may help lead the way. In fact I did just see events handling not being... handled the same.

@AleBles Oh nice, as I was mentioning you, you answered !
Indeed I'm all for this wrapper logic, Spine's ham is good we should just make a sandwich of it. They seem to be releasing quite often too so it'd be the only reasonable way.
And ok, that's what I thought about API "thinning" you did. Do you have somewhere a layout of API calls you had on older version (appart from code) or was it totally organic ?
I'm not quite sure I understand your last statement though. Spine-ts itself isn't retro compatible with older models ? But I think indeed we could keep them separated, just switch the "main" branch.

[gatthias]

@shibekin69 Damn undefineds. SpinePlugin currently thinks it will have option set upon initialisation, hence the error.
Try

this.Spine = this.game.add.plugin(PhaserSpine.SpinePlugin, {
      debugRendering: false,
      triangleRendering: true
    });

EDIT :
We should change Plugin.ts lines 54, 55 (missing optional tags):

SpinePlugin.DEBUG = config?.debugRendering || false;
SpinePlugin.TRIANGLE = config?.triangleRendering || false;

[gatthias]

@AleBles Awesome ! Let me know if I can be of any help.

[shibekin69]

Oh are the APIs not in yet? Like for example, I tried modifying the plugin adder part:

this.Spine = this.game.add.plugin(PhaserSpine.SpinePlugin({debugRendering: false, triangleRendering: false}));

Fair enough, it passes through. But when I have it load a spine animation, it gives me an error:

game.load.spine is not a function

[shibekin69]

this.Spine = this.game.add.plugin(PhaserSpine.SpinePlugin, {
debugRendering: false,
triangleRendering: true
});

@opulisDynamics Thanks for that! Let me try this out...

UPDATE: Still the same error :(. I don't know why, but this works:

this.Spine = this.game.add.plugin(PhaserSpine.SpinePlugin({debugRendering: false, triangleRendering: false}));

[gatthias]

@shibekin69 In fact, from example and our own use, it's:

this.game.plugins.add(PhaserSpine.SpinePlugin, { ... });

[shibekin69]

It just won't work :(. I'm on regular JS btw, not TS. If this matters lol.

[gatthias]

@shibekin69 No it shouldn't, I use it in js for now too. Does the given example work for you anyhow ?

[shibekin69]

Ok, if I hard set

SpinePlugin.DEBUG = false;
SpinePlugin.TRIANGLE = true;

on phaser-spine.js line 7637 and 7638

It loads up.

But passing that object is still giving me debugRendering being undefined.

[gatthias]

That is strange, maybe it has to do with Phaser not propagating arguments to potential init function (which seems to be called nonetheless). But like @AleBles said, there are a still fews itches here and there waiting to be scratched out.
Thanks for the early try though, and with those hard settings when you say it loads up, you mean up to display or just a little further down the road ?

[shibekin69]

Ok, well, I'll leave those static for now and see what other problems come up...

When I load my spine object (current implementation uses APIs from the current phaser-spine), here are things that aren't working for me (says they are not functions):

createCombinedSkin
setSkinByName
setToSetupPose
addAnimationByName
setAnimationByName
setMixByName

And well, the resulting bundle of graphics is just a mess lol. So I really don't know what's up yet.

[AleBles]

@shibekin69 Yep, I'll be adding all of those :)

@opulisDynamics I tried to update spine-ts to the latest version, but the webgl renderer is throwing me some issue, would you mind having a look over at spine-ts-update branch?

[gatthias]

@shibekin69 Nice ! That's what I meant by missing goodies :) Now here's a start of list, thank you. Actually most of those things are in .state now, but I believe this kind of wiring is what @AleBles meant, I am right ?

[shibekin69]

@AleBles - Oh no wonder lol.

[shibekin69]

with those hard settings when you say it loads up, you mean up to display or just a little further down the road ?

@opulisDynamics - Oh I mean it just loads without errors.

but I believe this kind of wiring is what @AleBles meant, I am right

Yeah I think so. I really haven't been able to try this out yet because of these odd problems, but I think I remember stumbling on these before so I stopped trying to make it work with my stuff since I couldn't understand what the problem was.

[AleBles]

Found it, was using the incorrect spine shader :P

[shibekin69]

Hey bros, I'm trying out the build now. Which Spine version do I need to export with to make this work? The "Latest" Spine is v3.7.01-beta.

Note: The current 3.4.02 exports don't work. I mean I can see transforms happening and stuff, but slot indexes can't be found (must be a different format or something), and the artwork is still jumbled.)

I'm going to try re-exporting my animations and see if this works.

[shibekin69]

Ok, I exported with 3.7.01-beta and it looks garbled right now. I see the general positioning of image parts is there, but it looks like textures are not mapped correctly. Remember that multipage atlas bug we fixed from before?

#14

It might be present here again, considering it wasn't fixed out of the box before.

[shibekin69]

Ok, I resized my animation down to use only 1 atlas page. It looks like it worked at least. It looks like that's the culprit - broken multipage atlas support is back.

EDIT 1:
Ok, so I console dump this.pages in line 5077:

this.pages.push(page);

I'm getting an array of [TextureAtlasPage, TextureAtlasPage], and it seems to recognize and get the different atlas pages. Now I need to see why it doesn't load them up onto the bone...

EDIT 2:
If I console dump this.regions in line 5114:

this.regions.push(region);

I'm getting an array of regions that define the image, and the page. In the page object, it seems to know what texture atlas file to get from since the filename of the texture atlas where the image part is located is specified here....

PS: I'm using Canvas, not WebGL. Tested with WebGL and problem appears in both modes.

EDIT 3:

From my observations, despite knowing and referencing the other page atlases, it looks like it's still using the same atlas file.

If I go to around line 9219:

SpinePlugin.prototype.addSpineLoader = function () {

and 9224:

this.image(SpinePlugin.SPINE_NAMESPACE + key, path + '.png');

It seems to load only the first image file associated with the atlas. I'll try but I don't know how to load up the other images defined in the atlas file...

EDIT 4:
Going back to line 5077:

this.pages.push(page);

I looked at the TextureAtlasPage objects in the array, and into the texture object, and found that all their currentSrc property points to the first image! The textureAtlasPage.name is correct.

EDIT 5:
I've been trying to look for this textureLoader. Dumping it to console directs me to line 9327:

inside this function:

if (_this.game.renderType === Phaser.CANVAS) {
    return new PhaserSpine.Canvas.Texture(_this.game.cache.getImage(PhaserSpine.SpinePlugin.SPINE_NAMESPACE + key));
}
return new PhaserSpine.WebGL.Texture(_this.game.renderer.gl, _this.game.cache.getImage(PhaserSpine.SpinePlugin.SPINE_NAMESPACE + key));

The problem appears to be it returns only the first image.

[shibekin69]

#70

[shibekin69]

Back to WebGL, there's a problem when using PNGs with translucent areas. Instead of blending in with the other image parts, they appear like fading to black. So if we have parts like the arm that we used a soft eraser on to meld with the body for example, instead of a smooth transition, we'd see a bruise of sort.

[shibekin69]

Btw, which Spine version is this plugin supposed to handle? 3.7.01-beta or 3.5.01-beta?

[shibekin69]

@AleBles

http://esotericsoftware.com/forum/Phaser-Spine-Making-Progress-In-Supporting-Spine-TS-9182

badlogic asking if maintainer can hit them up on contact -at- esotericsoftware.com

Maybe they can assist in some of these bugs.

[AleBles]

So a couple of things:

1. so the bruising, that's usually due to having premultiplied alpha configured wrongly according to the texture you load in, I added support for changing it when you add the spine to stage. After the the key you can now pass the boolean to enable premultipliedAlpha, it defaults to false.
2. From what I can see I took the latest from 3.6
3. Sure, I'll hit them up =)

[shibekin69]

1.) Ok, I'll try playing with this later. I tried exporting with and without premultipliedAlpha. Since I usually work with Canvas, I export with this disabled.
2.) Ah maybe that's why? I'll try 3.6. Any specific version like 3.6.01? (3.6 isn't on my Spine version dropdown)

[AleBles]

I just went here: https://github.com/EsotericSoftware/spine-runtimes
And got the latest copy from spine-ts/build :p

[shibekin69]

I'm posting some features in the WebGL version that I found not working or needs testing:

[Spine TS] Rotation - Seems to work like the canvas version (rotates the root bone), needs to be checked.

[Spine TS] Positioning - Proposed fix for canvas version. Need to be double checked.

[Spine TS] x and y properties don't move the Spine Object - Canvas version ok. WebGL version broken.
#80

[Spine-TS] Scale property doesn't work - Canvas version ok. WebGL version broken.
#78

[shibekin69]

Are you guys experiencing these problems or is it just me?

[AleBles]

Nope same here, I was just on a holiday ;)

[shibekin69]

ah no wonder. wb lol