ZZYZX wrote:1. Why native code, not OpenTK?
I picked native code over OpenTK because:
1) The project already had several native dependencies, including building a full C library. Streamlining that into a single native DLL seemed reasonable (yes, it isn't streamlined right now, but that other C library could be moved into BuilderNative easily). It would also give me an easy way to reimplement anything DevIL was doing, if needed (turns out Talon1024 found a way to just link directly with DevIL on Linux though).
2) 3rd party assemblies in .net are generally unstable. Hell, even Microsoft C# stuff is a moving target. SlimDX went missing in action, what's not to say same could happen to OpenTK? I generally gravitate towards solutions that can be maintained within a project rather than have outer dependencies. In short: I trust my own abilities over 3rd party developers and only use them when there's enough extra work involved that I can't do it myself. I've been burned too many times.
3) I do not like C# very much. Especially when resources are involved that language is like stepping back to early C and C++ before RAII and shared/uniqueptr. IDisposable and finalizers are an abomination. I wanted a solution that was "idiot proof" and with a managed outer interface, so that the consumers of RenderDevice did not have to worry too much about actual GPU resources and could stay in the la la land of garbage collection.
While you could create a backend directly in C# using OpenTK it would just invite the next developer to get creative about accessing OpenGL directly. My personal opinion here is that C++ is better at handling OpenGL resources, but of course a pure C# developer would disagree with me here. It is a design choice where either way would technically work. I see the C++ version having the bonus feature that a rookie C# developer won't be able to fire off custom OpenGL.
That said, if someone wanted to rewrite it with OpenTK they can do that relatively easy - because unlike the old SlimDX version there's now a few simple basic outer interface to drawing 3D that can encapsulate several backends, if needed.
ZZYZX wrote:I once had an attempt at removing SlimDX, however started differently and pretty much stalled at replacing all vector math that was randomly using either SlimDX or own code... That's why I remember OpenTK

My strategy was to first find the exact dependency to SlimDX at the class and function level. From there I evaluated each class and picked a solution. For the math classes the easiest step was to replicate them, although in the long run one would want to get rid of them completely. There's no real reason why there's several classes doing the same job. If you look at the commit log of my branch you can see it consists of many iterations where I slowly morph code closer and closer towards something better. This method is very powerful if done right and essentially allows me to refactor a large program while almost introducing no bugs.
ZZYZX wrote:Why shaders embedded in C++ preprocessor or whatever, and not Resources directory like D3D shaders?
This is one example what I do in intermediate steps when porting from one design to another. I needed some shader code fast and the easiest way was to inline it directly in the C++ code. At the time I didn't want to outright delete the original D3D resources as I still wanted them for reference. Defining the uniforms and shader source code from C# (coming from resources) would be a natural next step, but I didn't get around to code that.
You have a much better understanding of what GZDB does in general than I do. I opted for the first solution I could spot here, not even sure yet at the time if it would work or what the implications would be. I wouldn't be surprised if there are a few more of those kinds of issues lurking, including case sensitivity issues with files.