I ported some of the formulas I use in to , for faster rendering. Because of legacy baggage in the existing code of I started work on a new framework for 2D fragment within FragM.

Similar in spirit to (my physically inspired raytracer for FragM), only with the added complication of wanting to support double precision ( 4) where available, while still working to some extent (without so deep zooms) on single precision float (OpenGL 3) if that is all the can do. Only single precision is implemented so far.

Got dynamic switching between float and double working (based on derivatives of pixel coordinates). But I don't know if it's actually computing both and switching afterwards - there isn't much noticeable speed increase at shallow zooms. GPUs are weird.

But there are some bugs in FragM that mean my desired workflow is not yet attainable: the code that parses the shader for annotations about uniforms to build a GUI with is a bit dumb and doesn't respect preprocessor , which I was hoping to use to fallback to float when double is unavailable.

Similar deal with and , even commenting it out doesn't help if the is the first thing on a line...

Follow

Actually it turns out building a better parser for uniform/GUI mapping that respects is a because so many things are by the GPU driver and it's tricky to get at them from outside shader source, and it's trickier to get things from inside shader source to outside.

My current code works to an extent which is good enough for me, as long as I don't poke it.

Sign in to participate in the conversation
post.lurk.org

Welcome to post.lurk.org, an instance for discussions around cultural freedom, experimental, new media art, net and computational culture, and things like that. This is part of a family of services that include mailing lists, group chat, and XMPP.