hmmm… You mean like vertexPositions that form 3d shapes, like
new 3dSphere(pos, radius, subdivision);
new 3dBox(pos, length, width, height);
ya
Don’t tell me you already added it and i missed it ?
But really the educational creators club part of the xna forum with the working tested downloadable examples was genius.
hehe, no… But you kind of gave me this itch, like this is something I could do 
-But I’m not experienced enough to know if it is NEEDED…
I mean… There would probably be a library out there that includes this already, right?..
We should get some info from the higher-ups on WHY this doesn’t exist, maybe there’s a good reason… Maybe using simple 3d MODELS is “the way” to do this…
Anyway… Those classes seem pretty reasonable and doable… And the functionality requirements and the logic of it all seems pretty straight forward, in some way…
Anyway, I like the idea for the sake of the idea, so if this takes off, let me know, I’d like to contribute
I think it would be cool to see some built-in animation logic. I know it would be straying away from the original “Cross platform XNA” model, but it would bring more people to the framework and also make it easier for us MonoGamers because it means we wouldn’t have to write that same logic for every single project we work on. On the subject of animation, a way to completely fade out everything being drawn with a GraphicsDevice would also be cool. (So like at the end of our games instead of drawing a black rectangle with a decreasing alpha value we could just call something like GraphicsDevice.FadeOut(Color.Black]);). Also maybe support for the Tiled Map editor, but to be fair we already have 3rd party libraries like Nez or MonoGame.Extended for that.
Wii U, Switch and Browser Support and fix all the bugs
Great idea, we should open an issue for this!
In all seriousness, Wii U support is in progress, my guess is it will take someone with a succesful/promising game to want Tom’s company to port the game to switch to get a backend implemented (proprietary sdk and all) though there are all kinds of difficulties on consoles so that would take a while and finally web is on halt. Web might work with JSIL and some fixes applied, but there are a lot of complications and the popular opinion seems to be (or at least at the time this was last discussed) that waiting for webassembly would be a good option here.
What are the licencing fees though? and are there similar projects as ID@Xbox and PlayStation indie dev portals?
Speaking of which, UWP does not mean your app automatically works on XBOX, any help there?
Separate Microsoft.Xna.Framework.Audio in it’s own project/assembly and enable mix/match (SharpDX + OpenAL or OpenGL + XAudio).
This will give as two audio libraries:
/OpenAL/Microsoft.Xna.Framework.Audio.dll
/XAudio/Microsoft.Xna.Framework.Audio.dll
Implement EventQuery and PipelineStatisticsQuery to help with debuging & betchmarking.
Very similar the current OcclusionQuery but for D3D11_QUERY_EVENT and D3D11_QUERY_DATA_PIPELINE_STATISTICS.
I’ve been meaning to do some clean up on the Protobuild .definition files. We should make better use of services. That will help a great deal with mix-'n-matching. Also important for when we implement the new graphics API’s. I’ve been thinking it would be nice to support soft switches between e.g. Vulkan and OpenGL. By default Protobuild would just generate one backend, but it would be nice if we had a base GraphicsDevice class that contains the current API so you can use Protobuild to generate both backends and swich at runtime. Just an idea 
Also with more different options emerging, I feel like we should really take another look at integrating a project generation tool to avoid having a ton of templates.
I’m unsure about that one… but for sure allowing to switch between OGL or Vulkan at build time would be nice.
Agreed… I’ve been the blocker there on the existing PR for that.
Hello,
Is it possible to separate the Content pipeline from the main Graphics core and have it’s own assembly if it will not break anything of course
IMO content loaders should not be included from the main Rendering pipeline as from time to time it needs update and additional features from the Content managers, while other developers don’t need some of it’s features and only use MonoGame as their primary Rendering engine and wrote their own loaders for their Game engine.
I even wrote my own Obj file loaders that automatically loads every groups diffuse, ambient and bump texture materials and load every images and text files without using the Content pipeline I’m also planning to wrote MS3D(MilkShape) loaders as my primary Animated Mesh from scratch but I don’t want to touch or review how the content pipleline works as I roll my own.
Specially on Android device the whole MonoGame.Framework.dll is loaded into memory while I don’t need it’s other features. I’m just wondering what is the size of MonoGame.Framework.dll without the Content pipeline half the size maybe ?
Add the assembly as needed something like below 
MonoGame.Graphics.dll
MonoGame.Content.dll
MonoGame.Input.dll
MonoGame.Audio.dll
Etc…
Cheers ^_^Y
EDIT :
Make MonoGame light and powerfull rendering engine across devices, but of course if others wanted to use the default content loaders they just add the assembly. I want MonoGame to stay as a powerull rendering engine and not a Game engine; Game engine most likely becomes bloated and slow… just like : - D
This is not a good argument to spit up the assembly. The MonoGame.Framework.dll is less than 2 MB for all supported platforms. Code does not take up much memory. MonoGame is not an engine, it’s just a framework that abstracts away platform specific stuff and offers a nice API on top. That’s why it’s so small and that’s why there’s no need to split it up IMO.
[/quote]
MonoGame is not an engine, it’s just a framework that abstracts away platform specific stuff and offers a nice API on top.
[/quote]
Nice! if that’s the case… it’s a relief that it will stay as a graphic rendering framework for multiple devices
If the MonoGame Team had the resources of Unreal, sure, not an issue…
I think this thread needs to set out some sort of Realistic Goals List somewhere…
We have the chance the team is english/us.
Im a non english dev and i have no problem with english. It is a sort of standard.
But imagine if the team was japanese or chinese… Or russian… And realize the chance you have
Apart from that, vs17 is not available to everyone for instance so i dont think it is a priority.
I’m Chinese.
VS2017 will be available soon.
The templates aren’t installed yet for VS2017, but other than that everything works. MonoGame doesn’t care what IDE version or language version you’re using. If you have an older VS installation you can install MG templates for that version and copy them over for VS2017, that’s what I did.
For supporting .Net Standard we’ll have to move the project files to .NET Core. I’d rather wait with this until it’s properly supported on Linux systems. It will also require Protobuild to generate .NET Core .csproj files, not sure if that’s supported yet since they only just switched back from .json project files to .csproj.
Is there a free version of vs2017? Apart from visual studio community I dont know about that. And i have spent so much money in my 2013 license i wont change version each year microsoft will release a new version. And i think everyone who has paid its license wont upgrade as often as the visual studio’s version.
There is. If you just go to the home page there’s a shiny “Free Download” button.