I want to be able to scale the backbuffer according to a ratio when the user resizes the game window. After the window is resized, I change the back buffer width/height and applychanges, the window size then changes to match. I do not want this behavior, how can I block it?
The backbuffer size and window size are linked and you can’t change them independently through the MG/XNA API. most people render to a render target with the desired backbuffer resolution and then render that as a full screen quad to the backbuffer. MG.Extended has a solution that I think hides the complexity a bit (I’m not exactly sure how it works), they call it ViewportAdapters. If you really want to render to the backbuffer directly you can implement platform-specific stuff to resize the window. I’m not sure how stable that will behave for different platforms, you may need to tinker a bit to get it right. Or you can modify the MG source code for the platform(s) you’re targetting.
That is too bad 
This problem doesn’t seem to exist in fullscreen-borderless mode. I can change the backbuffer while the “full screen window” stays the same size as the desktop.
I do not think the RenderTarget solution will not work for me as I have things that use render targets already and I don’t see how to essentially do a global RenderTarget that would consume all the other (sub) RenderTargets.
it’s just one more step, you can render from one RT to another and back etc.
The way to do this is just create a renderTarget with the desired size and
instead of
rendering with spritebatch ( with _graphics.SetRenderTarget(null) )
setting _graphics.SetRenderTarget(newRenderTarget) and then
you can use spritebatch
to render the RT to the backbuffer again
Most games render to an RT anyways and only copy to the backbuffer in the end. That way you can reuse the pixel data and apply color grading, post processing etc.
Considering this it should be pretty easy to implement it so you can change the backbuffer and window seperately. But for now XNA API compatibility is an important priority to MG. Btw your Sad Console engine is super awesome 
Thanks! 
This is sort of why it’s hard for me to use the RenderTarget system. It’s an engine, and if I force everything through RenderTarget, that means everything else (and anyone using the engine) needs to be aware of this, which I’m not too keen on. I also have SadConsole running in SFML and you can use the viewport to scale the view without any sort of changes. It’s very simple.
Are there any perf hits to using a rendertarget?
not significant, everyone does it.
You obviously have more gpu memory used, since it is one more texture. And you need one more write when you copy the texture to the backbuffer, so the cost is “drawing one image the size of the screen”. (Plus one rendertarget switch)
The backbuffer itself is a rendertarget, too, if that is a concern for you. You can change its properties to make it have other formats, etc. too.
No difference what rendertarget you draw to as far as i know.
I figured as much but I thought I would check. The last time I had delved into RenderTargets was back before XNA and using (perhaps if my memory serves me correct) DirectDraw and VB6 or something…
Thanks!