Mikko Rasa [Sat, 12 Nov 2016 00:00:09 +0000 (02:00 +0200)]
Process existing inputs in passthrough
Vertex shader inputs are not linked to any outputs so they weren't being
recognized for passthrough. Also, some inputs might have already been
declared either explicitly or implicitly so those declarations should be
preferred over creating new ones.
Mikko Rasa [Fri, 11 Nov 2016 16:39:57 +0000 (18:39 +0200)]
Refactor module and stage management
Originally I envisioned that ProgramParser would handle imports, but it's
non-trivial to make re-entrant. The parser will now only hold one module
at a time and ProgramCompiler will handle combining them.
Mikko Rasa [Fri, 11 Nov 2016 09:05:15 +0000 (11:05 +0200)]
Streamline interface declarations
Out variables can now be declared inside functions and will be exported
to global scope. In variables don't need to be declared at all; they are
pulled in from the previous stage. There's a new passthrough statement
to copy all inputs to outputs.
Mikko Rasa [Mon, 7 Nov 2016 21:10:51 +0000 (23:10 +0200)]
Begin implementing a new shader program generator system
ProgramBuilder is good enough when working within its standard features,
but it's difficult to expand. Custom variables are overly sensitive to
declration order. Adding loops or conditionals (other than the operator
flavor) requires using an additional shader. It's not possible to modify
a variable's expression without replicating it in its entirety.
All of the internal processing with coordinate spaces, interfaces and
indices can also be difficult to understand. Not to mention the reverse
processing order which starts from the goal variables and works backwards
to figure out how they can be computed.
The new ProgramCompiler system, as its name implies, works more like a
compiler. It's designed to take GLSL as input, apply transformations to
it and produce different GLSL as output. Storing the progrem as an
abstract syntax tree allows much more comprehensive processing than the
old system which barely understood what an identifier is.
At the moment it doesn't do much yet. The only transformation is to
split a single source file into vertex, geometry and fragment parts and
add a common section at the beginning of each of them. More will be
added soon.
Mikko Rasa [Sat, 5 Nov 2016 23:37:55 +0000 (01:37 +0200)]
Detect deprecation versions for extensions
If the core profile is in use, deprecated extensions will be made
unavailable unless the driver explicitly advertises them. In particular,
MSP_legacy_features is made unavailable so code that tries to access
legacy features with a core profile context will throw an exception.
Additionally no enable/disable calls will be generated for textures, as
they are only used for legacy texture units.
Mikko Rasa [Thu, 3 Nov 2016 11:12:06 +0000 (13:12 +0200)]
Prefer RG pixelformats over LUMINANCE
LUMINANCE formats were deprecated in OpenGL 3.0. ARB_texture_swizzle
was not promoted to core until 3.3, so it's possible this won't work on
some transition period hardware.
SLUMINANCE formats are marked as deprecated in mspgl since it's not
possible to properly emulate them through swizzling.
Mikko Rasa [Thu, 3 Nov 2016 10:50:35 +0000 (12:50 +0200)]
Expand the PixelFormat conversion API
Get_sized_pixelformat now takes an explicit size parameter. The decision
between 16-bit and 32-bit depth component formats has been moved to
Texture::set_internal_format.
Get_unsized_pixelformat was added as an intermediate step for
get_base_pixelformat. It preserves sRGB information.
Mikko Rasa [Wed, 26 Oct 2016 18:33:21 +0000 (21:33 +0300)]
Be smarter about detecting backport extensions
Sometimes a more recent and completely unrelated extension reuses some
tokens with their core names, causing them to seem like backport
extensions to the script.
Mikko Rasa [Fri, 7 Oct 2016 12:38:09 +0000 (15:38 +0300)]
Perform culling in eye space and account for Renderer's matrix
This allows container renderables to apply intermediate transforms to the
Renderer. Sometimes it may be inconvenient to propagate every matrix
change down through the hierarchy.
Mikko Rasa [Sun, 14 Aug 2016 20:29:49 +0000 (23:29 +0300)]
Add a new API to Pipeline that ties Renderables and passes together
The old API is now deprecated and will eventually go away. There are
two reasons for this change:
1. Pipeline was a sort of pseudo-scene, and in many simple use cases it
was not clear which should be used to hold Renderables. Scenes are
intended as grouping primitives.
2. It was possible to add multiple passes with the same tag and different
rendering state, but there was no way to add a Renderable for only one of
them. This led to tags doubling as a way to filter different passes at
the level of individual Renderables. The intended purpose of tags is to
select between different presentations of a Renderable.