Yes, this makes sense to me. When dealing with any pixel-perfect rendering, you should always represent your positions and sizes as integers. When you specify a 0.5f, the GPU will ultimately have to choose which pixel it gets mapped to (this is actually done based on your projection matrix). I'm not sure why it's different on NVIDIA vs ATI, but it's probably due to floating point math differences.
For pixel perfect rendering I would use an orthographic projection that maps directly to your screen resolution. Also make sure the viewport (glViewport() if you're using OpenGL) is also set to your screen resolution. Don't rely on the default viewport that is set for you when you bind the OpenGL context.
I've recently implemented font rendering using freetype and have had results almost exactly to what you have shown in your image.
I believe OpenGL handles all of this during glLinkProgram(). It will bind the inputs and outputs of the vertex and fragment shader... and complain (i.e. fail) if anything doesn't line up. For older versions of GLSL, there was varying. I believe it's the same concept... just new keywords.
The only output of a fragment shader is going to be a vec4, since you are writing a color (or value) to a render target.
I would probably start by creating many textured quads, giving them a sway (via shear matrix), and then batching all of them on the CPU. Then send them all to the GPU in a single (or minimal) render calls.
The problem here will probably be depth sorting (since the grass textures will have alpha): You could either turn off depth writes and just let the pixels clash together, or spend the time sorting them if you have enough CPU resources. I'm sure there are papers on the subject if you want to get more advanced.
If you want the grass to cast shadows, you can still use standard shadow mapping. During the shadow pass, draw the grass with alpha-testing enabled.
In short, while I respect that you might find it difficult to write a game engine, it feels like you are assuming that everyone just writes game engines without some kind of idea as to what kind of game the engine will be used for.
Certainly not everyone. I did not mean to make that assumption. My initial comment meant to state that if one is having trouble writing an engine, then don't be afraid to continue writing games/apps and then refactor. The notion of "I must write an engine before I write a game" can be a trap for beginners with less experience.
If one is experienced and disciplined enough to write small unit tests for each feature and prove that their implementations work and their API's are intuitive throughout development, then I agree with your methods completely.
The bottom line is, just write code, fail early and often, write more code, and continue learning. This experience will only make you a better programmer overall.
RMGUI's cater towards artists/designers at the front of the pipleline and programmers at the end. IMGUI is the exact opposite - programmers will implement the logical components of the gui and then can expose the data (layout, color, theme, etc) for artists/designers to tweak.
I suppose it really depends on the project/team you are working with. If your engineers are nothing more than code monkeys, and need specific requirements for everything they write, then RMGUI may be best suited. However, if the engineers are making more of the design decisions, and you just want to outsource your art, then IMGUI may be best suited.
To answer some of the OP questions:
a) I would implement modal dialogs as part of a layered screen system, and use multiple IMGUI objects. You can push and pop "screens" onto the stack and trap input to the top level. Typically though, IMGUI does not support overlapping widgets.
b) Draggable windows are implemented by returning the (x, y) position of the window out of the function, and using them as inputs for the next frame. The IMGUI will store the mouse drag information in it's internal state.
c) I don't think you can identify controls throughout a frame. All widgets are independent of eachother. I'm having trouble coming up with reasons why you need to identify a control with IMGUI.
d) As in the paragraph above, IMGUI is probably better suited for programmers at the beginning of the pipeline (i.e. hand coded), and then expose whatever data you need tweaked to the artists. Using a generic designer to be later implemented into the game by programmers doesn't really make sense to me with IMGUI. The IMGUI is tightly coupled to the code flow.
e) I don't have an answer.
f) I don't have an answer.
g) An IMGUI can store whatever data it needs between frames. Typically it stores a variety of IDs that reference to what widget is 'hot' or 'active'. The key point about IMGUI is that typically only one widget can be interacted with at a time, so storing state in every individual widget is a waste.
As an example, during the load of a Shader, if the VertexShader it is dependent on hasn't been loaded yet, you could do the following:
1) Shader load() returns false - also sending out the dependency it requires.
2) The VertexShader the Shader requires is added to the resource loader if it hasn't been added already.
3) The Shader is re-added to the resource loader
With this in mind, the Shader load() could execute again before the VertexShader and the same thing happens. This could be ok, but will also keep you in an infinite loop if there is a problem locating the VertexShader. In order to handle these cases, I would probably add a timeout or a max fail count to each loader, and log the information.
You could also adjust the thread priority of each loader when a dependency is encountered, but I would try to keep things simple at first and work from there.
In the past, I've written game logic to include several screens. You can think of each screen as a layer of updates with the bottom layer being the game level/logic. Input is filtered from the top screen down to the bottom. On input, the screen can choose to handle it accordingly, and/or pass the input along to the one underneath it.
This makes it easy to pop up a 'pause screen' and halt updates to the 'game screen'. Or in your case, create a 'UI screen' and if input was handled, don't pass it down to the 'game screen' - just like Faelenor suggested.
I've implemented two types of shader/parameter systems before. My first implementation was very similar to yours. It has a very nice OO approach. You probably don't need a separate MaterialParameter class, your Material could hold a list of ShaderUniforms and provide an interface to set them. Don't worry too much about type checks - during development they will save your butt, and you can always #define them out in a release build. I don't see where you are doing static casts, but if your checking the type, then I don't see a problem with it.
In my second implementation, I steered away from this design, and tried to create something much simpler. My ShaderUniform class became a struct PoD with a type and union of parameters. I have methods to set them and bind them using a switch statement instead of hitting the vtable through virtual functions (I haven't profiled both implementations yet, so I don't know which is faster). Using a type and union may be simpler, but as I add more types, I need to touch several pieces of code to keep it updated. Using your OO approach allows you to easily create a new derived ShaderUniform and everything should just work.
Overall, I think your design is fine. As long as it's easy to use and extensible... which you'll find out pretty quick once you start using it as an interface.
Edit: It's probably not necessary to cache the ShaderUniforms into your Material class. Why not just create all of the uniforms and give them a default value on Init()?
Keep in mind that is it sometimes more appropriate to use separate streams. For example, if you need a depth-only pass, the positional data should be kept in it's own buffer and sent to the GPU separately during this pass.