Jump to content

  • Log In with Google      Sign In   
  • Create Account

rick_appleton

Member Since 29 Aug 2002
Offline Last Active Jul 05 2012 07:10 AM

Topics I've Started

Gather operation in Entity Component System

25 April 2012 - 01:11 AM

I've started working on an Entity Component System where an entity is only an ID and all the data is held in the different systems. As an example I have two systems: RenderSystem and LocationSystem. Each system stores the data of the entities that have that component in a flat array, and has map of 'entity id'->'array index' for that system.

- LocationSystem contains a position/orientation/bounding box for each entity
- RenderSystem renders each entity using it's position/orientation

Now imagine I have three entities:
Entity 0:
	Location
	Render
Entity 1:
	Location
Entity 2:
	Location
	Render

In the LocationSystem the contents will look like this:
	array = [Location Component A, Location Component B, Location Component C]
	map = [0->0, 1->1, 2->2]

In the RenderSystem the contents will look like this:
	array = [Render Component A, Render Component B]
	map = [0->0, 2->1]

Currently the update for each system is called manually, passing in the map and array from the other systems that are needed, such that each system can then get at the proper data (basically a gather operation):

renderSystem->update( locationSystem.map, locationSystem.array );
RenderSystem::Update( lsMap, lsArray )
{
	for( entityID in this.map )
	{
		RenderComponent rc = this.array[this.map[entityID]];
		LocationComponent lc = lsArray[lsMap[entityID]];

		// Do stuff with the two components here
	}
}

However, I'd like to change this so that the system can iterate over it's own array in it's update function, and doesn't need to bother with the map:

RenderSystem::UpdateNew( ... )
{
	for( i in this.array )
	{
		RenderComponent rc = this.array[i];
		LocationComponent lc = ???;

		// Do stuff with the two components here
	}
}

I guess I could do the reverse lookup outside the function, but I'm wondering if there is some kind of more efficient way to do this, taking into account that if an entity has a RenderComponent, then it also always has a LocationComponent.

Compile times?

27 July 2011 - 06:27 AM

I'm wondering how long it takes to compile your projects. Here at work, I am constantly waiting on the compiler. A full compile of the project takes hours! Touching a single file still takes minutes to compile. :(

Argument-Dependent Lookup error Visual Studio

30 March 2011 - 11:43 PM

I'm having an issue with Visual Studio and Argument-Dependent Lookup of functions.

The following code compiles without problem.
void testFunction( int i )
{
	printf("::\n");
}

namespace n1 {
	void testFunction( int i )
	{
		printf("n1\n");
	}

	void callingFunction( void )
	{
		testFunction(5);
	}
}

yet, this similar code doesn't. It gives me an error about ambigious call to overloaded function, due to finding the global function through ADL.

void testFunction2( HWND i )  //found using argument-dependent lookup
{
	printf("::\n");
}

namespace n1 {
	void testFunction2( HWND i )
	{
		printf("n1\n");
	}

	void callingFunction2( void )
	{
		testFunction2((HWND)5);
	}
}

Is this correct behaviour or a compiler error? If it is correct, is there something I can do to fix this WITHOUT explicitly adding which function I want called? I have a large list of generated functions and I want to selectively replace a few.

Debugging tools ...

24 February 2011 - 01:39 AM

After a couple more lengthy debug sessions involving gDebugger, glIntercept and lots of suppositions about the OpenGL state, I once again have gotten thoroughly frustrated by the state of OpenGL debugging tools. Being a programmer though, there is something I can do about that.

As such I'd like to get a feeling for what useful features would be in such a tool. Some things I can think of, some of which are inspired by PIX or gDebugger:

- Frame saving, replaying. Being able to exactly save the calls and data that generate a specific frame, and then replay them at will later.
- Image and movie capture.
- Shader debugging.
- Performance analysis.
- Bottleneck detection; (fillrate, vertex setup, texture bandwidth).
- Error checking.
- Deprecated function detection.
- Live shader editing.
- Viewing (and modification) of all data; textures, buffers, shaders
- Stepping through calls.
- See what calls render to specific pixel(s).

What would be useful to you?

Storing function arguments

22 February 2011 - 03:00 AM

For a logging utility I'm making I want to log function calls, with the parameters, and optionally the return value. Since the apps using this are usually high-performance, I don't want to take the time converting the parameters to a string inline with the function call. I've decided I want to store this data, and then in another thread I'll retrieve it and do the printing/analysing.

I think one of the fastest ways to store this data is to have a large block of memory, and simply 'push' the function pointer, the arguments, and the return value onto this sequentially. The question I'm now pondering is how to do this efficiently, and in clear code. Each function that will be logged this way can have a different number and type of arguments. Since arguments can have different sizes (bool vs double), I suspect I'll need to use some template or define magic to get this done nicely. However, so far I've not been able to think of a nice way to do it other than writing it out for each argument.

Basically I want to find a way to achieve the following with only a single line of code (or two when adding the return value):

int currentPositionInBlock;
int MyFunction( bool arg1, char* arg2 )
{
	void* fncPtr = &MyFunction;
	memcpy((char*)currentPositionInBlock, &fncPtr, sizeof(fncPtr)); currentPositionInBlock += sizeof(fncPtr);
	memcpy((char*)currentPositionInBlock, &arg1, sizeof(arg1)); currentPositionInBlock += sizeof(arg1);
	memcpy((char*)currentPositionInBlock, &arg2, sizeof(arg2)); currentPositionInBlock += sizeof(arg2);

	int result = ...

	memcpy((char*)currentPositionInBlock, &result, sizeof(result)); currentPositionInBlock += sizeof(result);

Of course I'll also need to retrieve this data and handle it, but since that isn't time sensitive and I know what function takes what parameters, I'm sure I'll manage that.

Kind regards,
Rick

PARTNERS