After a while of debugging why BlendFunctions didn’t behave as expected, I found that after setting the blend functions to BlendFunction.Min, the blend function would be Max instead of Min and vice versa.
My solution is set up as follows: PCL project containing the game logic with MonoGame 3.2.99.1 library (as this seems to be the most recent one NuGet Gallery | MonoGame.Framework.Portable 3.2.99.1-Beta) and a Android and WindowsGL project referencing the PCL project and MonoGame 3.4.0.459.
I believe this to be due to the Portable library being out of date as I checked the .dll with dotPeek and found that the order of the enum to be different than what I see on GitHub for the current version, although that file was never touched again after its first commit in 2011 so I’m not sure why it would be like this (maybe the dotPeek decompile results in a different order?)
Running the same code inside the WindowsGL project that has the new 3.4.0.459 library works as expected.
So while I’m now using Max to set Min, I was wondering if there are any plans to keep updating the Portable lib, or if the Portable library has been replaced by something else?
Thanks in advance,
Stephan
Edit: I also just noticed that using either Min or Max crashes the application on my Nexus 5
Caused by: md52ce486a14f4bcd95899665e9d932190b.JavaProxyThrowable: System.ArgumentException: Value does not fall within the expected range."
I’ve actually been chasing this up for a while now and the long and short of it is that it’s not “officially” maintained by the MonoGame team, but there is one contributor (Simon) who was behind the idea of having a portable version to use for the exact same reason that you proposed. Perhaps I can bring this to his attention because he will have a much more detailed answer.
Basically, from what I know he was the only one that was maintaining that branch but there was one or two issues with maintaining it I believe.
Yes the PCL project is of my invention with the support of Dean on the MG team.
The current aim to to develop a generator that will rebuild the PCL each release as opposed to the manual work I was originally doing. This would then be adopted as an automated process (also generating the NuGet’s as well) for each build/release.
Sadly at the moment it has stalled slightly as both Dean and I are maxed out on other projects / work, so progress has slowed. Although I just got an interesting offer of some help which may speed things along with a little support.
I very much believe in PCL’s as a fantastic way to build cross platform projects without all the fuss of multiple class libraries or linking code files
That would be fantastic, and agreed, the way my solution is set up is very comfortable, no hassle at all when switching between platforms. I’ll have to add iOS to it soon but I expect that to go just as smoothly.
I’ve had a chat with Simon and I’ve proposed that when I have some spare time that I help out with this effort.
I’ve been picking his brain last week and I should have enough information to start on looking into this. Supposedly there are some problems regarding the develop branch of the monogame repository in that there is a lot of duplicate code for various platform projects. This confuses the generator thus meaning that there are some generation artefacts.
I’ll investigate this and modify my own fork to get it working there and then when the time is right, pull it into the upstream develop (with approval permitting).
No ETA! I haven’t even begun talking to the main MonoGame contributors regarding this. Although from what I heard there was some stiff resistance towards it.
I just need to find the time away from my own projects to work on this.
Well, lots of progress going on, so it’s nearing it’s goal.
Both a separate “core” PCL project containing common code (math libs and so on) and a Bait and Switch PCL lib.
Will make sure I get the project (monogame.samples) updated once we have something official out (and generating)
Thanks for all the work you’ve been doing on the PCL version @SimonDarksideJ. It would be a lot more difficult to work on MonoGame.Extended without it.
Just pushed a new proposal for the MonoGame.Core project, still got a few issues for the protobuild build to complete it.
but it generates all the projects, you just need to reference the new .Core project manually.
This should reduce the dependency on a full PCL for all of MonoGame, especially for addon’s.
I takes an assembly and can generate the stub/façade/reference PCL as well as a set of type forwarding. It generates partial classes as code so any correction/tweaks can be done.
which may speed things along with a little support.
. I thought I would mention the GenAPI tool that I got from someone, that got from someone blah blah from Microsoft :