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.
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.
Quote from: mezzoEmrys on April 23, 2015, 10:22:42 amFrom 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!
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.
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.
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(); });
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'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.
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);
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.