(1) is definitely a bug, uniform values are supposed to be specific to each model.  I'll look into that.

(2) is just a documentation mistake, I've flip-flopped back and forth between full and abbreviated color components and I don't always remember to update the API doc when I do.  So thanks for the heads-up that I need to change it again.

edit: The shader bug is kind of strange.  Before a model is drawn, the first thing the engine does after switching in the shader is to set its uniforms:
https://github.com/fatcerberus/minisphere/blob/v4.5.11/src/minisphere/galileo.c#L209-L222

That's done unconditionally, regardless of which shader was set before.  In fact it seems that after every model, the shader is reset to the default Allegro one (shader_use(NULL)).  The engine isn't even being clever by reusing the shader--it's reset each time.  So I don't understand why your uniform values are bleeding over between models...

It's specifically if I have two models using the same shader if I set a uniform value for one it sets it for both, it's easy to work around I just have to set all the uniforms each time I'm going to draw anything.

I've had a look at the source in galileo.c and I could be wrong but I think what it's doing is:

looping through all uniforms set for the current model and setting them for the shader BUT the values set for the shader persist so:

A) Create model B and set for it uniforms C&D

B) draw model B -> uniforms C&D have the correct values no other uniforms are set

C) Create model F and set for it uniforms J&K

D) draw Model F -> uniforms C,D,J&K are all set, C&D with the values from model B and J&K with the values from Model B

E) draw Model B -> uniforms C,D,J&K are all set etc.

Now if each time I create a model I initialise all relevant uniforms for that model the issue would go away.

The source level options to fix it would be either:
a) add in a step of initialising all uniforms the shader has before looping through the model's uniforms
OR
b) make uniforms a shader level action rather than model level

(I think option (a) would be better)

b) is how shaders were originally implemented, but I didn't like that because you might want different models to use the same shader but with different parameters.  So I made it model-level like it is now.

I'll look into it again and do some tests.

I found it!  For each model the engine only has a list of uniforms the user has explicitly set.  So if multiple models use the same shader, and you set values for one model without setting them for the other, the other model will just skip the uniform-setting loop due to an empty list.  I think when I implemented that, I was under the impression that changing shaders would reset the uniforms already set, but it seems OpenGL maintains them.

I'll have to see if there's a way to work around it.  I can't just explicitly set all the unset uniforms to zero, because they might have default values in the shader itself.  So this is a stumper.

Shader issue: Are you sure that the shader has default values? there's no way to set any from within minisphere (per the api) Unless you mean the 3 allegro ones that the core engine provides? You could initialise all then reset those 3 or something OR perhaps this should just be a documentation point; include in the api that if a shader contains any uniforms they've defined they may get odd results if they don't initialise them for each model that uses that shader? (Maybe add vector uniforms so not as many are needed so initialising them all for each model will be less of a flaff)

Other matter:
I've been thinking more on the beginner friendly-ness (and also the needs of the project I'm half work on).

What I don't like about prim as a bridge for beginners is it ditches all the advantages of galileo and doesn't point towards its strengths which is part of why I wasn't keen on galielo to begin with; I was looking at the way prim used it and basically thinking:
"this is just unnecessary".

So I'm thinking of putting together a game graphics engine using galileo that can handle sprites, primitives, and other things AND use persistent shapes to take advantage of the speed galieleo can give; if it works out perhaps it could be a useful supplement to the core engine.

-> As a potential follow up if this goes well I'm thinking of building a galileo powered flexible map engine using tiled maps (unless someone else is already making one?)

Shader issue: Are you sure that the shader has default values? there's no way to set any from within minisphere (per the api) Unless you mean the 3 allegro ones that the core engine provides? You could initialise all then reset those 3 or something OR perhaps this should just be a documentation point; include in the api that if a shader contains any uniforms they've defined they may get odd results if they don't initialise them for each model that uses that shader?

I just meant that if a shader does something like:

Code: (javascript) [Select]

uniform float foo = 8.12;

If the engine were to zero uninitialized uniforms (to avoid the original bug), then we introduce a new bug of the default value getting destroyed.  No go.

Other matter:
I've been thinking more on the beginner friendly-ness (and also the needs of the project I'm half work on).

What I don't like about prim as a bridge for beginners is it ditches all the advantages of galileo and doesn't point towards its strengths which is part of why I wasn't keen on galielo to begin with; I was looking at the way prim used it and basically thinking:
"this is just unnecessary".

So I'm thinking of putting together a game graphics engine using galileo that can handle sprites, primitives, and other things AND use persistent shapes to take advantage of the speed galieleo can give; if it works out perhaps it could be a useful supplement to the core engine.

-> As a potential follow up if this goes well I'm thinking of building a galileo powered flexible map engine using tiled maps (unless someone else is already making one?)

The reason for Prim to exist is not really to show off Galileo but instead to provide v1-style immediate-mode primitives, which are generally much easier to understand for beginners.  It's true that the Galileo code to support them is overcomplicated, but that's the point: modern GPUs just aren't designed to work that way (if you look at how the v1-analogue primitives are implemented in Allegro, they do the same thing the prim code does).  Galileo, as originally designed by FJ, was set up to mirror the way modern graphics hardware actually works.  So if you use it for what's designed to do, the resulting code makes much more sense.

As for a Galileo-powered map engine, TurboSphere's map engine actually did just that--in fact in his case the whole map was a single Shape (I experimented with doing that internally, but large
maps ended up taking a performance hit).  I would like to implement a new Galileo-powered JS map engine in miniSphere 5.0 as well.  That's why I decided to do a 4.6 release, because there are a lot of useful changes on the trunk already and I still have my work cut out for me.

I just meant that if a shader does something like:

Code: (javascript) [Select]

uniform float foo = 8.12;

If the engine were to zero uninitialized uniforms (to avoid the original bug), then we introduce a new bug of the default value getting destroyed.  No go.

Doesn't the shader get executed at draw time hence re-doing that definition? Or is it that only the function is called at draw time?

I would like to implement a new Galileo-powered JS map engine in miniSphere 5.0 as well.  That's why I decided to do a 4.6 release, because there are a lot of useful changes on the trunk already and I still have my work cut out for me.

How about I do this bit for you so you can focus on core engine code?

Doesn't the shader get executed at draw time hence re-doing that definition? Or is it that only the function is called at draw time?

I think the default values are set up at compile time, not runtime.  The shader program itself is persistent (hence why you have a Shader object), the engine just binds and unbinds them at draw time.  Regarding your other suggestion, making it a documentation point: I would like to avoid having too many "gotchas" like that, even if they're documented, because one of the goals with the Sphere v2 API is to make Sphere code self-documenting.  If one skim overs the API and sees that uniform values are set per-model, then subsequently looks at code where one model has values set and the other doesn't, they will intuitively expect the second model to just use the default values.  So the behavior in practice should match that expectation.

The issue underlying the bug is that, in OpenGL, uniform values are specific to a shader program (and GL maintains them across rebinds), while in miniSphere multiple models can share the same program but with different values.  Like you suggested before, making uniforms shader-level would avoid the problem, however it would be less user-friendly and defeat the purpose of the Model object.

Trying to think through how to resolve that shader issue...

Possible option:
1. When a shader is compiled read back from it what it's uniforms are
2. Store those uniforms as an array somewhere.
3. When drawing a model clone the above array
4. write the uniforms from the model to the clone
5. write the clone to the shader

Just thinking on how a map engine should work with galileo, what about doing it with each layer of the map being an atlas. You have one model per layer the size of the clipping window you wish to draw in (either the whole screen or a subsection as suits) and you then use your shader to varying the texture coordinates so that only the right part of the map is in frame. (rather than moving the shape and drawing excessive amounts of it that are offscreen).

(I think the default shaders should be slightly more extensive than the ones you have at the moment in order to support stuff like that), after I've polished them a little will be happy to share the ones I'm using.

As long as you're willing to license your code under BSD/MIT, I'd be more than happy to let you develop the Sphere v2 map engine.

So it turns out that thanks to the recent fullscreen fix, I can now implement BezierCurve() and it will render properly.  Yay!

The only thing I can't figure out is why BezierCurve() is documented to just plot points along the curve, rather than making a continuous line.  Seems that would limit its utility.

Couple more comments...

1. Keyboard.isPressed(Key.Escape) gives me "Undefined not callable" - what have I got wrong? (I'm trying to cut v1 calls from any code I write but as well as still needing FlipScreen I find I've now found I still need v1 keys)

2. Transformations, the features you've given us are fine if we want to move objects around, rotate them and zoom in and out, but what if we want to distort them? Any chance you could give us read/write access to the underlying matrices? (It may already be there but if it is I can't find it).

1. Keyboard.isPressed(Key.Escape) gives me "Undefined not callable" - what have I got wrong? (I'm trying to cut v1 calls from any code I write but as well as still needing FlipScreen I find I've now found I still need v1 keys)

Keyboard.Default.isPressed(Key.Escape).  Keyboard is just the class name; you need to have a Keyboard object first to read any keys from it.  The API is set up this way to leave the option open for supporting multiple input devices in the future without a breaking change.  By the way, what's the FlipScreen bug again?  It's several pages back at this point and I don't feel like digging for it.

2. Transformations, the features you've given us are fine if we want to move objects around, rotate them and zoom in and out, but what if we want to distort them? Any chance you could give us read/write access to the underlying matrices? (It may already be there but if it is I can't find it).

No, I think you're right, I didn't provide any access to the underlying matrix cells in the API.  I don't think that's too hard to do, I could definitely add support for that to v4.6.  It'd probably be most intuitive to have array-style access, e.g. transform_obj[ i][j]

Thanks for the replies, and I agree on array style access to transformations.

As for the FlipScreen issue (it was screen.flip I had an issue with hence using FlipScreen instead) but I can't manage to reproduce the issue now, so maybe it was some other mistake I'd made.