[PAID BOUNTY] A shared base for public and console repos #8309

tomspilman · 2024-05-20T13:21:04Z

This is a WIP on the shared native base for future platform work.

Looking for feedback on the structure of things before i finish the implementation and finalize it.

~~C# to C++ wrapper generator.~~
~~C# native wrapper.~~
~~Windows VK setup.~~
C++ native wrapper. (WIP)
SDL native backend. (WIP)
Vulkan rendering backend. (WIP)
Input native backend.

tomspilman · 2024-05-20T13:26:13Z

MonoGame.Framework/Platform/Native/Interop.cs

+    public int MaxVertexBufferSlots;
+}
+
+internal static unsafe partial class MGG


We need to wart these with something that works for us in C# and in C++ (don't want conflicts with other native libs).

So i'm thinking:

MGG for Graphics.

MGA for Audio.

MGI for Input.

MGF for Framework?

Thoughts?

tomspilman · 2024-05-20T13:30:51Z

src/monogame/include/csharp_MGG.h

+#include "csharp_structs.h"
+
+
+struct MGG_GraphicsDevice;


The idea here is the C++ implementation will define the internals of these pre-declared structures.

For example one for DX could look like:

struct MGG_GraphicsDevice { ID3D12Device* _device; ID3D12GraphicsCommandList* _commandList; ID3D12CommandQueue* _commandQueue; // etc! }

This would be how native platforms pass along its data across pinvokes.

The C# just passes pointers and the C++ is responsible for allocation and freeing of these types.

src/monogame/include/csharp_common.h

tomspilman · 2024-05-20T13:32:17Z

src/monogame/include/csharp_enums.h

+
+#include "csharp_common.h"
+
+enum CSSurfaceFormat : csint


Same here... MGSurfaceFormat instead of CSSurfaceFormat ?

tomspilman · 2024-05-20T13:35:12Z

Tools/MonoGame.Generator.CTypes/PInvokeWritter.cs

+        //
+        // So skip these.
+        //
+        if (type.GetCustomAttribute<IsReadOnlyAttribute>() == null)


Feels sloppy depending on the readonly flag to identify our handle types.

Any better ideas?

My idea was to skip the types which names end in Ptr.

tomspilman · 2024-05-25T15:12:21Z

src/monogame/null_device/MGG.cpp

+
+MGG_GraphicsDevice* MGG_GraphicsDevice_Create()
+{
+	auto device = new MGG_GraphicsDevice();


@harry-cpp what do you think of having a no op backend that has empty implementations?

Seems it could be good for some cases.

tomspilman · 2024-05-25T18:44:58Z

Both projects need to be fully hooked up to the CAKE Frosting build system

@harry-cpp what do i need to do for this?

Is it just building? Or is it also a project generator for C++?

I had assumed we would maintain C++ projects manually on a per-platform basis.

tomspilman · 2024-05-25T21:04:26Z

MonoGame.Framework/Platform/Native/Interop.cs

+/// <summary>
+/// MonoGame image native calls.
+/// </summary>
+internal static unsafe partial class MGI


I think we should ditch StbSharp for native stb directly since we have a native library.

This API exposes reading images (jpg/png) from memory as well as writing jpg and png.

We could implement more here in the future.

tomspilman · 2024-05-25T22:31:25Z

@harry-cpp @mrhelmut

I assume we'll have one Windows C++ project for a monogame.native.dll that depending on build configuration would build Vulkan or DirectX?

Or should we plan on multiple C++ Windows projects?

I assume we won't support runtime swapping of Vulkan or DX12? Especially since we pre-build the effects for the platform. (IMO this is a gimmick and not actually useful in shipping games)

So we will end up with WindowsVK and WindowsDX as platforms sort of like we had before with WindowsGL.

Also i assume WindowsGL is going away.

mrhelmut · 2024-05-26T06:28:13Z

I assume we'll have one Windows C++ project for a monogame.native.dll that depending on build configuration would build Vulkan or DirectX?

I don't have a strong opinion on this. Whatever seems smooth enough in regard to Linux, macOS, and consoles moving to that too.

I assume we won't support runtime swapping of Vulkan or DX12? Especially since we pre-build the effects for the platform. (IMO this is a gimmick and not actually useful in shipping games)

It doesn't feel useful to me. Not on the C++ at least. Worst case we can manage that on the C# side of things with a simple switch loading either native dll at launch.

harry-cpp · 2024-05-26T08:37:22Z

@harry-cpp what do i need to do for this?

It should:

build all the generator projects
run all the generators
ensure no file is now in modified state compared to before running the generators (aka. all the generated files were properly committed)
build all the native projects

Is it just building? Or is it also a project generator for C++?

I had assumed we would maintain C++ projects manually on a per-platform basis.

CAKE is just building the projects. But.

We should use some cross platform solution for building the projects as VS projects are Windows only. Some of them even support generating a VS project for you to work in. Good options are meson and cmake.

tomspilman · 2024-05-26T16:23:23Z

MonoGame.Framework/Graphics/Texture3D.cs

@@ -74,11 +74,7 @@ protected Texture3D (GraphicsDevice graphicsDevice, int width, int height, int d
 		{
            ValidateParams(level, left, top, right, bottom, front, back, data, startIndex, elementCount);

-            var width = right - left;


I figured i would fix bad platform apis when i could.

Here it was passing left, top, right, bottom, front, back.... AND width, height, depth.

So i removed the extra data passing that not all platforms need.

tomspilman · 2024-05-27T16:04:03Z

MonoGame.Framework/Graphics/SamplerStateCollection.cs


-		internal SamplerStateCollection(GraphicsDevice device, int maxSamplers, bool applyToVertexStage)
+		internal SamplerStateCollection(GraphicsDevice device, int maxSamplers, ShaderStage stage)


This felt like a better design moving forward.

tomspilman · 2024-05-27T16:13:28Z

src/monogame/include/csharp_GameWrapper.h

+
+#pragma once
+
+#include "csharp_common.h"


The prefix csharp_ feels wrong here. Better ideas? gen_ or api_ or something?

tomspilman · 2024-06-04T14:16:47Z

src/monogame/vulkan/RebuildMGFX.bat

@@ -0,0 +1,19 @@
+@echo off


Decided it was best to keep the generated binary effect files in per-platform folders instead of all in a common place.

This seems like a good direction considering console support.

tomspilman · 2024-06-04T14:18:39Z

MonoGame.Framework/Platform/Native/TitleContainer.Native.cs

+        // Or do we make the native code transform the string?
+        //
+        var absolutePath = Path.Combine(Location, safeName);
+        return File.OpenRead(absolutePath);


Will be moving the file path fixup to native code.

tomspilman · 2024-06-04T14:20:50Z

MonoGame.Framework/Platform/Graphics/Effect/Resources/Structures.fxh

@@ -80,7 +80,7 @@ struct VSInputNmTxWeights
    float4 Position : POSITION0;
    float3 Normal   : NORMAL0;
    float2 TexCoord : TEXCOORD0;
-    uint4  Indices  : BLENDINDICES0;


This works around an issue DXC/Glsl where unsigned int 4 didn't compile. This shouldn't matter as you never have huge numbers for blend indices.

tomspilman · 2024-06-04T14:21:53Z

MonoGame.Framework/Platform/Graphics/Effect/Resources/Lighting.fxh

@@ -20,7 +20,7 @@ ColorPair ComputeLights(float3 eyeVector, float3 worldNormal, uniform int numLig
    float3x3 lightSpecular = 0;
    float3x3 halfVectors = 0;

-    [unroll]
+    UNROLL


Using macros here so it can be redefined per-platform.

tomspilman · 2024-06-04T14:22:26Z

MonoGame.Framework/Graphics/Vertices/VertexBufferBindings.cs

+        /// <see cref="InputLayoutCache"/>.
+        /// </summary>
+        /// <returns>The <see cref="ImmutableVertexInputLayout"/>.</returns>
+        internal ImmutableVertexInputLayout ToImmutable()


Moved this from DirectX specific code to be shared between platforms.

tomspilman · 2024-06-04T14:23:07Z

MonoGame.Framework/Graphics/TextureCollection.cs

        private int _dirty;

-        internal TextureCollection(GraphicsDevice graphicsDevice, int maxTextures, bool applyToVertexStage)
+        internal TextureCollection(GraphicsDevice graphicsDevice, int maxTextures, ShaderStage stage)


This seems like a better approach considering we may eventually have more shader stages.

tomspilman · 2024-06-04T14:25:41Z

src/monogame/vulkan/MGG_Vulkan.cpp

+
+	LPCSTR id = nullptr;
+
+	if (strcmp(name, "AlphaTestEffect") == 0)


Should we consider making an enum for the stock effects instead of passing around string names here?

tomspilman · 2024-06-04T14:30:02Z

src/monogame/vulkan/MGG_Vulkan.cpp

+
+static MGG_System* System_Get()
+{
+	if (mgg_system != nullptr)


I'm debating if we need some object like MGG_System exposed at the C# level to manage graphics state before a graphics device is created... like initializing the Vulkan API (or initializing DX12).

Or should we let the native code manage this internally?

tomspilman · 2024-06-04T14:31:01Z

src/monogame/vulkan/MGG_Vulkan.cpp

+	VkApplicationInfo app_info = { VK_STRUCTURE_TYPE_APPLICATION_INFO };
+	app_info.pNext = nullptr;
+	app_info.applicationVersion = VK_MAKE_VERSION(1, 0, 0);
+	app_info.pApplicationName = "None";


Ideally we pass down an application name... i assume this is used by drivers and utilities for optimizing/tweaking settings for specific games.

tomspilman · 2024-06-04T14:31:56Z

src/monogame/vulkan/MGG_Vulkan.cpp

+
+#ifdef _WIN32
+
+	HMONITOR primaryMonitor = MonitorFromPoint(POINT{ 0, 0 }, MONITOR_DEFAULTTOPRIMARY);


This is probably all wrong and needs to be rewritten, but it works for this first pass at Vulkan.

tomspilman · 2024-06-04T14:34:35Z

src/monogame/include/stl_common.h

+
+
+template <class T>
+void remove_by_value(std::vector<T>& vector, const T& element)


For now i'm depending on STL for vectors, string, queue, maps, etc.

I have seen differences in functionality and performance across platforms over the years.

I wonder if eventually we want our own small common set of native helper collections to use across our native backends?

tomspilman · 2024-06-04T14:36:23Z

MonoGame.Framework/GameWindow.cs

@@ -34,13 +34,13 @@ public abstract class GameWindow
        /// </summary>
        public virtual bool AllowAltF4 { get { return _allowAltF4; } set { _allowAltF4 = value; } }

-#if (WINDOWS && !WINDOWS_UAP) || DESKTOPGL


Thinking we should just expose this on all platforms and let it be ignored on platforms that cannot use it.

harry-cpp and others added 3 commits February 21, 2024 20:00

[Native] Add generator for c# types used on c++ side

0cf7078

backup

802cd49

Merge branch 'feature-native-enumexporter' of https://github.com/harr…

4305687

…y-cpp/MonoGame into native

tomspilman added the Bounty label May 20, 2024

tomspilman changed the title ~~[PAID BOUNTY] A shared base for public and console repos~~ [PAID BOUNTY] [WIP] A shared base for public and console repos May 20, 2024

tomspilman marked this pull request as draft May 20, 2024 13:22

tomspilman changed the title ~~[PAID BOUNTY] [WIP] A shared base for public and console repos~~ [PAID BOUNTY] A shared base for public and console repos May 20, 2024

tomspilman commented May 20, 2024

View reviewed changes

src/monogame/include/csharp_common.h Outdated Show resolved Hide resolved

tomspilman commented May 20, 2024

View reviewed changes

tomspilman force-pushed the native branch from f66c58e to 6b9557f Compare May 25, 2024 06:37

tomspilman commented May 25, 2024

View reviewed changes

tomspilman force-pushed the native branch 2 times, most recently from 37fb5ff to 5f845ec Compare May 25, 2024 18:43

tomspilman commented May 25, 2024

View reviewed changes

tomspilman force-pushed the native branch from 5f845ec to 93dd444 Compare May 26, 2024 16:21

tomspilman commented May 26, 2024

View reviewed changes

tomspilman force-pushed the native branch 2 times, most recently from 73e2947 to 948100b Compare May 27, 2024 16:03

tomspilman commented May 27, 2024

View reviewed changes

WIP on native wrapper, generator, and vulkan graphics.

0ff0249

tomspilman force-pushed the native branch from 948100b to 0ff0249 Compare June 4, 2024 14:13

tomspilman commented Jun 4, 2024

View reviewed changes

Nebulaxin mentioned this pull request Jun 9, 2024

Update ConsoleCheck to .NET 8.0 #8369

Draft

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[PAID BOUNTY] A shared base for public and console repos #8309

[PAID BOUNTY] A shared base for public and console repos #8309

tomspilman commented May 20, 2024 •

edited

tomspilman May 20, 2024

tomspilman May 20, 2024

tomspilman May 20, 2024

tomspilman May 20, 2024

harry-cpp May 20, 2024

tomspilman May 25, 2024

tomspilman commented May 25, 2024

tomspilman May 25, 2024

tomspilman commented May 25, 2024 •

edited

mrhelmut commented May 26, 2024

harry-cpp commented May 26, 2024

tomspilman May 26, 2024

tomspilman May 27, 2024

tomspilman May 27, 2024

tomspilman Jun 4, 2024

tomspilman Jun 4, 2024

tomspilman Jun 4, 2024

tomspilman Jun 4, 2024

tomspilman Jun 4, 2024

tomspilman Jun 4, 2024

tomspilman Jun 4, 2024

tomspilman Jun 4, 2024

tomspilman Jun 4, 2024

tomspilman Jun 4, 2024

tomspilman Jun 4, 2024

tomspilman Jun 4, 2024 •

edited


		internal SamplerStateCollection(GraphicsDevice device, int maxSamplers, bool applyToVertexStage)
		internal SamplerStateCollection(GraphicsDevice device, int maxSamplers, ShaderStage stage)


		LPCSTR id = nullptr;

		if (strcmp(name, "AlphaTestEffect") == 0)


		#ifdef _WIN32

		HMONITOR primaryMonitor = MonitorFromPoint(POINT{ 0, 0 }, MONITOR_DEFAULTTOPRIMARY);



		template <class T>
		void remove_by_value(std::vector<T>& vector, const T& element)


		#pragma once

		#include "csharp_common.h"

[PAID BOUNTY] A shared base for public and console repos #8309

Are you sure you want to change the base?

[PAID BOUNTY] A shared base for public and console repos #8309

Conversation

tomspilman commented May 20, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tomspilman commented May 25, 2024

Choose a reason for hiding this comment

tomspilman commented May 25, 2024 • edited

mrhelmut commented May 26, 2024

harry-cpp commented May 26, 2024

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

tomspilman Jun 4, 2024 • edited

Choose a reason for hiding this comment

tomspilman commented May 20, 2024 •

edited

tomspilman commented May 25, 2024 •

edited

tomspilman Jun 4, 2024 •

edited