Jump to content

  • Log In with Google      Sign In   
  • Create Account


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

Posts I've Made

In Topic: Gather operation in Entity Component System

25 April 2012 - 03:41 AM

One way to fix this, is to keep using your hash-map as usual, but generate the above keys array on each update - i.e. extract the map's keys and sort them by it's values before running the update loop.

I think this will only work if the components are sorted. If the array with components is not sorted by ID it'll give incorrect results.

N.B. sorting your entire systems can be handy too sometimes. e.g. if Render held [A,B,C,D], but Location held [D,A,C,B], then your update function is going to be iterating forward through the render array, but randomly through the location array. If you first sort them both by their entity IDs, then your update function will be faster due to better cache patterns.

This is the main idea of having the extra indirection there Posted Image
I didn't think of eliminating the values array like that, it's definately a good point. It makes it a bit easier to think about that way, since I then only need to reconcile the two arrays:
array from LocationSystem: [0, 1, 2];
array from RenderSystem: [0, 2];
I think I can safely set the extra limitation that those indexes will be sorted, although that does mean I'll need to move a lot of components if I erase an item in the middle.

In Topic: Compile times?

01 August 2011 - 05:25 AM

Thank you all for your replies. Looks like I'm not the only one then. And thanks for the tips everyone.

In Topic: Argument-Dependent Lookup error Visual Studio

31 March 2011 - 01:21 AM

Thank you all for your replies. I suspected the non-fundamental type thing, but always thought that HWND was actually a void*. After some digging it seems that by default HWND is actually a pointer to a proxy struct. However, adding #define NO_STRICT before including Windows.h reverts HWND to being an actual void* again, which causes the code to work as expected. It obviously won't work for other types, but I think I won't encounter anything else anyway.

In Topic: Setting up a GL capabilities database

25 February 2011 - 03:35 AM

Rows that are identical except for driver version are merged together, but otherwise nothing is discarded, since it seems useful to know the limits of not-the-most-recent drivers. The full data is downloadable as JSON from that page.

Thanks for the info. I could have used this just a week ago :D I'd also see the value in what driver versions support what extensions, so I'm wondering if you've got a specific reason for merging driver version together?

In Topic: Storing function arguments

23 February 2011 - 01:24 PM

Using sizeof( variable-name ) is poor coding practice, particular when you already know the size of the argument. I recommend, in your example, you use sizeof(bool) and sizeof(char*). sizeof() is not a function, it is a compile-time operator. Using a data-type as an argument for sizeof() rather than a variable-name will help remind you what you're really coding.

I'm not sure of the intent of your example function. Just a comment that it might be better to copy the actual data to the log, rather than a pointer to the data. I.e.,

memcpy( logmemory, &arg2, sizeof( arg2 ) ); // copies 4 bytes
// maybe better is..
memcpy( logmemory, arg2, amountOfDataToCopy );

For instance, from your code, it appears that you expect arg2 to point to memory that will not change by the time you use whatever it is that arg2 points to. That is, are you certain that the string pointed to by arg2 (in your example) will still exist when you attempt to retrieve/interpret the string later?

// this is okay
char *myStr = "Here's a log message."; // static string
MyFunction( true, myStr );

// however
char *myStr2 = new char[256]; // dynamic string
strcpy( myStr2, ..someOtherString.. );
MyFunction( true, myStr2 );
delete[] myStr2; // now you're in trouble
// if you later attempt to read from the myStr2 pointer you wrote to the log,
// you'll probably get an error or access violation

An alternative would be to read the string itself into your log file. I.e., use strlen(arg2), strcpy( yourlog, arg2 ), etc., rather than relying on the memory pointed to by arg2 to exist for the life of the app. Yeah, strlen and strcpy are deprecated, but I think you get the idea.

You are indeed correct. For now I'm not really interested in the contents of the pointers, I'm just going to print the value out. I realize this is not really useful info to have, but I can't very well leave out arguments if I'm logging the function calls. Later on I will indeed copy any info that is passed as a pointer. Likely I'll use a scratch heap for that as well, similar to how I plan to use scratch heaps to store the arguments on.