So it's been awhile yet again since my last post.
Been working on a shader to replicate an old CRT for HLSL shader model 3 for XNA 4.0. There's of course some strange stuff that I didn't know about XNA 4.0, such as if you make a shader that only implements the pixel shader, the spritebatch (which I am using for this shader as it's all post processing) will make a ShaderModel 2.0 vertex shader to pass things through. This wouldn't be a problem if there wasn't s 64 instruction limit on pixel shaders math calculations. A shader I found to base myself on for the start of the scan lines goes over that limit and of course the poster even said, "Fixed it by putting it on shaderModel 3."
Now the problem with that is if you just put your pixel shader on 3.0 and still don't define a vertexShader of 3.0 as well, XNA will give you a compilation error which basically says "Fool, you're trying to mix a VertexShader of ShaderModel 2 with a PixelShader of ShadeModel 3...You duuuumb."
I had to search for a couple different things to finally come across a way of just passing everything through the VertexShader to not affect the outcome of the post processing (if you try to just do something like pass the input position to the output in the vertexShader, it will give you a one color screen instead of what you want.). Thankfully someone has already done a great service by figuring out a way to make a pass through without affecting the actual image (much, he claims it might make it a bit blurry but I don't really see it)
A few lines of code later and you've got a model 3 vertex shader that passes through and doesn't mess with your pixel shader. So I got that working...And then I found out I needed to actually be working on this for GLSL so here goes nothing (with learning GLSL/OpenGl) and trying to paste some shaders together and check their performance
Something else that has popped up is Unity and XML reading. Now I figured since we're using the C# scripting it would be just regular C# that I could use to read it all in and work with it. I figured hey, I like LINQ and I've gotten quite a bit of experience working with it and XML together in my P90X WoT project so we'll just use that for our localization and be done with it.
Oh How Wrong Was I. Unity doesn't use a high enough C# version to access XDocument which is what I had done all my previous work with so I had to scour the internet to find a new way to do it and after researching...and, you guess it, PROBLEMS GALORE, I finally have it working.
One of the pages about XML loading and Unity I found was this,
Which almost worked for me. Some of the code was needed for me to get it working again but one of the lines that did give me errors no matter what is this one
Line 29 xmlDoc.LoadXml(GameAsset.text); // load the file.
I found a bunch of things about how when you save XML as UTF-8 it sometimes adds a BOM (Byte Order Mark) which Unity reads as white space. It's supposed to be in there to let things know what the endianess of the code is but Unity just reads it as white space and will actually just say, "NO". So after probably a literal hour or two searching and trying different solutions all to no avail, I tried something else which I originally didn't know was there....
If you do xmlDoc.Load(GameAsset.text);
It will go without a hitch and load it. Strange but it works and I curse it every time I look at it.
I'm just starting with localization for the first time and we're going to be developing a text heavy game (dialogues for characters and their actions and progress reports etc. etc.) which has to be localized from English to Dutch, French and German as well...Now that the XML is loading finally we can start on things because we felt that we had to get this in place before we even started developing the game. I feel it's a good thing because if I would have to go back and change all this stuff to load different things based on languages I'd probably rip my hair out and throw myself through a wall..
But anyways, that's all my problems for now.