Skip to main content

News

Topic: Sphere v2 API discussion (Read 34898 times) previous topic - next topic

0 Members and 1 Guest are viewing this topic.
  • Rhuan
  • [*][*][*][*]
Re: Sphere v2 API discussion
Reply #135
Thanks for the heads up, I'll fix the bug in 4.8.4.

As for the branches and backrefs, I removed them because they were difficult to document adequately.  So I just tried to make it work similarly to a C struct because that's easy to understand and explain.  If there's enough demand I could bring the feature back, though. ;)

I admit I was nice being able to load an entire .rmp file with one call...
I've just learnt how the history feature works on github. :P

I'm going to add the branches/backrefs code to my own script for now, it's too good not to use.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere v2 API discussion
Reply #136
I've just learnt how the history feature works on github. :P

Version control is awesome isn't it? :D  I like using Git because I'm not tempted to keep dead/commented-out code around forever, I can prune things as aggressively as I want and if it turns out I need the code back later I can just get it back from the history.  Sometimes it's difficult to find things, but I've found YAGNI holds true most of the time and I indeed never need the deleted code again.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: Sphere v2 API discussion
Reply #137
Am I allowed to be annoyed that neither textures nor surfaces are readable in sphere v2?
I was briefly tempted to resort to some v1 functions....

(I want to implement fancy pixel scaling algorithms, but I don't want them at render time I want to do them in advance for a stack of reasons)

BUT it's fine I've worked out a work around that may even work better than what I was planning before, it's just not what people would think of. (but it will be cool)

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Sphere v2 API discussion
Reply #138
I actually wanted to add a function for that like Surface#lock() but I couldn't come up with a way to expose the raw pixel data to JS in a user-friendly way.  I'll revisit it at some point, it might be possible to have it return an ArrayBuffer or similar.

That said, the preferred way to do fancy scaling nowadays is in the fragment shader.  I think I've seen hq2x shaders out there, for instance.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rhuan
  • [*][*][*][*]
Re: Sphere v2 API discussion
Reply #139
I actually wanted to add a function for that like Surface#lock() but I couldn't come up with a way to expose the raw pixel data to JS in a user-friendly way.  I'll revisit it at some point, it might be possible to have it return an ArrayBuffer or similar.

That said, the preferred way to do fancy scaling nowadays is in the fragment shader.  I think I've seen hq2x shaders out there, for instance.
Yeah what I'm going to do is use shaders to scale and draw to a surface then convert the surface to a texture.

(I want these done in advance not at runtime as my runtime shader is complex enough as it is, though I may revisit that later. Having the whole map as an atlas drawn using a shape the size of the screen with just 4 vertices seemed like such a good idea when I first thought of it, but getting the coordinates and stuff to work properly with it was... interesting to say the least.

  • Rhuan
  • [*][*][*][*]
Re: Sphere v2 API discussion
Reply #140
I actually wanted to add a function for that like Surface#lock() but I couldn't come up with a way to expose the raw pixel data to JS in a user-friendly way.  I'll revisit it at some point, it might be possible to have it return an ArrayBuffer or similar.

That said, the preferred way to do fancy scaling nowadays is in the fragment shader.  I think I've seen hq2x shaders out there, for instance.
TBH I''m not sure if there's a need for it as you can do whatever you need with a shader, it just feels counter intuitive to use a shader to fiddle with an image then store the edited image into a variable for later use.

If you were to implement it, I'd want it as a direct inverse of the new Texture function except as a surface method probably.