You do not want to resize anything at all but instead.
- Rendering to a target that will fill the game window on a 1 to 1 ratio exactly.
- Render that target to your game window / screen with a shader.
To clarify that’s what you need to focus on, how to avoid any resizing in the first place.
So first of all - the question is - do you change the rendertarget size of the backbuffer when resizing?
That’s not done by default
To that regard.
You should note that their is a difference between the ideas of
the rendertargets width and height
the back buffer
the client size window bounds
the tile safe area
the current modes resolution
the monitors resolution itself.
Im not sure a 1 pixel scanline is as simple as it sounds i mean if this has to really be 1 pixel.
I can imagine a lot of ways this could get messed up.
Monogame has been a little quirky on this stuff. To the point you will need to check these things for equality for yourself and possibly adjust them during runtime not just at construction.
Any suggestion or idea of using GetData()/SetData() to do this is just crazy. Stop that right now.
Yep just wanted him to be able to see it for himself.
Its not unusual for some new people to have to see it fail to fully believe it or in general for some people to want to know why something won’t work in fact its expected. The quicker he is 100% on that, the better.
He could literally test it with that class in about 15 minutes there wasn’t much to tweek to make it work he really would get like 1 to 3 fps tops, its simply not going to work anyways.
That class i showed was originally made for xna specifically for programmatically done paint operations from and to disk only, within xna and for operations on multiple enormous bitmap sprite-sheets for automated editing operations. Hence why there are methods for cutting and placing parts of a color array in and out of a texture. Which is all its really useful for. Not real time rendering in any way.
as resizing isn’t going to be a good option performance wise as I do need to do this
for the full screen every frame.
The heavy iterative nature of these operations and other similar operations is why we have gpu’s. Hardware scaling is much much much faster then cpu side scaling. but scaling has other considerations gpu side as well such as aliasing (which are still explored to this day). This particular shader problem specifically hits on another which is known as artifacts but in this case it can generate entire lines of them instead of pixels here or there.
Consider the following… which can apply to even a simple painting operation
You have just 3 white lines at the following rows y0 y2 and y4 in a texture that has a total of 5 lines.
You have to expand this to a texture that has a total of 8 lines up to row 7.
Do you now put them at y0 y3 y6 leaving a 2 line gap between each or do you make a extra line and have a line at y0 y2 y4 y6 with a extra empty line at the end ?
Or do you have the same number of lines but some are two pixels in height or are some antialiased to a shade of grey.
Can you tell me exactly how you can make just this original texture proportionally identical to the destination with integer based real world physical screen elements that may not match what your final position width height is lets say when it has a total of 10 lines, i.e. this https://images.duckduckgo.com/iu/?u=http%3A%2F%2Fecx.images-amazon.com%2Fimages%2FI%2F41J73haYBKL.jpg&f=1 will your app automatically make the users screen resolution his monitors maximum. The problem with scaling is there is a lot of context and the more detailed you get the more complex it is to control it and some of it you might not even realize may not be fully in your control.
When you talk about a one pixel scan line, that’s pretty deep there is a lot of context to consider.
So the simple solution here is to ensure you avoid allowing any scaling at all, or avoid any solution that depends on using it at all. In combination with being assured the physical monitor or screen wont also be getting a scaled version of things visually that affect what you expect to see,
Its not like the screen will change its physical size because you change the back buffer hieght.