We would like to help MonoGame next version MonoGame 4.0 ???

1

Hello everyone,

Do you like we have to use with GLFW ( include VulkanGL, OpenGL support )into MonoGame. If we use multiple windows

GLFW is easier than SDL.

Can we have to support with MonoGame? If you would like to improve advanced features of MonoGame 4.0

And we don’t need support with x86 because I have generated dlls for Windows, so forLinux and dylib for macOS from vcpkg

Assimp 4.1.x
GLFW 3.2.x
OpenGL 0.0.5
and more are using only x64-window, x64-linux and x64-osx

I think better we use only x64 bit MonoGame because macOS and Linux are using only x64. No x86 apps. We should switch to x64 with windows.

PS: How do I find parameters from methods of dll, so or dylib?

How did you find parameters from sdl2.dll

I know that MonoGame’s SDL from WindowsGL of Github. I saw why do you use “internal” I thought they are hidden and can’t show to import…

Nice idea because linux and macOS are very same like LoadLibrary(). But I can’t find google since I find…

We would like to improve directory for x64 with important dlls like sdl2, glfw3.dll etc …

Before :
/x64 <- *.dll, *.so pr *.dylib

After:
/x64/bin <- *.dll, *.so pr *.dylib

Why do I want bin directory because they made Gtk Sharp 3 for example than it will copy to /x64/* whole Gtk 3 Runtime, Java Runtime or Lua Runtime etc if they use with MonoGame.

It looks better than before. Or You want unpack to temp directory with dlls, sos, dylibs and MonoGame will run. Like Lwjgl3 has embedded dynamic libraries and unpacks to temp directory.

Plea

For Pipeline:

We would like to add viewer if they know about which filename like Model-, Texture-, Effect-, Sound-, Text- or VideoViewer.

For models should not need to worry if you add model than model need to embed texture into packed model xnb - embed texture + model = single binary.

Please don’t forget that:

    // Working directory for dynamic libraries like dll for Windows
    // so for Linux and dylib for macOS
    Type type = Type.GetType("Mono.Runtime");
    if (type != null)
    {
        Console.WriteLine(Path.Combine(Path.GetTempPath()));
        Environment.CurrentDirectory = Path.Combine(Path.GetTempPath());
    }
    else
    {
        Console.WriteLine(Path.Combine(Environment.CurrentDirectory, Path.GetTempPath()));
        Environment.CurrentDirectory = Path.Combine(Path.GetTempPath());
    }

Environment.CurrentDirectory It means working directory for dynamic libraries if MonoGame unpacks first dynamic libraries from memory into temp directory than MonoGame will run and it looks like fast.

Do you like my idea? It works like Lwjgl 3.x unpacks dynamic libraries from jar file into temp directory.

I am very hopeful that we can make safe with MonoGame.

Please accept my idea! And share my suggestion - if you love to listen me than you can replace SDL with GLFW. I hope something…

Thanks!

2

As a lover of MonoGame and XNA, I must simply say… NO!

1 Like
3

Okay you decide that. I know I would like to improve. I can’t say - if other MonoGame Lovers like stable version of MonoGame. Ok, I respect you.

4

@Jens_Eckervogt,

I do not believe the English translations came out as you expected. Ich glaube nicht, dass die englischen Übersetzungen wie erwartet erschienen sind.
I am going to interpret this post as best I can.

Support for x86 comes from XNA and will most likely not be abandoned in the foreseeable future.

It would be beneficial to have viewers-decoders for each Xnb type. Especially for debugging purposes.

I would like to see full binary FBX support including embedded textures, bones, and animations.

As for your actual request of replacing SDL with GLFW, I cannot comment as I only have experience with SharpDX in Windows.

Seien Sie nicht entmutigt.

5

Please do not take one persons opinion as fact.

6

Thanks for replying - I am sorry for bad English.

For x86 will be gone. Like macOS has nothing x86 bit now since Lion ( 10.7 ) I have readden Apple’s website. And Linux OS use now x64 and I see any Windows users work 64 bit computers or laptops why they don’t use x86 computers because x86 is dead. But Visual Studio will come soon to x64 bit.

Yes I know fbx but any other types like dae, obj, mdl or 3ds or other custom model types need embedded textures into single xnb. It looks like Half-Life loads embedded textures from model or zipped like model format.

I understand you love only SharpDX but Linux, MacOS and Android still wait for correct Graphic Layout GL. SharpDX is loving only Windows UWP and XBox…

But i miss OpenGL or VulkanGL “embedded” to Winforms but it can’t able with MonoGame. I thought GLFW works fine with OpenGL and VulkanGL but I don’t know- I will try MonoGame with GLFW and GTK Sharp 3.22, Cocoa, X11 or Winforms ( just i don’t release - I will prepare for Work-in-Process. ) i know I check if GLFW works with SharpDX ( DirectX ). Please don’t hesitate me!

Oh keine Sorge! Ich soll nicht entmutigen. Ich werde mich konzentrieren.

7

To correct you, x86 not only is NOT dead, but has some performance benefits in (some limited) cases as well it is cost effective for poorer people… Generally if you have money to LITERALLY waste on a MacOS compatible computer, you are already willing to pay alot so you will get their super limited brand and thus having x86 and x64 on that platform wouldnt be necessary, your wallet gets raped either way. Not all Linux is x64 exclusive either, and with high performance for less resources (A byproduct of better programming design and utilization of resources) you can afford to play better games on lower end machines meaning x86 people would see better opportunity to play games made by the MonoGame platform should it maintain compatibility.

As well GLFW may be better in performance as a cross platform window tool, it is not specificly designed for game programming and doesnt dedicate as much API for that which can pose a problem as MonoGame is a wrapper over other existing libraries for ‘Cross Platform Write Once Run Anywhere’ type design, it isnt efficient for the work load to basicly limit themselves to only the bare bones and basicly write all the platform specific code necessary beyond what the simple window library offers just for GL support when they have work on so many other things to do… Not only that SDL is a better established library FOR game design -> AKA the people who come here, so people wishing to contribute to MonoGame if they have ANY direct GL experience at a lower level(Which would be the best case scenario if they plan to touch GL design) SDL will be the most likely thing they will be familiar with 90% of the time.

EDIT: To clarify as you seem to believe that GLFW will offer some alternative to making the GL control work, the issue had to do with getting MonoGame context without requiring a unique hidden window generation on every call + External forced re-embedding of the window context into a control… back in TK you could attempt that but only succeed at generating 1 control afterward any others wouldnt produce any graphics when drawing to them… Should access to the MG context without the weird hacky implimentation i mention above be re-granted it would be much less of a problem to do the GL control again… HOWEVER, if you arent in dire need of newer features and/or changes made to MG u can opt for moving to an older version where the solution Jaquadro presented for OpenTK controls with MonoGame WOULD work.