Skip to main content

News

Topic: Sphere 5.5.2 (previously miniSphere) (Read 427015 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.5.11
Reply #1680
Ok, I got the shader working, heading towards that option 2, would be nice if you could add shader support to shapes to remove an object from the code, but it works without that.

BUT I seem to have found a weird error when I draw a Model screen.flip() does not clear the backbuffer afterwards but FlipScreen() does.
  • Last Edit: June 29, 2017, 07:51:14 pm by Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1681
That's a weird bug - the only difference between the two flip functions is that FlipScreen doesn't reset the clipping rectangle for compatibility (screen.flip does) and uses SetFrameRate rather than screen.frameRate.  Everything else should be the same.  I'll look into it later, though.

Note that Model can't be completely removed from the API because you might want to use the same Shape with different shaders and/or uniform values.  I agree that the extra complexity isn't always needed, though.  I'll see what I can do to improve it going forward. :D
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.5.11
Reply #1682
When I'm asking for shader support at the Shape level it would need the uniform setting features as well, are you saying that model is there so you can draw the same shape with two different values at the same time by having it in different models, I'd assumed that that wouldn't work, not sure why I'd assumed this, but I had.

My "custom" shader is just the default vertex shader you'd written with two uniform floats added in that get added to the x and y components of the varying_texcoord.

FYI I'm thinking of trying to build what I'm working on out into a "standard" sprite library for your v2 api so we can deprecate .rss with something good.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: miniSphere 4.5.11
Reply #1683
Fat Cerberus, have you thought about putting "dead zones" between sprites on the atlas? If you add a 1px or 2px transparent gap, the artifacting should go away. It helped the atlases in my SSFML build, for instance.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1684

When I'm asking for shader support at the Shape level it would need the uniform setting features as well, are you saying that model is there so you can draw the same shape with two different values at the same time by having it in different models, I'd assumed that that wouldn't work, not sure why I'd assumed this, but I had.


If I remember correctly, FJ's original design didn't allow that, but I realized there was no technical reason why it couldn't be supported, so miniSphere does allow it.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: miniSphere 4.5.11
Reply #1685
implementing this is a large undertaking

it will take me a day or so

This is pretty great. ;D

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1686

implementing this is a large undertaking

it will take me a day or so

This is pretty great. ;D


:)
What can I say, I'm good at managing my time.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1687
I started experimenting with the fullscreen fix, and I found that doing it the way I want to has an additional positive side effect: Screenshots will be saved at the game's native resolution, rather than being the physical size of the window as they are in 4.5 and earlier.  That's especially nice for fullscreen screenshots, which right now come out letterboxed at 1080p :)
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.5.11
Reply #1688
A few more thoughts from fiddling with Galileo:

1. It seems that to apply a colour mask to a shape you either have to retexture it OR I need to add more to my shader...

2. You don't have the different blend modes that v1 has, but maybe it's best to implement these via the shader - (possible project for me this evening)

3. I think it would be good if you could  pass values to the shader at the shape level, would mean you could move a model around whilst having parts of it change colour differently, rather than needing to track multiple models.

4. For code cleanliness would be great if we could pass vectors to the shader - if I do as much with shaders as I'm thinking of now I think the uniform setting is going to get quite clunky I can obviously make helper functions to make it look neater but would be nice if it was neater.

(Yes I may have just spent a while dreaming about what I can do with glsl...)

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1689
To apply a color mask to a shape you just change the color of its vertices.  This is how Prim.blit() applies the mask you give it.  As for blend modes, you're right, that needs to be done in the pixel shader.  Allowing predefined blend modes alongside shader support seems like mixing metaphors and I don't want to make the v2 API too complicated.

Agreed on the usefulness of passing vectors.  That would be good for passing colors, for instance.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.5.11
Reply #1690

To apply a color mask to a shape you just change the color of its vertices.  This is how Prim.blit() applies the mask you give it.  As for blend modes, you're right, that needs to be done in the pixel shader.  Allowing predefined blend modes alongside shader support seems like mixing metaphors and I don't want to make the v2 API too complicated.

Agreed on the usefulness of passing vectors.  That would be good for passing colors, for instance.
But unless I'm missing something I can't re-colour the vertices without making a new shape?

I'm looking at how to be as efficient as possible with my use of shapes but at the moment unless I'm missing something the only writeable property of a shape is a texture and masking a texture is just a pain (convert to surface then draw a coloured shape over it then convert back)

-> Going to work on the shader method instead.

Note: whilst with a bit of effort I'm growing to like the concepts in this Galileo interface, I think it is nowhere as beginner friendly as the v1 graphics interface -> there needs to be clearer tutorials/guidance/something if we want programming beginners to be able to dive into this.
  • Last Edit: June 30, 2017, 05:09:25 pm by Rhuan

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1691
Yeah, that's by design.  Constructing a shape is tantamount to uploading it to the graphics card.  If I allowed the properties to be changed afterwards, I think people would tend to want to do that and then wonder why their game is so slow (every modification would need to re-upload the whole shape).  Forcing the user to construct a new one makes the re-upload explicit.  If you need to dynamically change things, it's indeed recommended to do it in the shader.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: miniSphere 4.5.11
Reply #1692

Note: whilst with a bit of effort I'm growing to like the concepts in this Galileo interface, I think it is nowhere as beginner friendly as the v1 graphics interface -> there needs to be clearer tutorials/guidance/something if we want programming beginners to be able to dive into this.


Yep, that's intentional.  Beginners are meant to use the Prim module for exactly this reason.  Galileo is the low-level foundation everything is built on, but it's definitely designed to be used as middleware, rather than the primary graphics interface for game-level code.  It'd be way too tedious to try to use it directly in game code without having a framework built on top of it.
Sphere 5.5.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: miniSphere 4.5.11
Reply #1693
If you do use it directly, you usually want to put it into your game's engine code. In my prototype games (mostly RTS and puzzles, but the concepts apply to RPGs) I usually attached Shapes to a character [proto]type (ie a sprite), and then had a Group/Model for each character that included the shape of the type. This is more efficient than the v1 API which amounts to immediate mode, and actually works pretty well with a prototypical object model, and for an RPG type of game (each prototype of a character or enemy 'class' in the RPG sense, or unit type in an RTS has a Shape, and each instance has a Group/Model, which means the actual sprite is the Shape, and is not duplicated between individual characters in memory or on the GPU).

  • Rhuan
  • [*][*][*][*]
Re: miniSphere 4.5.11
Reply #1694
Spotted two things I think are bugs, or at least aren't in line with the api as far as I read it.

1. If I have two different models using the same shader and set a uniform value for one of them it sets it for both of them.

2. Color#red [read/write]
Color#green [read/write]
Color#blue [read/write]
Color#alpha [read/write]
Don't exist, though:
Color#r
Color#g
Color#b
Color#a
Do exist and work.
  • Last Edit: June 30, 2017, 07:57:21 pm by Rhuan