Good point, I ammended my examples to add the public, but my actual implementation already did that. In my second (working) example, making Data in the Derived class private does actually result in an error about accessing the private struct. The second example was working with public though, so making it private makes sense that I would get the error.
The part about dependencies in the template would make sense, especially "In resolving dependent names, names from the following sources are considered: Declarations that are visible at the point of definition of the template." Since the Data struct isn't visible when I inherit from the mixin template, it can't resolve the dependent type. That wouldn't explain why my second method works though, as that should still be subject to the same restrictions on resolving the dependency?
First, thanks for the name, I knew it was called something and was failing to remember/find what it was.
Second, sadly, this doesn't seem to work for a struct inside the derived class. It works for (almost?) everything else, member variables, functions, etc, but MSVC won't let me access a inner struct from the templatized class.
[EDIT] Third, I was able to figure something out:
template <class CLASS>
struct Data : public CLASS::Data
std::map<string, Data> dataMap;
// Do stuff with the map of data;
: public BaseMixin<Derived>
It lets me do what I want, and I can still get the Data inside Derived and use it as expected. I'm actually not sure why this works compared to my original post, anyone know? I don't mind using it since it makes sense to me, it just doesn't make sense why I can use the type this way, but not how I originally tried.
It's even more funny because Visual Studio highlights some of the code as errors in Derived when using Data, but it compiles without error and runs as expected.
Have you checked the debug output? If nothing is rendering (or a black square), then it sounds like something else is happening (SRV not bound anymore?). For the blending, your order of operations looks correct, though what do you mean by invalidate texture? I'd try out some different debug output, write .5 to the alpha when drawing the circles, just to check with a fixed value. If it renders at half opacity there, then the issue would be with your input texture. Try different things like that, even rendering the squares without a texture at all, just output a fixed color and alpha value, just to make sure that part is working correctly. If it's a texture issue, you can also try just outputting the alpha to the color, and don't enable blending at all, just to visually see what value you are getting.