It would be definitively faster with computeshaders ! 
but we have to deal with the things we have.
I was wondering if I would add SDF after reading unreal4 papers, but as my engine is space dedicated, it would not be very usefull I think, but you are working on a nice feature 
Well, to revive this thread a bit.
I first wanted an experimet a little with Noise algorithms and their use in map generation, and of course, Monogame was quickest to do it.
It seems I went overboard with it.
Basically, map uses multiple OpenSimplex passes to generate terrain, forests, biomes and resources, and by multiplying the input with certain factors, I can control how the map is generated.
Now, the question is, how to progress from here…
This seems like the least obnoxious place to do so, so I’m promoting my game here. It’s not groundbreaking, but it showcases the basics that MonoGame can accomplish and what I think is most important - that MonoGame does save you from having to work with Android and iOS separately.
It’s a simple puzzle game, where the objective is to move over each tile in the level.
Download links:
Android – Google Play Store
iOS – Apple App Store
The community has generally been very helpful - thank you guys. I couldn’t have done it without your help. Still, there remain some issues (ie the S8 flickering as mentioned in this thread and as far as I can see no iPhoneX support). For everyone working on or adding to MonoGame, thanks for all you do - hope you’ll continue to push MonoGame to be better and better.
You can always post a standalone thread, this is just a cumulative thread, so people can just go down one thread and see random concepts…
Original Paper Mario Tattle replication with a RenderTarget zooming in on the enemy (reference).
EDIT: Replaced with shareable link. It was private.
I think your link’s down @Kimimaru. That sounds like fun; I always liked reading up more on enemies in my games (the Yoshi’s Island on DS has a really good enemy zoo you can populate which I haven’t seen in other games too, if that’s something you’d go for).
Anyways, I feel like I’ll weigh in with an update on my progress while I’m here (a montage of my progress after one year working on my love letter to early 3D games):
Ain’t gonna lie, making the mechanics and engine has been fun. But actually making a game using those mechanics can get quite stressful. There’s so much subjectivity on what makes a game fun. Actually designing a level or settling on a mechanic can be a far greater challenge than programming a physics engine. tl;dr, give your level editors a thank you letter next time you see them 
I wrote up a class that stores pixel data of previous frames and can export a frame as an image or a set of frames as a GIF. It uses ImageSharp for the exporting. You can use it to make a GIF exporter built into your game, which is pretty neat. Here’s a gist with the code and a small sample project: https://gist.github.com/Jjagg/b1dce39b23192f46205a75d3a6482073
And the amazing result:
This would make a nice addition to a official monogame extras or utility namespace.
Replication of the text system from the first two Paper Mario games, utilizing “control codes,” which are HTML-like elements in a piece of text that have a variety of effects on the text’s behavior.
All the effects are achieved in one big string ran through a parser. The scrolling and input prompts are also control codes themselves. More details and source here.
Looks awesome! I was just recently thinking about how to implement something similar into the project I’m working on. 
That’s crazy looking.
Made this some time ago but never shared.
Ignore the fact that the objects dissapear for 1 frame when fractured, easily fixed.
What did you use to make that ?
The physics engine I believe is bullet physics, other than that I used a library to compute the Delaunay triangulations and from there my own code to slice the triangles on the cpu.
Graphics engine is my own and texture is from minecraft.
wow nice. Do you cull / assign the lights on the CPU?
yes, since we don’t have CS yet
Just got the shiny ImGui-Viewport stuff working with MonoGame (green balls are just some Verlet balls). Only change to MonoGame was adding access to the DX11 DeviceContext.
Still finishing the bindings, but I’ll post it up onto github once it gets somewhere a bit less disgusting (basically mashed the Win32 DX11 demo into a C++/CLI wrapper and massaged it a bit to take foreign objects (device/device-context/rendertargetview/etc).
Edit:
Tossed the C++/CLI project onto github. Had to make a handful of additional changes to MonoGame.Framework.Windows (for DX11) to get at things I needed (SRV for textures to draw images, Win32 message routing (Application.DoEvents() doesn’t cut it, needed complete Translate/Dispatch processing), and a few other handles needed.
Tossed up some Windows DX11 x86 binaries for the above ImGui viewport stuff: https://github.com/JSandusky/ImGuiCLI/releases - really just a pseudo-demo for anyone wanting to fiddle with it a smidge just to see how all that stuff behaves without messing with making the MonoGame-side tweaks or dealing with C++/CLI projects.
Don’t attempt to roll with these binaries rather than compiling though, the monogame dll used here has some Effect changes for geometry and tessellation shaders on DX11 that could choke on loading Effects from older 2MGFX versions if I screwed something up - and other things that could go terribly wrong (still haven’t tested it outside of this verlet balls stuff).
Yanked out my spline surface class and started working on it again.
I re-wrote the whole thing. Im trying to get it into a fairly sane state before i put it up on github.
I made some crazy hard indexing proportion ratio changes. So i can do basic edge joining.
(the red lines that extend down are adjoinment vertice nodes)
Also to test the natural adjoinment curvature which is basically G2 continuous as far as i can tell.
I made it so it can take a straight up Heightmap in floats.
I added a change so it takes a array of vector4’s instead of 3’s.
Were the w element determines how much curvature occurs at a control point, 0 is none 1 is Continuous on the control point.
The hardest part is everything but creating the surface itself.
