What problems could occur if you make use of both the MonoGame API and the underlying graphics API?

Question

What kinds of problems could one run into if they were making a game with MonoGame and started making calls to the underlying graphics API as well?

For example, if I wanted to do something in a MonoGame project that MonoGame didn't necessarily support, or I just couldn't find the proper documentation / example for but I could find an example of how to do it in OpenTK, am I setting myself up for trouble if I implement it using OpenTK directly while using the MonoGame API everywhere else? Specifically I'm looking to find out if there are any big issues that are known that might result of this and not something obscure that will happen in very rare cases.

I tried doing a little research via Google and the GD.SE site itself and I couldn't find much. Maybe MonoGame has really covered most of its bases, but what if I manually wanted to work around one of it's outstanding issues or a feature that is not yet implemented?

If so what sort of problems might arise and are there any ways to help mitigate these issues?

Answer 1

In most cases these problems would fall into the category of "undefined behavior" (not in the C++ sense, but in a more broad understanding).

What you'd be doing is essentially circumventing the abstraction provided by MonoGame (as an example, this of course applies to basically any such higher-level API). In doing so, you can cause class invariant guarantees to be violated, which in turn means the assumptions the MonoGame authors were able to write their code under may no longer be true and the code may behave unexpectedly. Your own code can really no longer rely on the abstraction's invariant guarantees, either, since you've broken them.

This unexpected behavior will include, potentially, the entire gamut of such behavior from simple rendering artifacts to crashes or memory corruption.

• For example, if you fiddle with some rendering API state by end-running around MonoGame itself, it may not be able to detect that state change (because it probably won't poll the underlying API for changes, it's more efficient for it to simply assume it's the one controlling the API and track those changes itself). Consequently it may decide, on the next render pass, that it doesn't need to update something that should in fact be updated and your scene may not correctly render.

• Or you could mess with the underlying API and alter the reference count of some device object (assuming D3D), which means that it may get prematurely released from under MonoGame or accidentally not released, resulting in a probable crash or resource leak.

• Or you could do something that works, but because you are mucking about in an unsupported manner and with undocumented features or unexpected access patterns, you could find your code horribly broken on the next release.

• Or you could do something, it works fine for a few versions, but later you run into some other bug and have difficulty tracking it down, so you ask the MonoGame folks for help, perhaps sending in a bug report because you're sure its a problem in their code. They can't reproduce the bug, of course, and it finally comes out that you're doing this weird direct-access hackery and at that point -- regardless of whether or not your hackery is the root cause of the bug -- they'll probably stop spending resources on your fix simply because you are doing an unsupported thing (or at least, they'll likely de-prioritize you).

Of course, in some cases you might absolutely have to circumvent the API, perhaps to work around a bug in shipping software for which the official patch will not be released in time. If you absolutely have to do this, you should take the soft approach: try to scope your direct access as narrowly as possible, and make sure you try to leave the state of the underlying API as unchanged as possible when you are finished with your meddling. It's not a guarantee of success, but it can help.

Ideally you'll avoid this kind of thing entirely, though.

Answer 2

I agree with Josh's answer fully but I'd like to add some thoughts.

The purpose of MonoGame is to bring the XNA API to many platforms. If you are using OpenTK directly you are restricting yourself to only those platforms that support it. Therefore, you could loose one of the main benefits of using the abstraction.

If you find yourself wanting to do something that MonoGame doesn't support or are having trouble finding the documentation, first ask the more specific question of what you're trying to do. You might find that there's a way to do it already or perhaps it's a planned feature that hasn't been implemented yet.

After discussing it, it may be that you, or someone else, could implement the missing features in MonoGame for everyone's benefit.

Answer 3

With regards on how to mitigate the problems arising on combining those two ideas:

MonoGame is open source, modify it directly and you don't need to worry about problems from using both.

If you think you need additional stuff in it, then by all means: create a fork. Use that base code and add yours on top of it. Recompile MonoGame and there you go. This would also let you update the MonoGame fork when it's updated (of course you'll have to fix any conflicts that may arise in the process).