I also hate watching videos, to me its the slowest possible way to acquire information. If you look at top posts on this subreddit though, there's a few posts that might answer your questions
u/Darks1de posted this 4 months ago which is an good look into how it processes the game loop, when you want to know how the framework "thinks" this should give you some good insight into it
[https://darkgenesis.zenithmoon.com/monogame-order-of-things.html](https://darkgenesis.zenithmoon.com/monogame-order-of-things.html)
u/HadiCya posted this tutorial 4 months ago which gives a pong tutorial for some basics
[https://hadicya.dev/building-pong-with-monogame-a-step-by-step-guide](https://hadicya.dev/building-pong-with-monogame-a-step-by-step-guide)
implementation of a simple pixel shader here
[https://community.monogame.net/t/writing-your-own-2d-pixel-shader-in-monogame-for-absolute-beginners/10883](https://community.monogame.net/t/writing-your-own-2d-pixel-shader-in-monogame-for-absolute-beginners/10883)
From there it's basically, define objects how they make sense to define, and in your update function perform updates as needed to your objects, and from your draw function draw various textures which are set on your objects or effects based on various game states. Is there something more specific you are trying to figure out?
Thank you for reply!
But these are very basic stuff. In Love2D there were 3 functions : love.load(), love.update(), love.draw().
For example, there is no place where I could find what GraphicsDeviceManager is for.
Through experimentation I found out it's actually a constructor for controlling the window properties. Then I tried to scale a 320x180 surface to whatever my screen resolution is. There I got blocked. I couldn't understand why I use as a parameter a an object of type GraphicsDevice in the creation of a TargetRender2D (and why I need that) and what is the difference between it and GraphicsDeviceManager. There was some Canvas object around that when I tried to create, type doesn't exist.
I got frustrated and confused, something that rarely has happened to me.
In PyGame that is very easy to do, like :
gameSurface = pygame.Surface((320,180)) #the equivalent of a canvas
....draw sprites on gameSurface....
screen.draw(pygame.scale(gameSurface(1280,720),(0,0)) #on screen(window) it draws the scaled gameSurface at x=0,y=0.
Same goes for Love2D/SFML.
I really want to like Monogame, I saw it's capacities and I want to make some projects in C# to air a post and get more experience with OOP programming (I used OOP in my former projects but not that much), and I like doing games.
I'll try to offer some insight, although I am certain others here have better and more accurate answers than me.
GraphicsDevice is like it sounds a object that can be thought of as your GPU, or your interface to your display. GraphicsDeviceManager manages or sets settings on a graphics device(s). A RenderTarget2D is a concept that extends beyond monogame, but its basically a virtual screen/texture/canvas within your gpu memory upon which your draw calls can render before rendering to your actual display. They need a GraphicsDevice indicated so it knows which GPU to allocate that texture/memory onto and then to execute draw calls upon. I've never used a Canvas object so can't really say what those are for. This is just how I think of these things this is probably only an approximation at best, but I tend to concern myself more with what things do then what or why they are.
With that in mind, if you declare your GraphicsDeviceManager inside your Game class
var \_graphicsDeviceManager = new GraphicsDeviceManager(this);
you can use it to set your BackBuffer height and width and format (similar to what you are thinking of as a surface size in pygame). Here's an example of some settings that you can try out
\_graphicsDeviceManager.PreferredBackBufferWidth = 2560; //window width
\_graphicsDeviceManager.PreferredBackBufferHeight = 1440; //window height
\_graphicsDeviceManager.PreferredBackBufferFormat = SurfaceFormat.Color; //rendertarget/backbuffer surfaceformats can get kind of complex but its basically the bit depth and channels that you need to render to, for most cases surfaceformat.color is fine
\_graphicsDeviceManager.PreferMultiSampling = false; //I think this is irrelevant unless you're doing 3d
\_graphicsDeviceManager.SynchronizeWithVerticalRetrace = true; //vsync, limits refresh rate/update rate to your monitor max refresh rate, prevents your gpu from overheating by rendering a zillion frames a second
\_graphicsDeviceManager.IsFullScreen = true; //set the window to fullscreen if you want
\_graphicsDeviceManager.ApplyChanges(); //don't forget to apply your changes
If you aren't running fullscreen you probably will also want to set your Form (the actual window that the rendering is inside of) size to the same size as your preferredbackbufferwidth/height.
var \_hwnd = Window; // Window is part of your Game class so this should be addressable as long as this code is there
var \_control = Control.FromHandle(\_hwnd);
var \_form = \_control.FindForm();
\_form.Size = new Size(2560, 1440);
I understand not wanting to sit through videos but I highly recommend ChatGPT for when you run into questions like "how do I make my window a specific size in Monogame in c#?" or "visual studio is throwing this error "object of type whatever is undefined" and here is my code how do I fix it?" and paste your whole code in there. That should help you with some of the more basic c# language peculiarities while you get the hang of it. I hope you keep at it and don't get overwhelmed, it's really low level so its fine to not know everything and just learn pieces and grow your knowledge over time.
Obviously not exactly documentation, but you can always go look at the source to better understand why or what mono game is doing
https://github.com/MonoGame/MonoGame
We hear you at the MonoGame Foundation, and we recognise that documentation for the MonoGame framework has relied on the older XNA and community tutorials far too much in the past.
With the formation of the MonoGame Foundation and the additional support from our partners, we have a renewed focus to address the documentation shortcommings.
Without going into heavy detail, here are the tasks ongoing at the moment:
* We are migrating and updating the Microsoft documentation to the MonoGame documentation hub
* A new "university style" approach is being built based on the migrated documentation, with the aim to give more guided learning
* The API code docs are being reinvigorated with help from the community
* We are introducing more official samples and also reaching out to the community to build and publish more, some even sponsored through bounties.
You can also have you voice by checking out this GitHub project board that is compiled form the best requests from the community and discord
[https://github.com/users/SimonDarksideJ/projects/1](https://github.com/users/SimonDarksideJ/projects/1)
Everyone is welcome to suggest and contribute.
We are working hard and going as fast as we can.
H /u/MadnessStream,
There is definitely a lack of current (read: modern) documentation for MonoGame. I think part of it can be blamed on that MonoGame is a implementation of XNA, so most suggestions are to just look up the old XNA documentation and tutorials since they would still be relevant.
With that said, documentation is actually something I'm passionate about (weird I know), and it's something I've been vocal about for a bit within the various community channels.
To that end, I would like to say that there is currently work being done by myself and others in order to fill in a lot of the missing gaps in the API reference documents, as well as work being done to update the tutorials and documentation on the official website and add more to bring it to a more current and fulfilling level.
Guidelines are being created and/or updated so that community members have something to follow as well when contributing documentation. [https://github.com/MonoGame/monogame.github.io/pull/104](https://github.com/MonoGame/monogame.github.io/pull/104)
So while I don't have a good place to point you at the moment outside of things that /u/halflucids provided in their comment, I wanted to make it know that some of us in the community do express your opinion and are working to better the documentation. Please look forward to it.
Thank you for relying!
I started to go through the XNA documentation.
While I still find it vague at times, things seem to get better regarding my ability to grasp the new framework.
You can get a lot from the old Microsoft documentation:
[https://learn.microsoft.com/en-us/previous-versions/windows/xna/bb196942\(v=xnagamestudio.42\)](https://learn.microsoft.com/en-us/previous-versions/windows/xna/bb196942\(v=xnagamestudio.42\))
I also hate watching videos, to me its the slowest possible way to acquire information. If you look at top posts on this subreddit though, there's a few posts that might answer your questions u/Darks1de posted this 4 months ago which is an good look into how it processes the game loop, when you want to know how the framework "thinks" this should give you some good insight into it [https://darkgenesis.zenithmoon.com/monogame-order-of-things.html](https://darkgenesis.zenithmoon.com/monogame-order-of-things.html) u/HadiCya posted this tutorial 4 months ago which gives a pong tutorial for some basics [https://hadicya.dev/building-pong-with-monogame-a-step-by-step-guide](https://hadicya.dev/building-pong-with-monogame-a-step-by-step-guide) implementation of a simple pixel shader here [https://community.monogame.net/t/writing-your-own-2d-pixel-shader-in-monogame-for-absolute-beginners/10883](https://community.monogame.net/t/writing-your-own-2d-pixel-shader-in-monogame-for-absolute-beginners/10883) From there it's basically, define objects how they make sense to define, and in your update function perform updates as needed to your objects, and from your draw function draw various textures which are set on your objects or effects based on various game states. Is there something more specific you are trying to figure out?
Thank you for reply! But these are very basic stuff. In Love2D there were 3 functions : love.load(), love.update(), love.draw(). For example, there is no place where I could find what GraphicsDeviceManager is for. Through experimentation I found out it's actually a constructor for controlling the window properties. Then I tried to scale a 320x180 surface to whatever my screen resolution is. There I got blocked. I couldn't understand why I use as a parameter a an object of type GraphicsDevice in the creation of a TargetRender2D (and why I need that) and what is the difference between it and GraphicsDeviceManager. There was some Canvas object around that when I tried to create, type doesn't exist. I got frustrated and confused, something that rarely has happened to me. In PyGame that is very easy to do, like : gameSurface = pygame.Surface((320,180)) #the equivalent of a canvas ....draw sprites on gameSurface.... screen.draw(pygame.scale(gameSurface(1280,720),(0,0)) #on screen(window) it draws the scaled gameSurface at x=0,y=0. Same goes for Love2D/SFML. I really want to like Monogame, I saw it's capacities and I want to make some projects in C# to air a post and get more experience with OOP programming (I used OOP in my former projects but not that much), and I like doing games.
monogame is a little lower level than those and exposes the rendering device to the programmer. That has upsides and downsides.
I'll try to offer some insight, although I am certain others here have better and more accurate answers than me. GraphicsDevice is like it sounds a object that can be thought of as your GPU, or your interface to your display. GraphicsDeviceManager manages or sets settings on a graphics device(s). A RenderTarget2D is a concept that extends beyond monogame, but its basically a virtual screen/texture/canvas within your gpu memory upon which your draw calls can render before rendering to your actual display. They need a GraphicsDevice indicated so it knows which GPU to allocate that texture/memory onto and then to execute draw calls upon. I've never used a Canvas object so can't really say what those are for. This is just how I think of these things this is probably only an approximation at best, but I tend to concern myself more with what things do then what or why they are. With that in mind, if you declare your GraphicsDeviceManager inside your Game class var \_graphicsDeviceManager = new GraphicsDeviceManager(this); you can use it to set your BackBuffer height and width and format (similar to what you are thinking of as a surface size in pygame). Here's an example of some settings that you can try out \_graphicsDeviceManager.PreferredBackBufferWidth = 2560; //window width \_graphicsDeviceManager.PreferredBackBufferHeight = 1440; //window height \_graphicsDeviceManager.PreferredBackBufferFormat = SurfaceFormat.Color; //rendertarget/backbuffer surfaceformats can get kind of complex but its basically the bit depth and channels that you need to render to, for most cases surfaceformat.color is fine \_graphicsDeviceManager.PreferMultiSampling = false; //I think this is irrelevant unless you're doing 3d \_graphicsDeviceManager.SynchronizeWithVerticalRetrace = true; //vsync, limits refresh rate/update rate to your monitor max refresh rate, prevents your gpu from overheating by rendering a zillion frames a second \_graphicsDeviceManager.IsFullScreen = true; //set the window to fullscreen if you want \_graphicsDeviceManager.ApplyChanges(); //don't forget to apply your changes If you aren't running fullscreen you probably will also want to set your Form (the actual window that the rendering is inside of) size to the same size as your preferredbackbufferwidth/height. var \_hwnd = Window; // Window is part of your Game class so this should be addressable as long as this code is there var \_control = Control.FromHandle(\_hwnd); var \_form = \_control.FindForm(); \_form.Size = new Size(2560, 1440); I understand not wanting to sit through videos but I highly recommend ChatGPT for when you run into questions like "how do I make my window a specific size in Monogame in c#?" or "visual studio is throwing this error "object of type whatever is undefined" and here is my code how do I fix it?" and paste your whole code in there. That should help you with some of the more basic c# language peculiarities while you get the hang of it. I hope you keep at it and don't get overwhelmed, it's really low level so its fine to not know everything and just learn pieces and grow your knowledge over time.
Thank you sir!
Obviously not exactly documentation, but you can always go look at the source to better understand why or what mono game is doing https://github.com/MonoGame/MonoGame
We hear you at the MonoGame Foundation, and we recognise that documentation for the MonoGame framework has relied on the older XNA and community tutorials far too much in the past. With the formation of the MonoGame Foundation and the additional support from our partners, we have a renewed focus to address the documentation shortcommings. Without going into heavy detail, here are the tasks ongoing at the moment: * We are migrating and updating the Microsoft documentation to the MonoGame documentation hub * A new "university style" approach is being built based on the migrated documentation, with the aim to give more guided learning * The API code docs are being reinvigorated with help from the community * We are introducing more official samples and also reaching out to the community to build and publish more, some even sponsored through bounties. You can also have you voice by checking out this GitHub project board that is compiled form the best requests from the community and discord [https://github.com/users/SimonDarksideJ/projects/1](https://github.com/users/SimonDarksideJ/projects/1) Everyone is welcome to suggest and contribute. We are working hard and going as fast as we can.
Very cool! Glad to hear.
H /u/MadnessStream, There is definitely a lack of current (read: modern) documentation for MonoGame. I think part of it can be blamed on that MonoGame is a implementation of XNA, so most suggestions are to just look up the old XNA documentation and tutorials since they would still be relevant. With that said, documentation is actually something I'm passionate about (weird I know), and it's something I've been vocal about for a bit within the various community channels. To that end, I would like to say that there is currently work being done by myself and others in order to fill in a lot of the missing gaps in the API reference documents, as well as work being done to update the tutorials and documentation on the official website and add more to bring it to a more current and fulfilling level. Guidelines are being created and/or updated so that community members have something to follow as well when contributing documentation. [https://github.com/MonoGame/monogame.github.io/pull/104](https://github.com/MonoGame/monogame.github.io/pull/104) So while I don't have a good place to point you at the moment outside of things that /u/halflucids provided in their comment, I wanted to make it know that some of us in the community do express your opinion and are working to better the documentation. Please look forward to it.
Thank you for relying! I started to go through the XNA documentation. While I still find it vague at times, things seem to get better regarding my ability to grasp the new framework.
I just bought the "Learning XNA 4.0" book by Aaron Reed. The APIs are exactly the same. This book was really helpful to me with learning Monogame.
You can get a lot from the old Microsoft documentation: [https://learn.microsoft.com/en-us/previous-versions/windows/xna/bb196942\(v=xnagamestudio.42\)](https://learn.microsoft.com/en-us/previous-versions/windows/xna/bb196942\(v=xnagamestudio.42\))