Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error

Options
Go to last post Go to first unread
Offline elasto  
#1 Posted : Thursday, May 3, 2012 3:00:33 AM(UTC)
elasto

Joined: 8/23/2011(UTC)
Posts: 245

Thanks: 6 times
Was thanked: 12 time(s) in 11 post(s)
Ok, so I've made changes to Delta.Rendering.Basics.Drawing that, let's say for the sake of argument, the Delta Engine team do not wish to incorporate into Delta Engine.

How would I get the build process to use my local version as opposed to the standard Delta Engine DLL?

I've tried bringing the various classes into my own Project (still keeping the Delta Engine namespace), but, as I expected, they run up against scoping issues - with various classes and methods internal to Delta Engine being inaccessible outside of it - and with some parts of Delta Engine still closed source I can't get round that.

How is it anticipated that I should be dealing with this issue? Thinking about it now, if I move my project entirely inside of the Delta Engine solution, would that work? Seems overkill if there's an easier way, though - and I could imagine the build engine still getting tripped up...

---

Btw, the changes I've made may or may not be useful to others. I don't know if it meets with the vision for RenderLayer going forwards...?

Basically, instead of one instance of DrawManager, there is an array of instances (created on demand) with potentially one DrawManager per RenderLayer:

ie. Instead of

Code:

private static DrawManager instance

internal static DrawManager Instance
{
    get
    {
        if (instance == null)
	{
	    // Needs to be created via factory to make sure we only do this once
  	    instance = Factory.Create<DrawManager>();
	}
	return instance;
    } // get
}


It goes:

Code:

private static DrawManager[] instances;

public static DrawManager Instance
{
    get
    {
        return Instances((RenderLayer)((MaterialManager.layers.Length - 1) / BaseMaterial.NumberOfBlendModes));
    } // get
}

public static DrawManager Instances(RenderLayer drawLayer)
{
    // If we have not yet created our DrawManager array, do so now
    if (instances == null) instances = new DrawManager[(MaterialManager.layers.Length / BaseMaterial.NumberOfBlendModes)];

    // If we have not yet created our DrawManager instance for this renderlayer, do so now
    if (instances[(int)drawLayer] == null) instances[(int)drawLayer] = Factory.Create<DrawManager>(drawLayer);

    // Return the appropriate DrawManager
    return instances[(int)drawLayer];
}


With the DrawManager constructor accepting the required RenderLayer

Code:

protected DrawManager(RenderLayer drawLayer)
    : base("DrawManager", typeof(MaterialManager))
{
    try
    {
	// The line material is an empty material with just the shader.
	// Note: 2D and 3D Positions are different in vertex data, both use
	// pretty much the same shader, but we need to 2 materials anyway.
	line2DMaterial = new Material((Texture)null, Shader.Create(
  	    // Note: This even works for VertexCompression because the Content.xml
	    // does save the original shader flags, not the modified ones in the
	    // case the VertexFormat of the shader uses vertex compression!
	    ShaderFeatureFlags.Basic |
	    ShaderFeatureFlags.UI2D |
	    ShaderFeatureFlags.NoTexturing |
	    ShaderFeatureFlags.ColoredVertices))
	    {
		    // Make sure that we always see the lines and aren't hidden by any
		    // "normal" geometry because the lines are usually used as debug
		    // information
		    // DrawLayer = (RenderLayer)((MaterialManager.layers.Length - 1) /
		    //	    BaseMaterial.NumberOfBlendModes)
                
		    // Assign the prescribed draw layer
		    DrawLayer = drawLayer,
	    };
...
}


And with the various Drawing operations now overloaded to accept a RenderLayer parameter - and the draws themselves all using DrawManager.Instances(drawLayer) instead of DrawManager.Instance:

Code:


public static void DrawOutline(Rectangle rect, Color lineColor)
{
    DrawOutline(rect, lineColor, (RenderLayer)((MaterialManager.layers.Length - 1) / BaseMaterial.NumberOfBlendModes));
}

public static void DrawOutline(Rectangle rect, Color lineColor, RenderLayer drawLayer)
{
    // Skip if the drawArea is certainly outside of the quadratic space.
    // Checking the screen area would work too, but is a little slower and
    // won't exclude much more anyway.
    if (rect.Left >= 1.0f ||
        rect.Top >= 1.0f ||
        rect.Left < -rect.Width ||
        rect.Top < -rect.Height)
    {
	// Skip this material rendering, not visible this frame.
	return;
    }

    DrawManager drawInstance = DrawManager.Instances(drawLayer);

    Point topRight = rect.TopRight;
    Point bottomRight = rect.BottomRight;
    Point bottomLeft = rect.BottomLeft;

    drawInstance.Draw2DLine(ref rect.TopLeft, ref topRight, ref lineColor);
    drawInstance.Draw2DLine(ref topRight, ref bottomRight, ref lineColor);
    drawInstance.Draw2DLine(ref bottomRight, ref bottomLeft, ref lineColor);
    drawInstance.Draw2DLine(ref bottomLeft, ref rect.TopLeft, ref lineColor);
}

Edited by user Thursday, May 3, 2012 3:05:53 AM(UTC)  | Reason: Not specified

Wanna join the discussion?! Login to your forum accountregister a new account. Or Connect via Facebook Twitter Google

Offline elasto  
#2 Posted : Thursday, May 3, 2012 11:48:37 AM(UTC)
elasto

Joined: 8/23/2011(UTC)
Posts: 245

Thanks: 6 times
Was thanked: 12 time(s) in 11 post(s)
Well, I'm really happy with my changes - it renders in the required renderlayer just how I'd wish. It seems like it shouldn't work, though; When it runs it displays a warning:

Code:
Warning: 	Found an existing dynamic module already! This is not allowed, each module should be a singleton and only be initialized once! Existing module with all children will be removed: Delta.Rendering.Basics.Drawing.DrawManager: Name=DrawManager-Background, Children=0, Parent=null, this module has the name 'DrawManager-9': Delta.Rendering.Basics.Drawing.DrawManager: Name=DrawManager-9, Children=0, Parent=null

Warning: 	Found an existing dynamic module already! This is not allowed, each module should be a singleton and only be initialized once! Existing module with all children will be removed: Delta.Rendering.Basics.Drawing.DrawManager: Name=DrawManager-9, Children=0, Parent=MaterialManager, this module has the name 'DrawManager-UI': Delta.Rendering.Basics.Drawing.DrawManager: Name=DrawManager-UI, Children=0, Parent=null

Since I gave the different DrawManagers different names it must be doing a lookup based on the class.

I am running DrawManager.Run myself though, so that's perhaps why this warning doesn't cause me any problems?



As an example of what I'm using this for, I'm creating a Fog of War effect in my game thus:
At the lowest renderlayer level, I draw a white rectangle filling the screen; Then I draw black circles at the position of each unit.
Then, one renderlayer up I overlay this with a partially transparent background map.
The effect is of a white mist beyond the range of all friendly units.

Of course, I only render enemy units if they are also within range of a unit - giving the effect of enemy mobs appearing from the edges of the mist.

(I could do this same effect by drawing mono-colour bitmaps, but clearly it's going to be faster this way.)

If for some reason this change is a no-go, then I imagine in this instance I could cut and paste the sections I need from DrawManager into my own pseudo-DrawManager class - I imagine I can avoid scoping issues by cutting it to be bare minimum - but it's still an interesting question in general, I think: What is the plan for people wishing to build with their own versions of the Delta Engine dlls?
Offline Benjamin  
#3 Posted : Thursday, May 3, 2012 3:20:41 PM(UTC)
Benjamin

Medals: Admin

Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover

Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
Cool idea, I have written a feature to include your changes some day (not today ^^).

Basically there are two options how to work with your own Delta Engine modifications:
- Keep it private. Only modify your DeltaEngine repository locally and merge for every update (most of the time there won't be any conflicts). This is what all game teams have been doing since we ever released a release. Often they update a few more times but then stuff runs out of sync (especially if heavy changes are incoming or might brake things like in the internal v0.8 beta) and they will stay with "their" version instead. This is obviously the worst option for the Delta Engine and community, but it is a very good one for independant game teams.
- Make your changes public. Either post a request like you did with some source code and wait until it is implemented by me or create your own Delta Engine branch (called Fork at http://DeltaEngine.Codeplex.com).

In either case you can use the locally changed csproj directly and it will be respected in all your builds (Visual Studio or launcher). You could also replace the dll in \DeltaEngine\Dlls, but this will cause a conflict with the next merge (binary files can't be merged) and makes only sense if you want to save compile time or if you don't update the engine anymore.
Offline elasto  
#4 Posted : Thursday, May 3, 2012 4:20:22 PM(UTC)
elasto

Joined: 8/23/2011(UTC)
Posts: 245

Thanks: 6 times
Was thanked: 12 time(s) in 11 post(s)
Ah, ok. So, basically, so long as the projects I am working on I create within my local DE solution all will be well - the build process will respect my local version.

I'll have to do a little reorganisation then but it'll work out fine. Currently I have each project as part of its own solution referencing the compiled DeltaEngine\Dlls - and it doesn't surprise me that the build process can't hook into that.

My reason for having separate solutions is partly historic (I started them as XNA projects) and partly just being tidy (I have five games I'm actively working on(!)) but I can put them all under the same solution if it makes life easier for myself ^_^

Cool :)

Edited by user Thursday, May 3, 2012 4:22:08 PM(UTC)  | Reason: Not specified

Offline Benjamin  
#5 Posted : Thursday, May 3, 2012 5:20:16 PM(UTC)
Benjamin

Medals: Admin

Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover

Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
Actually it does not matter how you setup your solutions.

All you do submit with the Launcher is your projects csproj file and whatever is setup there will be used: Either fixed dll assembly references, e.g. Delta.Engine.dll or System.dll or csproj project references.

No dlls are transmitted (as they cannot be transformed for other platforms, but you can upload them as windows assembly dependencies in the ContentManager if you only need them in your windows build), so the only source code you will be using in the Launcher is whatever is linked up in your csproj (can be as complex as 100 recursive dependency csproj files or just a single csproj with some source code, doesn't really matter).
Offline elasto  
#6 Posted : Thursday, May 3, 2012 6:07:30 PM(UTC)
elasto

Joined: 8/23/2011(UTC)
Posts: 245

Thanks: 6 times
Was thanked: 12 time(s) in 11 post(s)
Well knock me down with a feather...

Do you know that it didn't occur to me until just then that a Project can be in more than one Solution...? The joys of being a self-taught programmer... :)

I added the Delta.Rendering.Basic Project to my game's Solution, used a Project reference instead of a DLL reference, built and ran it on my iPad and it works like a charm! :)

(Well, I say that... All my rendering works perfectly. Fonts are messed up though, which is a bit weird. Fonts render fine in the Windows build I made at the same time. Maybe it's just a transient thing...

Anyhow, I'm off to sleep now, a very happy lad!)
Offline Benjamin  
#7 Posted : Thursday, May 3, 2012 6:32:46 PM(UTC)
Benjamin

Medals: Admin

Joined: 8/20/2011(UTC)
Posts: 1,421
Location: Hannover

Thanks: 18 times
Was thanked: 97 time(s) in 92 post(s)
If you continue to have problems with fonts you might be using some outdated code maybe? But if you use the latest nightly release (lets say since 0.9.5.14) it should work. If not, I can check why the code rules are not correctly applied. Please also note that there are some open bugs in iOS and Android OpenGL rendering. Most are not critical, but they prevent some optimizations to be used to make rendering much quicker.
Rss Feed  Atom Feed
Users browsing this topic
OceanSpiders 2.0
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Powered by YAF.NET | YAF.NET © 2003-2019, Yet Another Forum.NET
This page was generated in 0.708 seconds.