Ok, I got the shader working, heading towards that option 2, would be nice if you could add shader support to shapes to remove an object from the code, but it works without that.

BUT I seem to have found a weird error when I draw a Model screen.flip() does not clear the backbuffer afterwards but FlipScreen() does.

That's a weird bug - the only difference between the two flip functions is that FlipScreen doesn't reset the clipping rectangle for compatibility (screen.flip does) and uses SetFrameRate rather than screen.frameRate.  Everything else should be the same.  I'll look into it later, though.

Note that Model can't be completely removed from the API because you might want to use the same Shape with different shaders and/or uniform values.  I agree that the extra complexity isn't always needed, though.  I'll see what I can do to improve it going forward.

When I'm asking for shader support at the Shape level it would need the uniform setting features as well, are you saying that model is there so you can draw the same shape with two different values at the same time by having it in different models, I'd assumed that that wouldn't work, not sure why I'd assumed this, but I had.

My "custom" shader is just the default vertex shader you'd written with two uniform floats added in that get added to the x and y components of the varying_texcoord.

FYI I'm thinking of trying to build what I'm working on out into a "standard" sprite library for your v2 api so we can deprecate .rss with something good.

Fat Cerberus, have you thought about putting "dead zones" between sprites on the atlas? If you add a 1px or 2px transparent gap, the artifacting should go away. It helped the atlases in my SSFML build, for instance.

When I'm asking for shader support at the Shape level it would need the uniform setting features as well, are you saying that model is there so you can draw the same shape with two different values at the same time by having it in different models, I'd assumed that that wouldn't work, not sure why I'd assumed this, but I had.

If I remember correctly, FJ's original design didn't allow that, but I realized there was no technical reason why it couldn't be supported, so miniSphere does allow it.

implementing this is a large undertaking

it will take me a day or so

This is pretty great.

implementing this is a large undertaking

it will take me a day or so

This is pretty great.

What can I say, I'm good at managing my time.

I started experimenting with the fullscreen fix, and I found that doing it the way I want to has an additional positive side effect: Screenshots will be saved at the game's native resolution, rather than being the physical size of the window as they are in 4.5 and earlier.  That's especially nice for fullscreen screenshots, which right now come out letterboxed at 1080p

A few more thoughts from fiddling with Galileo:

1. It seems that to apply a colour mask to a shape you either have to retexture it OR I need to add more to my shader...

2. You don't have the different blend modes that v1 has, but maybe it's best to implement these via the shader - (possible project for me this evening)

3. I think it would be good if you could  pass values to the shader at the shape level, would mean you could move a model around whilst having parts of it change colour differently, rather than needing to track multiple models.

4. For code cleanliness would be great if we could pass vectors to the shader - if I do as much with shaders as I'm thinking of now I think the uniform setting is going to get quite clunky I can obviously make helper functions to make it look neater but would be nice if it was neater.

(Yes I may have just spent a while dreaming about what I can do with glsl...)

To apply a color mask to a shape you just change the color of its vertices.  This is how Prim.blit() applies the mask you give it.  As for blend modes, you're right, that needs to be done in the pixel shader.  Allowing predefined blend modes alongside shader support seems like mixing metaphors and I don't want to make the v2 API too complicated.

Agreed on the usefulness of passing vectors.  That would be good for passing colors, for instance.

To apply a color mask to a shape you just change the color of its vertices.  This is how Prim.blit() applies the mask you give it.  As for blend modes, you're right, that needs to be done in the pixel shader.  Allowing predefined blend modes alongside shader support seems like mixing metaphors and I don't want to make the v2 API too complicated.

Agreed on the usefulness of passing vectors.  That would be good for passing colors, for instance.

But unless I'm missing something I can't re-colour the vertices without making a new shape?

I'm looking at how to be as efficient as possible with my use of shapes but at the moment unless I'm missing something the only writeable property of a shape is a texture and masking a texture is just a pain (convert to surface then draw a coloured shape over it then convert back)

-> Going to work on the shader method instead.

Note: whilst with a bit of effort I'm growing to like the concepts in this Galileo interface, I think it is nowhere as beginner friendly as the v1 graphics interface -> there needs to be clearer tutorials/guidance/something if we want programming beginners to be able to dive into this.

Yeah, that's by design.  Constructing a shape is tantamount to uploading it to the graphics card.  If I allowed the properties to be changed afterwards, I think people would tend to want to do that and then wonder why their game is so slow (every modification would need to re-upload the whole shape).  Forcing the user to construct a new one makes the re-upload explicit.  If you need to dynamically change things, it's indeed recommended to do it in the shader.

Note: whilst with a bit of effort I'm growing to like the concepts in this Galileo interface, I think it is nowhere as beginner friendly as the v1 graphics interface -> there needs to be clearer tutorials/guidance/something if we want programming beginners to be able to dive into this.

Yep, that's intentional.  Beginners are meant to use the Prim module for exactly this reason.  Galileo is the low-level foundation everything is built on, but it's definitely designed to be used as middleware, rather than the primary graphics interface for game-level code.  It'd be way too tedious to try to use it directly in game code without having a framework built on top of it.

If you do use it directly, you usually want to put it into your game's engine code. In my prototype games (mostly RTS and puzzles, but the concepts apply to RPGs) I usually attached Shapes to a character [proto]type (ie a sprite), and then had a Group/Model for each character that included the shape of the type. This is more efficient than the v1 API which amounts to immediate mode, and actually works pretty well with a prototypical object model, and for an RPG type of game (each prototype of a character or enemy 'class' in the RPG sense, or unit type in an RTS has a Shape, and each instance has a Group/Model, which means the actual sprite is the Shape, and is not duplicated between individual characters in memory or on the GPU).

Spotted two things I think are bugs, or at least aren't in line with the api as far as I read it.

1. If I have two different models using the same shader and set a uniform value for one of them it sets it for both of them.

2. Color#red [read/write]
Color#green [read/write]
Color#blue [read/write]
Color#alpha [read/write]
Don't exist, though:
Color#r
Color#g
Color#b
Color#a
Do exist and work.