search

PistonDevelopers / gfx_text

Draw text for gfx using freetype
http://docs.piston.rs/gfx_text/gfx_text/
MIT License
22 stars 12 forks source link

Lower requirements to GLSL 1.3 #39

Closed mattias-p closed 8 years ago

mattias-p commented 8 years ago

I've got this Debian stable (8.3) installation on a laptop with integrated graphics and an i915 driver. I'm unable to use the current gfx_text because its shaders require GLSL 1.50. By simply lowering the version requirement in the shader headers to GLSL 1.30 I'm able to run the gfx_text styles example on my laptop. Unless there's a good reason why the requirement should be at 1.50, please accept this PR. I bet there are lots of people like me with non-monster computers.

Kagami commented 8 years ago

As far as I remember, current version line allows to use gfx_text on both Mac and Linux/Windows with single version of shaders. @kvark am I right? I think we should provide two versions of shaders for better portability in that case. (See gfx examples.)

kvark commented 8 years ago

@Kagami yes, you are correct. OSX requires GLSL 150 core. Windows/Linux could work on lower version, but these need to be provided separately. If you do that, just changing the version number is not sufficient - you also need to patch some code (in in VS -> attribute, no out in FS, etc).

mattias-p commented 8 years ago

Could the shader version be chosen depending on capabilities somehow? It seems to me that the only information available to gfx_text is the factory object received in the constructor, and the only relevant information it provides is a ShaderModel object that isn't detailed enough to distinguish between support for 1.30 and 1.50. Am I reading this correctly? Is there some other way to do it? Would it make sense to make a feature request for increased granularity?

It looks to me that the in and out storage qualifiers were introduced in version 1.30. That would also explain how I'm able to compile and run the shader as submitted in this PR.

Kagami commented 8 years ago

Could the shader version be chosen depending on capabilities somehow?

Yes, ShaderSource struct allows it, see docs here. Though gfx examples don't use v120 shaders anymore for some reason, but you can look at some previos commits, e.g. this one.

This issue might be related, I haven't digged through all latest changes of gfx yet.

kvark commented 8 years ago

@Kagami yes, examples are not using this at the moment, but we'll get it back for sure.

Right now, you can create a program with FactoryExt::link_program_source (@mattias-p - it's using the capabilities of the factory to choose the shader version) and then a PSO with create_pipeline_from_program. We just need a shortcut for it, similar to create_pipeline_simple.

It looks to me that the in and out storage qualifiers were introduced in version 1.30. That would also explain how I'm able to compile and run the shader as submitted in this PR.

Oh, you are right, sorry. I was thinking about 120, which we have for examples. If you care enough to specify a separate shader source, you should go as low as 120.

Kagami commented 8 years ago

Seems like this issue is blocked by #37. It's better to port to latest gfx first and then provide additional v120 shaders since API was changed.

Kagami commented 8 years ago

gfx_text was ported to gfx 0.10. Moving to #42.