does anybody know how to create my own color struct? I tried deriving from xna’s Color struct but it’s sealed.
I would like to make it drawable within monogame as I am using that for the base of engine.
I don’t want to use monogame/xna’s color struct because I want to beable to use my engine without the use of monogame.
Structs cannot be inherited from. The Color struct is very general and doesn’t have anything specific to MonoGame tied to it aside from some of the other types in the namespace (Vector3, Vector4, etc.). What is it about it that would prevent you from using it in your engine? If you have your own definitions of some basic structs, like Vector2 and Vector4, you could copy the Color struct and define it in your namespace, or define your own Color struct in your namespace.
If you do this, you might not be able to use SpriteBatch, but if you don’t use it to begin with, it should be fine.
I do use the sprite batch for drawing its just done inside my library.
my main problem is making my own color struct that that can be used it the sprite batch.
unless there is a way to draw integer colors to the screen with gpu acceleration that I don’t know of.
My main goal is just to hide monogame behind my library to where it is no longer necessary to include it.
Even if you could inherit from a struct, it would tie your Color implementation to MonoGame and you’d be unable to use it without MonoGame. @markus and @DexterZ solution will have your color struct still depend on MonoGame.
I got two alternative to what Chuck suggested:
Conditional compilation and no conversion overhead, by using explicit layout to simulate unions (like in C) and having a Microsoft.Xna.Color member field. This lets you interpret the data in your color struct as a MonoGame Color. Your struct must have the same layout as MonoGames Color struct for this to work. Here’s a Gist with an implementation: https://gist.github.com/Jjagg/9b8c7c8f90dbe936e495ce010c446f32
Have extension methods in another assembly to do conversion from and to MonoGames Color struct so you don’t need conditional compilation in your main library, but can just include the conversion assembly when you use your lib with MonoGame.
You don’t need to link to MonoGame (add it as a reference), but you’ll need to provide the dll with your game so your class library can call into it. So yeah, you’ll still need to include the MonoGame dll with your game.
Oh, you want everything to be contained in one dll. I thought you only wanted to avoid having to reference MonoGame from your game project. There are ways to bundle multiple dll’s into one.
It’s not just MonoGame.dll though. MonoGame depends on other dll’s, just have a look at your output folder.
Why do you care so much about only having one dll? Are you planning to publish your engine and you want it to look as simple as possible?
@markus this is what I wanted…
however I have a small problem that i don’t think needs another topic.
how do I handle hooks for monogame in a static class?
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
using System.Reflection;
using Microsoft.Xna.Framework;
namespace AC.Engine
{
public static class Program
{
[STAThread]
static void Main()
{
AppDomain.CurrentDomain.AssemblyResolve += CurrentDomain_AssemblyResolve;
}
static Assembly CurrentDomain_AssemblyResolve(object sender, ResolveEventArgs args)
{
using (var stream = Assembly.GetExecutingAssembly().GetManifestResourceStream("MonoGame.Framework.dll"))
{
Byte[] assemblyData = new Byte[stream.Length];
stream.Read(assemblyData, 0, assemblyData.Length);
return Assembly.Load(assemblyData);
}
}
private static Game game = new Game();
static void Run()
{
game.Run();
}
//Hooks how do I run them?
static void Init() { }
static void Tick() { }
static void Draw() { }
}
}
You have to inherit from the Game class and override the Initialize, Update and Draw methods to call your static functions. I’m assuming that you can’t call the static functions directly, because they are in a different assembly, that you don’t want to reference, right? In that case you pass the static functions as delegate parameters to your game class constructor.
public class MyGame : Game
{
Action init;
public MyGame(Action init)
{
this.init = init;
}
protected override void Initialize()
{
init();
base.Initialize();
}
}
I don’t understand enough about how your engine will be used from a user perspective. Can you explain a bit more how having those functions is ruining the user experience?
again I just want to hide monogame behind my library so the user only has what I expose to them
is no that is ruining it, I just want to do this for learning purposes.
Pretty sure that goes against the MonoGame licence… you need to be very clear of your intention there, to me it sounds like you want to hide the use of MonoGame in order to appear as an entirely new framework, this is not only possibly against the MG licence but also illegal.
You should probably show a design document for this usage.