Deploying an application with shader files.

[Graeme]

Does anybody know of a good way to ship an application with shader code?
The shaders are all in stand-alone text files, but I'm trying to come up with a
way to ship it inside my binary for easier deployment. Is that a good idea?
I guess I could include them as FPC Resources, and then at runtime read them
out from the resource and store in as text (or a TStringList) in memory.

[Graeme]

Ah, I see now Marcov's standalonegl test archive (from another message thread), and if I understand the code correctly, he does exactly what I described. The shaders text files are stored as resources inside the executable.

Glad I was on the right track.

[creaothceann]

Or store them in a hidden form's memo controls.

[Graeme]

Or store them in a hidden form's memo controls.

Please don't do that!!!  We are not Visual Basic 6 developers.

[marcov]

Yes, I got tired of using   '+'  or msg2inc.

While Resources sound convoluted when you first encounter them, they are nice in practice, since they don't require any extra actions except rebuild, and no complication of the build system. (set directories and point at the first file, no separate steps).

Just add the RC file that includes them to the project, and done. The .rc plays nice with VCSes (unlike many XML project files)

I also pack the required textures into the exe. (like rendered fonts)

While in theory it would be better to generate them from ttfs on first run, it is simply one less thing that can go wrong. And aside from that I don't have a good sdf font generator yet.

[SymbolicFrank]

That was the main bottleneck with my implementation of the signed distance fonts: a good font generator.

Even just creating a huge texture with a single, sharp glyph on it is hard, with the libraries available. And generating the signed distance textures from that on the fly takes too long.

Displaying the glyphs is easy.

[marcov]

That was the main bottleneck with my implementation of the signed distance fonts: a good font generator.

I got the source of the PXL fonteditor from ykot and planned to integrated the translated sd generation from a bitmap from the sdfont tool (from e.g. Cinder), but the signed distance font didn't scale well to small sizes, and the rush was high, so it went live with wglusebitmapfont fonts for (the one) small size, and only signed distance for big sizes. Unfortunately the only font that worked right was a bit cartoony, I'm not happy with it, but customers haven't commented till now (probably since they like the feature)

The problem is that the sdfont tool doesn't allow to specify a distance between the textures, packing them too tight which causes artefacts when rendering (or I'm doing something wrong)

I translated the C code during the christmas break, but then lost time again. I changed PXL a bit so that it can increase the distance between glyphs.

I also found a different algorithm for generating the signed distance glyphs that is probably faster. Must have a pdf for that somewhere. But in practice I plan to simply ship a texture in a resource anyway, since that makes things more crossplatform.

Even just creating a huge texture with a single, sharp glyph on it is hard, with the libraries available. And generating the signed distance textures from that on the fly takes too long.

Displaying the glyphs is easy.

Doing anything slow is easy. Doing it fast (like 15000 glyphs in <10ms) was the hard part. (building up the vertices is what eats up the time btw, not the GL part)

However, when I need to render small glyphs it is always in a small font, so I plan to do that with a separate draw step using a plain font atlas.

While the shader code will be much the same, the size of the vertices will be small due to the non scalability, and I hope that gains another factor 2.

[SymbolicFrank]

I would be interested in cooperating about this.

Native RSA (or, a decent BigInt library) and sharp 3D fonts are the two things that prevent me most from using Free Pascal / Lazarus in random projects.

Yes, I know, I should take the time to implement them myself, or fit them in my next project, but I tend to have deadlines and managers/co-workers who like C#/C++/Java/whatever over ObjectPascal. Telling them it takes longer isn't helping.

My next project is serious micro-services (Web that doesn't suck), which I'll start in Free Pascal. Other than that, I would like to contribute. It isn't hard to do, but I'm lazy. So I require some encouragement.

[AlexVinS]

I`m using resources for shaders deployment. And compile them with TResourceStream descendant class.

[Thaddy]

That's what I would suggest too. RT_RCDATA
There's no reason to stream them out to storage. One would typically use a resourcestream to access them directly.

[ChrisR]

My own solution is to always store a default shader in the program's code so there is always a fallback, and then to have a separate "Shaders" folder with optional GLSL text files the user can edit.

For example, my plyview includes a shader embedded as a string in the main code:
  https://github.com/neurolabusc/plyview

//Blinn/Phong Shader GPLv2 (C) 2007 Dave Griffiths, FLUXUS GLSL library
kFrag = '#version 330'
+#10'in vec4 vClr;'
+#10'in vec3 vN, vL, vV;'
+#10'out vec4 color;'
....

My MRIcroGL and Surf Ice programs optionally support a shaders folder - the user can easily edit the text files with their favorite editor. This allows them to make simple modifications, e.g. adjust the default slider positions for the shaders, or they can create new ones. While this works for MacOS, Linux and Windows, I particularly like the implementation in MacOS, where the Shader folder is stored in the applications' package. That way whenever the user copies the application, they are copying the shaders as well.

https://github.com/neurolabusc/MRIcroGL
https://github.com/neurolabusc/surf-ice