Yeah, zoomBlit draws whole images, so that's not a problem.  The GPU will simply clamp to the edges of the texture.  The artifacts in your screenshot happen because the font renderer draws individual glyphs from a single large image containing all of them (called an "atlas")--and in fullscreen where a non-integer scaling factor is used, the GPU starts sampling pixels from adjacent tiles/glyphs.

I managed to avoid any of those issues by only ever using nearest-neighbor filtering for zooms. That should never cause bleedover from adjacent atlas entries.

Three questions:

a) could you use an array of images for a font instead of an "atlas"?

b) If zoomBlit handles single pixel width primitives on the surface it's drawing fine then is there a related way to fix your primitives rendering issue?

c) this idea of an Atlas sounds interesting, is this effectively like surface.clonesection(x,y,w,h).blit(x,y)?

a) Atlases are used because they improve performance.  A LOT.  OpenGL is a state machine and switching textures is expensive.  Using an atlas minimizes the number of state changes that need to be done each frame, which is very important for, e.g. text and map rendering which involve many distinct images.

b) The only thing that will fix it properly, I think, is to use a game resolution-sized texture as the backbuffer and scale that up, instead of applying the scaling to rendering operations themselves.  It's just that implementing this is a large undertaking and requires refactoring the internal flipping code, so it will take me a day or so to implement.  It's not hard, just tedious.  FJ's solution would work too, but it would lead to really ugly fullscreen since everything drawn to the backbuffer is scaled up.  I still want the bilinear filtering, just without the bleedover.

c) Functionally, yes, it's the same concept, but without the added expense of creating additional throwaway images.

a) is there anyway to expose Atlas type functionality within the API? (though without the sampling outside of the designated region)

b) OK, well I look forward to seeing fix

The sampling issue totally goes away with the fix I mentioned.  But yeah, you can already implement an atlas using Galileo, it's just kind of tedious.  It'd probably be worth adding an atlas module to the standard library (or enhance Prim.blit() to make things easier.  I'll see what I can do, thanks for the idea. 

The sampling issue totally goes away with the fix I mentioned.  But yeah, you can already implement an atlas using Galileo, it's just kind of tedious.  It'd probably be worth adding an atlas module to the standard library (or enhance Prim.blit() to make things easier.  I'll see what I can do, thanks for the idea. 

Time to learn how to use the sphere v2 graphics api, you've finally given me an incentive that has me interested It previously just always seemed like an unnecessary pain.

This probably also means it's time to bin my use of Sphere v1 spritesets as now I can just use a single image for a whole spriteset and hopefully get performance enhancements from doing so.

This is a good incentive for me too, to look at the implementation of Galileo and see if the internal wiring can improved at all.  There's a bit too much internal componentization at present and it probably does more texture changes than strictly necessary, preventing it from performing as well as it could.

So lets build this up a few steps at a time, have I got the below right?

Situation:
- I want to make a spriteset by combining multiple input images (containing body/clothing/weapons etc)
- I then want to draw parts of that spriteset (the different frames for different scenes)

1. Load the various parts as textures

2. Create a surface to be the spriteset

3. For each texture apply it to a shape and draw the shape on the surface (could use one shape over and over?)
OR could instead use a shape per texture and make them into a model then draw the model - not sure if there's any benefit to this unless you can add and remove shapes from the model easily? (can't see this in the api)

4. Convert the surface into a texture - the Sprite

5. When I wish to draw it make a shape and texture it with the sprite setting the vertex.u and vertex.v properties in order to determine which parts of the sprite are drawn?

6. Use translation matrices to move the shape around the screen when needed

7. draw the shape and flipscreen etc when wanted (or go into proper v2 mode and have a dispatch render script that draws the shape)

8. How do I change what frame of the sprite is showing, can I edit the shape's vertices' u and v properties or do I have to bin the shape and make a new one?

Follow up question:

So I can't find a way to get at the u and v values of a vertex, the transformation operations allowed only seem to get the x and y unless I'm missing something?

In light of this the only ways I can see to use a texture as an atlas are to either:
a) keep creating and destroying shapes OR
b) make an array of shapes one for each possible piece of the atlas then draw the one you want

Which of these is better? Or are they both bad? Could you create a type of transformation to edit u and v i.e. slide the texture around?

The other option to achieve the same effect on screen that I can see is to have one shape that you move around and keep retexturing with an array of Textures instead of the atlas.

Yeah, you can only transform the spatial position of a vertex, not its texture coordinates.  At least not without using a vertex shader.

Ideally you'd want to keep the Shapes around.  Recreating them all the time would be no better performance-wise than Sphere v1 blitting because you're constantly re-uploading vertices.  The idea of a Shape is that you upload vertices to the GPU once and then reuse them (as-is) over and over again using transformation matrices.  Constantly making new ones all the time defeats the purpose.

I can explain in-depth later; I'm currently at work so no time to get into the nitty-gritty.

Hmm ok I can see four ways to implement the system I'm thinking of with the Galileo API:

Option 1: A large array of Shapes textures using an atlas - have to determine which shape to draw based on certain parameters each render cycle

Option 2: One Shape per sprite that is textured using an atlas and converted into a model; I would then need to have written a glsl shader that will allow me to input variances to the u and v values of its vertices, my update code when then use Model#setInt(name, value); when needed to specify the correct u and v values that the shader would then set.
(unsure why I can't specify a shader for a shape and have to make a model out of it first) - I note I'd need to learn some glsl but I've found a tutorial already.

Option3: Creating each shape only when drawing it (using an atlas to hold the graphical data so only one texture is ever needed but continually destroying the shapes)

Option4: forget about the atlas, split the image into all of it's seperate frames so I have loads of textures, use one shape and retexture it whenever I need to change frame

The best approach, IMO, would be to create one Shape per sprite with the corresponding texture coordinates for its position in the atlas.  You would set the shape to have its "center of gravity" (usually the center of the collision base) at (0,0) and you could then simply use a translation matrix to put it wherever you like.

Regarding using a shader when drawing individual shapes... that feature should be possible to add, actually.  The idea of a Model is to optimize drawing for multiple shapes using the same parameters, but there's no reason I couldn't optimize internally to minimize render state changes when multiple shapes using the same texture/shader are drawn individually.

Again, you don't want to continually destroy and recreate shapes--that's no better performance-wise than just blitting the old-fashioned way.  Shapes are meant to be persistent, which is why they are objects.  Keeping them around avoids unnecessary communication with the GPU--which is quite expensive.

This is why I needed someone (other than me) to try out the new graphics API, it's been very untested ground until now.

To clarify a bit on the performance thing, when you go "new Shape" what that does is to upload the array of vertices you passed in to the graphics card.  Later, drawing it is just a matter of telling the graphics card "draw using this vertex buffer I gave you before".  Things like old-style blit have to upload four vertices on the fly for every blit, which adds up after a while.

I think you missed a point - each sprite has many frames.

E.G. if the sprite is facing North and standing still that's one frame, if it's facing north and has it's left leg forward that's another etc.

Hence my hope was that one atlas could be all the frames of that sprite, and I could move which part of the atlas the sprite's shape is textured with then:

a) I can apply transformations to move the sprite around AND
b) apply a different type of transformation to change which frame of the sprite is being drawn AND
c) only need two objects to do the whole thing (one texture and one shape)

With my option 2 above I think I can do this if I have a model as well and write some glsl.