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

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #375 –
Quote from: mezzoEmrys – on

From what I'd expect, all to almost all of the configuration options should be in a built in menu bar of some kind, like when using Visual Boy Advance, so you can change all those options on the fly. It makes a lot more sense to me, but I'm not sure how feasible it would be to change which graphics and audio plugins you're using on the fly.


Hmm....HMMMMM!

Quote from: Lord English – on

Well, I decided on a whim that 1.1 doesn't represent a big enough evolution and am now going to implement the Sapphire API from TurboSphere.  After looking at the method signatures and such, it seemed like low-hanging fruit to me. :)

If minisphere 1.1 doesn't end up being the most awesome Sphere implementation ever after this... well, I don't know what to tell you. :D


I wonder if my map engine would run in minisphere then.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #376 –
Quote from: Flying Jester – on

Quote from: mezzoEmrys – on

From what I'd expect, all to almost all of the configuration options should be in a built in menu bar of some kind, like when using Visual Boy Advance, so you can change all those options on the fly. It makes a lot more sense to me, but I'm not sure how feasible it would be to change which graphics and audio plugins you're using on the fly.


Hmm....HMMMMM!


Yeah yeah, plugin support, I can take a hint. ::)  I'll get there eventually... maybe.  Honestly it's just not that important to me and adds complexity that's just not needed for most use cases.  Maybe I'll do it when I run out of features to steal from other engines. ;)

As for Sapphire, I just need some clarification: Can a shape be created with a Surface as texture, or does it have to be an Image?  With the way the engine is set up right now I could both (surfaces and images are the same under the hood), but I'm trying to be compliant here.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #377 –
In TurboSphere, a Shape must be constructed using an Image.

I wasn't bugging you for plugins...I was just thinking...
TurboSphere could actually unload and load plugins on the fly, but the only issue with that would be that any objects constructed using a plugin that is then unloaded couldn't be used anymore, and when they are finalized bad things would happen...but it's an interesting idea.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #378 –
I'm assuming UV is normalized [0-1], but what of coordinates?  Are X/Y resolution-dependent or are they normalized too?  And where is the origin (0,0) relative to the screen?

I'm probably going to change a few names here and there in any case (Shape:image->Shape:texture among others), so it won't be a fully compatible implementation, but the general API structure should be identical.
 

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #379 –
Quote
Unless you mean an API to set the mappings, in which case... eh.  I think at the point your game wants to do that, it means you're already exposing your own configuration UI anyway, so might as well go all the way and manage the settings yourself.  Let's not invite scope creep here. :)

That's what I meant, though. Setting options. But yeah, if you're going to have a menu bar it's not going to be needed. :)

Quote
Oh, and speaking of Sir Boingers, I'm actually not a big fan on the new control setup in v2.  The 2010 version's setup was better, I think (Ctrl to bounce).  A big issue with the new controls I've had is that, when bouncing and trying to move left and float at the time, the Up input gets ignored because of simultaneous-key limitations on cheaper keyboards (the keyboard on my Core i3 2-in-1 laptop, for example).  This makes a few areas almost impossible and cost me a good number of avoidable deaths.  I think this is why old console emulators used to use Ctrl and Alt for the face buttons, actually, since modifier keys don't contribute to the 3-key limit.

It's set up so you can use the Z key too. In the end I moved away from ctrl because it felt less natural for modern games, but I can bring it back easily enough.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #380 –
You can now do this in the latest build of minisphere:

Code: (javascript) [Select]
var image = new Image('texture.png');
var shape = new Shape([
	{ x: 0, y: 0, u: 0.0, v: 0.0 },
	{ x: 10, y: 0, u: 1.0, v: 0.0 },
	{ x: 10, y: 10, u: 1.0, v: 1.0 },
	{ x: 0, y: 10, u: 0.0, v: 1.0 }
], image);
var group = new Group([ shape ], GetDefaultShaderProgram());

// vvv this requires access to the Specs Threader, though...
Threads.doWith(group, function() { return true; }, function() { this.draw(); });


Gangnam TurboSphere style!  It draws a little 10x10 textured square at the top left of the screen. ;D

I feel like I should change the order of the arguments for the Shape and Group constructors though... it feels clunky tacking the image/shader onto the end of the array literal like that, it would be more natural as the first argument I think.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #381 –
The default shader returned from GetDefaultShaderProgram must guarantee raster coords and have the origin in the upper left, just like how Sphere does it.

UV is normalized, but giving a number greater than 1 causes tiling just like how OpenGL and (or so I've heard) DirectX do it. UV is also automatically assigned to the order you gave if it is not present in the vertices. Triangles use the same coords, but just the first three. Same with lines and points.

I don't think it would be more natural with the Image/Shader first...for the primitives in Sphere, coords and parameters come first, colors and attributes come last. That's why I set it up this way, anyway.

I'll be curious to see how you tackle drawing text using Galileo/Sapphire. That's kind of a thorny spot so far. It works, but I think it could be handled better.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #382 –
Quote from: Flying Jester – on

The default shader returned from GetDefaultShaderProgram must guarantee raster coords and have the origin in the upper left, just like how Sphere does it.

UV is normalized, but giving a number greater than 1 causes tiling just like how OpenGL and (or so I've heard) DirectX do it. UV is also automatically assigned to the order you gave if it is not present in the vertices. Triangles use the same coords, but just the first three. Same with lines and points.

I don't think it would be more natural with the Image/Shader first...for the primitives in Sphere, coords and parameters come first, colors and attributes come last. That's why I set it up this way, anyway.


When I said more natural, I meant the syntax.  If a function is likely to be called with a multi-line array or object literal as argument, as here, it's awkward to have to add arguments after the literal.  See the code sample above, especially the Shape initialization, for what I mean.

I'm curious about the automatic UV assignment... how does that work?  Right now UV defaults to zero for all vertices in my implementation, which is pretty useless.  Maybe I should take a closer look at the TS source...

As for that shader, that's a vertex shader, right?  I wasn't entirely clear on whether it was that or a fragment/pixel shader.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #383 –
Quote from: Lord English – on

I'm curious about the automatic UV assignment... how does that work?  Right now UV defaults to zero for all vertices in my implementation, which is pretty useless.  Maybe I should take a closer look at the TS source...


If you are curious:
https://github.com/FlyingJester/TurboSphere/blob/master/src/plugins/Sapphire/script.cpp#L608-L679
I check the number of vertices against a lookup table with default UV numbers. As I iterate the vertices, I check if they have U, V, and Color properties, and override the defaults if they do.

That way, to blit an image you don't need explicit U and V, you just need the corner locations. This is pretty convenient, I find. It also allows overriding the color mask, but defaulting to full masking.

Quote from: Lord English – on


As for that shader, that's a vertex shader, right?  I wasn't entirely clear on whether it was that or a fragment/pixel shader.


So, this is what it would look like if TurboSphere had full shader support:

Code: (JavaScript) [Select]


var fragment_shader = new FragmentShader(frag_shader_source_string);
var vertex_shader = new VertexShader(vert_shader_source_string);
var shader = new ShaderProgram(fragment_shader, vertex_shader);

/*...*/
var group = new Group(some_shape_array, shader);


There are other things I could do, too. Maybe add the ability to specify GLSL version in the fragment and vertex constructor and inject that into the shader source? That would be nice if I also added a way to query valid GLSL versions. When the ShaderProgram constructor exists, I will add GetDefaultVertexShader and GetDefaultFragmentShader, so that you can use only a single part of the defaults. Then you'd really need to know the GLSL version.

You need both vertex and fragment shaders in OpenGL 3.2+ and 4. Since that's also valid for 2, that's how I did it. I never got much into shaders for OpenGL 2, maybe it's necessary there to?

Adding Geometry shader passes would also be a very cool extension. I don't really want to get into Compute shaders since that is an aborted feature.

But that's the gist of how I imagine the shader system.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #384 –
I think Allegro might actually support shaders... I should try experimenting with it. :)

Is Sapphire (I'm assuming Sapphire is the frontend and Galileo the backend...) part of the Pegasus spec by any chance?  It's actually been a while since I've looked at that repo and I don't remember if anything like this was specified in it.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #385 –
Quote from: Lord English – on

I think Allegro might actually support shaders... I should try experimenting with it. :)

I wanted shaders to really be optional just because I didn't want the engine to necessarily use OpenGL. GLSL shaders would be an extension to Pegasus.

Quote from: Lord English – on

Is Sapphire (I'm assuming Sapphire is the frontend and Galileo the backend...) part of the Pegasus spec by any chance?  It's actually been a while since I've looked at that repo and I don't remember if anything like this was specified in it.

Sapphire is the name of TurboSphre's implementation (well, the whole TurboSphere graphics plugin). Galileo is the name of the API.

The spec is in the api/ts directory of Pegasus. I just updated a week or so ago, based on what TurboSphere actually implements.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #386 –
Oh, good to know.  I will rename the extension to "galileo-api" then.  :)

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #387 –
Wow, just took a look at the Galileo spec and it really is a ridiculously simple API.  I imagine it could be deceptively powerful in the right hands, though.

My only real gripe is with the way Vertices are treated.  It specifies a full constructor for what is ultimately just data.  And what's up with Shapes not being able to share a Vertex?  That's just silly. :P

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #388 –
Shapes are sort of passed by value. In TurboSphere, there isn't even a true vertex constructor, they are just objects. When a Shape is constructed, the data of all the Vertices is copied.

Shapes can 'share' a Vertex, but changes to the Vertex do not affect the Shape.

Re: minisphere 1.1b1 (stable: 1.0.10)

Reply #389 –
Well, not even 24 hours later, my Galileo implementation is almost finished (sans shaders, of course--that'd be getting a bit too ambitious for 1.1, although Allegro 5.1 *does* have the functionality). :D  It'll be a fully Pegasus compliant implementation and its existence is reported by GetExtensions() as "sphere-galileo".  Allegro 5 truly is awesome.

The only thing I really have left to implement is the automatic U/V assignment and modifiable vertex and shape lists for Shapes and Groups, respectively.  Shouldn't be too much more work.

minisphere 1.1 will be a sight to behold once it's released.  Best of all: You get all this new stuff, and it STILL runs old Sphere games! ;D