Migration to OpenTK
moorehousew opened this issue · 42 comments
We should really move to a better cross-platform framework. I suggest OpenTK, since I've already written almost an entire layer of abstraction on-top of it and can just pull it all into a new project file. We can discuss migration details here.
My understanding of the advantages of using OpenTK:
- One download for all platforms without stupid bullshit like we do now
- Shaders aren't stupid
Disadvantages:
- Reduce chances of iOS or Android port
- Lots of work to switch
Comments:
- An iOS/Android port would be pretty difficult anyway
Is this correct?
Yeah, that's pretty much it.
Alright, then let's do it. Did you want to lead this effort?
I dunno; I could lead, but it would be nice if the endeavor was hosted in this repo, not one of my own. We should also decide what the result is going to be before jumping in. I doubt you want 5 thousand lines of OpenGL abstractions cluttering the client namespace; perhaps a TrueCraft.Client.Runtime project for 'engine' logic?
I was going to suggest giving you write access to this repository to facilitate that.
As for abstractions, sure, TrueCraft.Client.Runtime sounds fine to me.
Write access would make this a lot easier, yeah.
Cool. I'll give you write access and we can get started. I'm a bit tied up tonight, but I'll help out starting tomorrow.
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
Let's do this in a new opentk branch until we get things working at the degree they are now with MonoGame.
Sounds good.
Why is monogame stuff stupid? There are obvious reasons for it, platforms are different. You are digging a hole, from which you can't later escape.
That's a bit weird. Was there a problem with compiling and using shaders? I have written custom shaders and they work both on android and windows.
We can't compile shaders from Linux. The ability to compile the code is dependent on your platform.
Also, the majority of the work here is not in the client's rendering layer. That can easily be replaced. We are not committing ourselves to an inescapable fate.
The problem is with opengl es. There are differences that would need to do stuff like #if ANDROID.
I mentioned earlier that mobile is not an important target for TrueCraft.
Okay, then this topic is closed. OpenTK do have better performance compared to monogame
Yeah, because MonoGame is just an XNA shim on top of OpenTK.
I've pushed most OpenGL wrapper code to opentk, there are a few gotchas since this is all code I've written before and have just imported into this project;
- Declarations of inheritance and implementation are indented, feel free to run a macro replacing
\n:with:, I'll probably do that anyways. - Most types are disposable. This is due to the fact that OpenGL handles need to be deterministically disposed of. The pattern is any objects encapsulating handles inherit from
SafeHandle, which provides proper methods of disposal and the possibility of implementing an OpenGL handle 'finalizer' later on. Any objects containingSafeHandleor derived members should implement IDisposable, but needn't override their finalizer or raise disposal events. - Enumerations and other value types are essentially their equivalent OpenTK value types. This is because the code was intended to be a complete game runtime; you shouldn't have to even know it's based on OpenTK to use it.
- Because the proper IDisposable pattern is throwing an
ObjectDisposedExceptionif an object is accessed in any way after disposal, I've implemented most properties literally, instead of letting the compiler auto-generate them. - The Input namespace is essentially a thin shim around OpenTK. Again, the code was intended to be a complete runtime. Think of it as having the ability to extend/modify keyboard functionality later, without forking OpenTK and modifying
KeyboardDevice. - Other miscellaneous style guide (violations?). We can probably fix those up with macros, like I said earlier.
That's all I can think of off the top of my head, I still have an OpenAL wrapper we can import when we get to that point, as well. If you have any questions or suggestions don't hesitate to ask.
It looks good. I'd like to see how it's going to integrate with the client.
Sure, should we purge the files in the client on this branch and port them over one-by-one from master, or just slowly rewrite all of them?
I'm in favor of the "change the dependencies and fix build errors until it works" approach.
Also, if we're providing our own Vector{2,3,4}, can we just use the TrueCraft.Core implementations?
Yeah, probably. We'll have to make sure TrueCraft's vector structs have a `[StructLayout(LayoutKind.Sequential)]`` attribute, and the field order is X, Y, Z, W.
We do already have that, but we'll need to add a Vector4 class.
Unfortunately TrueCraft's vector class uses double-precision components. We can't feed those to OpenGL without expecting a huge performance hit because graphics cards are optimized for single-precision.
Ah. Well, I'd prefer to switch our vectors to single-precision over having two vector implementations floating around.
Actually, that has some protocol implications that we can't really turn a blind eye to. For now I suppose we can just live with two implementations.
There's an implementation of XNA's math library released under the MIT license here, we should probably make use of these classes (especially BoundingFrustum) to save ourselves from writing replicas.
Sure.
Do we want to encode shader information (type + source code) in a JSON file or an XML file?
How about just source? Then we can annotate it like so:
// Some shader v1.2.3.4
// key=value
// key=value
// ...
[ source code ]
That works.
I'm not entirely sure what's going on in the OpenTK branch right now. How can I help?
It's a bit complicated. The Input namespace is complete, you might want to add key bindings after we reach our stage of development in XNA. The Maths namespace contains the XnaGeometry library, so if you want an XNA math class like BoundingFrustum, import it from there. The Graphics namespace is where most of the work is being done right now. There are the more abstract classes like sprite-rendering, meshes, and camera in the base namespace, with the OpenGL one containing specific, low-level classes. For the most part the OpenGL namespace is complete, with the exception of a Texture1D, Texture3D, and TextureCube classes. In the Graphics namespace we have sprite rendering which needs to be completed. I'm working on a content-caching system so that we can load our textures without using System.Drawing and load custom shader source files. Other than that, the entire TrueCraft client still needs to be ported to the runtime.
Progress report? Haven't seen activity in the branch in a while.
Busy with other projects. Feel free to contribute more to get this one done faster.
Sorry I've been busy. Returning my focus to TrueCraft and will be investigating this today.
After banging my head on this for a while, I'm thinking that we might want to drop this effort and instead focus on getting MonoGame working consistently across platforms. The key issues with MonoGame are:
- Weirdness on Windows (solvable)
- Unable to compile shaders on non-Windows platforms (unsolvable)
The second one is a big problem. As for the first one, I don't use Windows and I'm unwilling to buy a Windows license. So, this merits some discussion. For now, I think that we can live with BasicEffect and wait for MonoGame to get their shit together. Anyone have thoughts?
I don't have any complaints, as long as client development can resume. It's strange, however, that moving to OpenTK causes issues on Linux, since MonoGame uses it under the hood?
MonoGame does use it under the hood, but it's pretty poorly documented and I'm having a hard time figuring out why the stripped down demo doesn't work, or even finding anyone else's stripped down demo to test with.
Yeah, most OpenGL demos are in C/++, and OpenTK isn't a 100% faithful implementation of the OpenGL API anyways.