Monogame on the evercade platform

1

Hello monogame community! :wave:

I’m creating a game and for hobby purposes I want to get it working on the evercade from blaze. You know, for the lols.

The game works on my orange pi one (armv7 32 bit Linux). But there are some problems on the evercade, which has similar hardware and also runs Linux. It’s probably something small but it could be worse.

I was offered help but I think maybe a reach out to the community would help better as I’m not as knowledgeable about monogame and related. I’m a hobbyist and not a professional. I don’t know much about monogame internals either.

Ideally someone with more knowhow gets a dev cartridge and get the OpenGL (es2 or ogl2 shim) build working with evercade vs and handheld.

Wouldn’t it be cool to be able to have the option/platform to release retro inspired monogame games on the evercade? Maybe have its own compilation cartridge? What is the animo for you guys to release your game on the evercade? I can’t speak for blaze/evercade but I think personally that would be pretty cool.

The evercade is a platform for retro games, mainly emulated, but they’re also looking into natively build games. They have two devices, the vs that is a home console, and a handheld with a new model coming up, the “evercade exp”.

I’m using monogame 3.8 exported as arm32 and this works with little effort on my orange pi one board with armbian os. On the evercade it refuges to create the graphics device. Here is the output from Ryan (contactee at blaze/evercade) his run:

Unhandled exception. Microsoft.Xna.Framework.Graphics.NoSuitableGraphicsDeviceException: Failed to create graphics device!

—> System.PlatformNotSupportedException: MonoGame requires either ARB_framebuffer_object or EXT_framebuffer_object.Try updating your graphics drivers.

(…) Stuff at apply changes (…)

I think this has to do with the custom SDL 2 stuff on evercade and applying resolution changes, or something funky I don’t understand. But really I can’t confirm this and don’t know how to confirm this. Could someone with good knowledge of monogame internals or multiplatform stuff communicate with Ryan?

I’m mailing him this thread. So replying to this thread suffices.

Hoping for the best,

  • Joey
2

Joey,

The Evercade looks fun and interesting. In the developer section it mentions they plan to support Unity. I suspect if the device supports Unity it should be feasible to overcome the issues you are seeing and also support MonoGame, although I’m not experienced with Linux or MonoGame internal development.

I might be interested in pushing some content if a MonoGame release pipeline comes to fruition.

-Brett

3

:+1:brett

Is evercade support something I can request on monogame GitHub? Is that appropriate?

4

From the link Brett sent, Evercade uses GLES instead of GL, which to my understanding are not compatible with eachother. MonoGame developers would need to create a GLES backend and reach out to the Evercade developers for an SDK. Given how behind they are with the 4.0 release, I doubt this would be very high priority compared to stuff on their todo list: Next Generation API · GitHub

However, there’s no harm in requesting it: it’s technically feasible, but I can guarantee that it’ll be a low priority goal.

5

Is it possible to leverage OpenGL es support from combining the Linux OpenGL desktop platform with the Android OpenGL es routines? Or are these all in an Android namespace/convention and only meant for use with Android stuff?

I’m a bit afraid of biting off more than I can chew when I think about adding support myself.

I think OpenGL es would be an useful addition especially since this feature of OpenGL es on Linux platforms means hardware acceleration for all (educational) development pi boards, which almost all are armxx with Mali or adreno GPUs just like the evercade. That is a bonus.

I will probably try to clone and build monogame some day just to see if I can understand it.

Thanks for now though! I have a better understanding of the issue.

6

Okay so what I typed earlier didn’t make much sense since Android obviously uses GLES instead of GL and MG has support for Android.

This is a naive evalutation but from what I can gather from examples such as:

OpenGL.Android.cs

GraphicsCapabilities.OpenGL.cs

MonoGame seems to basically load GLES and work around the differences between the two APIs. If this is actually the case, then all you should need to do in create something like OpenGL.Evercade.cs to load in GLES and obviously handle all of the stuff specific to Evercade (windowing, audio, sdk, and probably BRUTE for AoT compilation). Again, this is a naive guess and I would maybe see if you could get in contact with a maintainer if you are serious about this

7

Thanks!

I’ve been browsing and reading the monogame source code.

The evercade is basically just an arm SoC with Linux just like all the pi boards. So maybe OpenGL.PiBoard or OpenGL.ArmSoC makes more sense as an identifier. Evercade uses a custom SDL 2 build for all the windowing stuff. So do most pi board operating systems

What would need to be done (my guess), if someone would please agree

  1. create a copy of the OpenGL desktop project, and call it OpenGLESBoard
  2. change the compiler directives of the copy, undefine OpenGL and define GLES and ignore OpenGL sources and add OpenGL es platform source files to compile
  3. check if you have to change the content pipeline as well or just copy the Android pipeline
  4. prune the project stuff up until a Linux build (optional). But keeping Windows support would be nice if people run windows on their arm development boards

I might be able to pull it off with some good luck. But I think it would be just a few hours work for a more involved monogame backend developer.

One thing though is that it’s (my hacking) maybe not neat enough for the master branch, but if the answer is “no” to add evercade support to it I would try that/it myself.

I’m somewhere between junior and intermediate a developer. It does look mighty educational to me.

8

@Joey_Peters

I think you should open a MonoGame Issue on GitHub, summarize your thoughts from here, link to this thread, and provide some links to Evercade or other documentation.

This might facilitate giving developers a chance to comment on your thoughts who may not be frequenting the this forum. As you stated, it would be better to provide a way for feedback ahead of opening your fork with a PR without a supported issue explaining your plans. Maybe someone will provide a bit more guidance.

If you decide to bite off on this, will be interested to see how it goes.

-Brett

9

Will do. Thanks. :+1: