Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8505704 times) previous topic - next topic
0 Members and 15 Guests are viewing this topic.

Re: miniSphere 4.5.11

Reply #1725 –
Vector uniforms should be pretty easy, I can probably implement it in 10 minutes or so since the framework is already in place (note UNIFORM_INT/FLOAT_VEC in galileo.c).  I could maybe also add .setColor() for setting a 4-vector using the components of a Color.

Transformation matrix access I want to use array syntax, but that's a bit tricky since it's a two-level array.  I could probably come up with something easily enough, though.  If worse comes to worst I could postpone the feature for 4.6.1 since it's not a breaking change, but I'll try to avoid that.  I'm trying to finalize 4.6.0 by the Fourth of July if I can :D

Re: miniSphere 4.5.11

Reply #1726 –
Thinking about vector uniforms I'd like to be able to do 2vectors, 3vectors and 4vectors, as there are uses for each and having the right size makes the shader more efficient.

For transformations, something like transformation#matrix[­i][j] would be great.

Re: miniSphere 4.5.11

Reply #1727 –
Follow up comment about Uniform setting, is there a way to have one function set a vector of varying lengths? As I feel that otherwise there simply end up being too many setUniform functions in the api relative to anything else, alternatively could it be possible to create an object or array of uniforms in some way then have one set function that you pass the object to as a parameter?

Re: miniSphere 4.5.11

Reply #1728 –
It would in theory be possible to have one setUniform() method to rule them all, however there's a complication.  JS only has one number type: double.  This means it's impossible to distinguish a float value from an integer if one is only using the type of the value argument.  So we'd end up with something like:

Code: (javascript) [Select]

model.setUniform("floatunif", Uniform.Float, 3.0);
model.setUniform("intunif", Uniform.Int, 5);
model.setUniform("transform", Uniform.Transform, myTransform);


Which is a lot more wordy than the current API for no benefit.

Anyway, the particulars of the API can be worked out during 5.0 development.  For now, this is what I can get into miniSphere 4.6 for you (already implemented on the trunk):
https://github.com/fatcerberus/minisphere/blob/master/docs/sphere2-core-api.txt#L846-L874

edit: Aww, syntax highlighting doesn't work anymore. :(

Re: miniSphere 4.5.11

Reply #1730 –
Quote from: Fat Cerberus – on

@Rhuan: Just implemented direct matrix access:
https://github.com/fatcerberus/minisphere/commit/5303ba45d81274b60db26e2746b679db44791c8c

I'll try to finalize everything and post 4.6.0 before the night is out.
Good work, but, is it read only or read/write? YOu say read only then give an example of changing a value (I need write access for some of the stuff I want to do)

Re: miniSphere 4.5.11

Reply #1731 –
Sphere.Game is documented as read-only too.  It just means that the property itself can't be reassigned, that is, you can't do:

Code: (javascript) [Select]

transf.matrix = somethingElse;


I need to come up with a better way to communicate that because as you point out, "read-only" in this context is misleading.

Re: miniSphere 4.6.0

Reply #1733 –
miniSphere 4.6.0 is available!  There are way too many improvements to summarize here; just look through the changelog to find out what's new. ;D

Re: miniSphere 4.6.0

Reply #1734 –
Quote from: Fat Cerberus – on

miniSphere 4.6.0 is available!  There are way too many improvements to summarize here; just look through the changelog to find out what's new. ;D
Good work.

I've now built it for MacOs and it runs fine, I had to repeat my two edits from before:
1. Adding the path hack to the assets path function (I don't like the sphere system folder being invisible which is the alternative to this) as well as removing the "if" you'd put around it in the engine path function
2. renaming panic to d_panic (as a MacOs system include of some kind defines something else called panic)

I think I'm going to see if I can build the other components as well (sphereRun, Cell etc), not just the main app then do a release of sorts.

Comments on changed graphical functionality
- the graphical anomalies are gone BUT
- my brownian motion spinning rings now look awful (I think they were relying on some oddity of how the full screen resizing worked to ake them look good before - they always looked bad in windowed mode)

Other note...
Be interested in your comments in my map engine topic, hoping to code the core of it in the next two weeks.

Re: miniSphere 4.6.0

Reply #1735 –
Quote from: Rhuan – on

1. Adding the path hack to the assets path function (I don't like the sphere system folder being invisible which is the alternative to this) as well as removing the "if" you'd put around it in the engine path function
2. renaming panic to d_panic (as a MacOs system include of some kind defines something else called panic)


Thanks, I'll fix the panic thing on my end while it's still fresh in memory.  I had forgotten about it because it's in dyad.c, which isn't my code.  I was trying to figure out what you were referring to with that, and then I just gave up and did a Find in Files to figure out what was wrong.  It'll be fixed for good now. :)

Regarding that path hack: See, I'm kind of jealous that it's even possible for you to hide the system folder on macOS.  If I could easily make a version of the engine for Windows that was entirely self-contained, assets and all and only required distributing the engine executable with a game, I would have done it a long time ago.  So you wanting to make said folder visible again is a little backwards to my sensibilities. ;)  That said, I do understand why you want things that way and actually had posted this Allegro feature request a while ago:

https://github.com/liballeg/allegro5/issues/700

While the request was acknowledged (the bug post is tagged), it doesn't seem to be high on their list of priorities.  I would implement it myself but I don't have a Mac.

Re: miniSphere 4.6.0

Reply #1736 –
I found out why objects drawn outside of the [-1.0,1.0] Z range don't get rendered.  Allegro's default projection is:

Code: (c) [Select]

al_orthographic_transform(&trans, 0, 0, -1.0, width, height, 1.0);



Which is to say, pixel-perfect for X/Y with the near and far clipping planes at -1.0 and 1.0, respectively.  Everything outside that range gets clipped.

I'm curious now, does Galileo honor Z order?

Re: miniSphere 4.6.0

Reply #1737 –
Quote from: Fat Cerberus – on

I found out why objects drawn outside of the [-1.0,1.0] Z range don't get rendered.  Allegro's default projection is:

Code: (c) [Select]

al_orthographic_transform(&trans, 0, 0, -1.0, width, height, 1.0);



Which is to say, pixel-perfect for X/Y with the near and far clipping planes at -1.0 and 1.0, respectively.  Everything outside that range gets clipped.

I'm curious now, does Galileo honor Z order?
I'm just thinking, it's probably possible to setup 3d drawing within the transformation api within sphere, now you've given full matrix access, can write all the properties to what we need them to be to project 3d onto 2d, unless allegro is going to clip it anyway?

Re: miniSphere 4.6.0

Reply #1738 –
Allegro isn't clipping it, OpenGL does--because Allegro told it to use an orthographic projection with the near and far planes at -1.0 and 1.0.  That's not hardcoded, it's just a default.

But yeah, we're most of the way there already, it's just missing an API to actually apply the projection matrix.  Setting model_obj.transform just affects the modelview matrix, I don't think you can apply projections at that stage in the pipeline.
 

Re: miniSphere 4.6.0

Reply #1739 –
I'm thinking more on the path-hack for macos.

I've had a read through your code and there are two relevent places that the assets_path function are called:

1. Finding the system directory: - for a version of sphere intended to be shipped with games having this hidden away would be fine. (though less helpful for a game developer)

2. Finding the games folder: - if Sphere is intended to be shipped with more than one game in a v1 style this is a problem

I had been thinking if it was just point 1 I could make Sphererun as a mac unix-style executable that can ignore the whole issue and be used for development and then minisphere as a deployment bundle with the system directory hidden in it, but as long as v1 is a thing (and to be honest it's more of a thing than v2 at the moment) that's not going to work.