• Create Account

### #ActualSeraphLance

Posted 29 September 2013 - 04:07 PM

Now that I've had a chance to mess around with the tracing stuff...

I'm still having trouble handling de-duplication.  I've tried a few different designs, but none of them seem to work quite right.  Suppose for simplicity I have two objects -- the renderer and a camera class.  The camera needs to be able to log camera position every update cycle, but neither the camera or the renderer know about the other directly.

This is the only thing I've thought of thus far:

class DebugPrintTraceListener : TraceListener
{

//need to reparse hashcodes and check against a dictionary that gets flushed on read.
public override void Write(string message);
public override void WriteLine(string message);
}

class DebugPrintObject
{
string message;
int hashCode;

public DebugPrintObject(Object parent, string message)
{
hashCode = parent.GetHashCode();
this.message = message;
}

public string ToString()
{
return hashCode.ToString() + " " + message;
}
}

//somewhere in the renderer's initialization -- or containg class, whatever
System.Diagnostics.Debug.Listeners.Clear();

//Somewhere in the camera
System.Diagnostics.Debug.WriteLine( new DebugPrintObject(this, "stuff"));



This should technically work, but the debugging objects are pretty much the definition of disgustingly hacky.

The solution would be easy if I only needed to log, but because of the deduplication problem I need some way of knowing the sender of the tracing data.  The diagnostics stuff doesn't seem to support this, or really supporting anything but sending strings along.  Sure, there's filters on both sides I can use, but it's mostly pointless if the only communication format is a string.

EDIT:  It's worth mentionining that, after all this crap, I'm still using global state, as System.Diagnostics.Debug is just as global and stateful as my old ad-hoc solution, albeit slightly less abstracted.

I thought of another idea:  Put two listeners on System.Diagnostics.Debug.Listeners, we'll call them sender and receiver.  register a TraceSource owned by the renderer with the receiver, and register other TraceSources in every class that wants to write information with a sender.  Every update cycle, the sender owners cache their string data, but don't send.  When the receiver needs to draw, it sends a trace to the senders.  The senders notify their parents, which then call back to the senders to write to the receiver with their data.  This works, doesn't technically use global state (though it leverages global state to set up), doesn't require weird encodings, but holy hell is it incredibly roundabout.  This can't be the best way to go about it.

### #1SeraphLance

Posted 29 September 2013 - 04:02 PM

Now that I've had a chance to mess around with the tracing stuff...

I'm still having trouble handling de-duplication.  I've tried a few different designs, but none of them seem to work quite right.  Suppose for simplicity I have two objects -- the renderer and a camera class.  The camera needs to be able to log camera position every update cycle, but neither the camera or the renderer know about the other directly.

This is the only thing I've thought of thus far:

class DebugPrintTraceListener : TraceListener
{

//need to reparse hashcodes and check against a dictionary that gets flushed on read.
public override void Write(string message);
public override void WriteLine(string message);
}

class DebugPrintObject
{
string message;
int hashCode;

public DebugPrintObject(Object parent, string message)
{
hashCode = parent.GetHashCode();
this.message = message;
}

public string ToString()
{
return hashCode.ToString() + " " + message;
}
}

//somewhere in the renderer's initialization -- or containg class, whatever
System.Diagnostics.Debug.Listeners.Clear();

//Somewhere in the camera
System.Diagnostics.Debug.WriteLine( new DebugPrintObject(this, "stuff"));



This should technically work, but the debugging objects are pretty much the definition of disgustingly hacky.

The solution would be easy if I only needed to log, but because of the deduplication problem I need some way of knowing the sender of the tracing data.  The diagnostics stuff doesn't seem to support this, or really supporting anything but sending strings along.  Sure, there's filters on both sides I can use, but it's mostly pointless if the only communication format is a string.

PARTNERS