December 27, 2016, 08:41:03 pm

Background - I've decided to start making an SRPG in Sphere (there is a 90+% chance I'll never finish it but hey...)

I'd like to have what I call a "spinning ring" as a selection cursor. This is an ellipse rolling up and down on its side - obviously I'd do this in some kind of render script but to show what this ought to look like here's some example code that simply draws the ring:

Note: I do not expect any part of the above to be final except perhaps the image creation at the top - but this does show what the spinning ring should look like. (note I probably should change this to use the ellipse functions rather than the loop of points though I couldn't immediately see how to do a multi-thickness outlined ellipse particularly not in minisphere which seems to have not implemented the ellipse functions)

Now the problem:1. from looking at that code (or trying it out) you'll soon see that sometimes the front of the ring is at the top and sometimes the back is at the top.2. Imagine you have a sprite and this ring is around their feet - you want the front to show in front of them and the back not to. The only ways I can currently think of to do this are to have two seperate images, one for the back half which is drawn before the sprite and one for the front half which is drawn after the sprite - this seems a tad painful

But anyway, to get to the point, I don't think you can do what you want in a single drawing operation. If you want half of an image in front and half in back of a sprite, then you have to split the rendering into steps like you suggest. There's no way around that.

miniSphere 5.0b2 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enormous man-eating pigs ~Rhuan

Maybe it's because I've never worked in C# or perhaps for some other reason; but to me the sphere v2 api seems incredibly complex and hard to understand.

I understand procedural code and I understand the idea of a class with properties including methods that you can make an instance of. I don't really understand many other programming concepts as I've never used them or read any tutorials on them.

The core Sphere v2 API is still pretty classical in that regard. miniRT on the other hand is implemented as modules, and I think what trips people up with require() is the extra level of indirection. Basically when you say require(whatever) that's the same as Sphere v1 RequireScript(), with the difference being that the functions defined in the script are loaded into a variable rather than just tossing them into the global scope. There's no real magic to it, it's just better organized.

miniSphere 5.0b2 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enormous man-eating pigs ~Rhuan

I'm happy with the way require works the things I don't understand are various of the specific modules that seem quite important.

Notably I don't understand how from and dispatch are meant to work - maybe if someone wrote an example game with them that I could pick apart I'd get it for now I'm happy with my largely procedural code...

Dispatch at least is easy - say you call Dispatch.onUpdate() and pass it a function. Now that function gets called every frame. Or if you call Dispatch.later(60, func), then func() gets called 60 frames from now. Sphere 1.x has this too, with its update and render scripts, the only difference is that you pass it source code (like eval) instead of a function.

miniSphere 5.0b2 (stable: 4.8.8) - Cell compiler - SSj debugger - thread | on GitHubFor the sake of our continued health I very much hope that Fat Cerberus does not become skilled enough at whatever arcane art it would require to cause computers to spawn enormous man-eating pigs ~Rhuan