Aressera

• You shouldn't be allocating memory within a function like in LineInterHull, it's not necessary and slow. Just rearrange your test so that you merge both loops into one, and hence no need to cache the intersection data.
• Pass your vectors by const reference rather than by value.
• the line in MakePlane should be *d = -Dot( setnorm, point ). This is because the plane equation is defined as: a*x + b*y + c*z + d = 0, where (a,b,c) is the normal and d is the plane 'distance', so d = -(a*x + b*y + c*z)

you might be interested in some of the work being done on real-time sound propagation at UNC:

http://gamma.cs.unc.edu/GSOUND/ (my work)

http://gamma.cs.unc.edu/research/sound/ (other work)

I don't generally worry too much about it. The main thing is to make sure you're not doing a LOT of heap allocations at runtime, so reuse buffers/vectors, or use a pre-allocated memory pool and use your own allocator. The more allocations you do, the more memory fragmentation there will be, and thus can run into problems on embedded systems/consoles where virtual memory is not available.

You're not going to have many problems if you do a few dynamic allocations, the main issue is if you are doing many hundreds or thousands of allocations every frame.

One particular pattern that I've found helpful in reducing dynamic allocations is this:

template < typename T, size_t localCapacity >
class ShortList
{
	public:
		
		ShortList()
			:	storage( (T*)localStorage ),
				size( 0 ),
				capacity( localCapacity )
		{
		}
		
		~ShortList()
		{
			if ( storage != (T*)localStorage )
				free( storage );
		}
		
		void add( const T& newElement )
		{
			if ( size == capacity )
				reallocate( capacity*2 );
			
			new (storage + size) T( newElement );
			size++;
		}
		
		
	private:
		
		void reallocate( size_t newCapacity )
		{
			// replace current storage with dynamically allocated storage.
		}
		
		T* storage;
		size_t size;
		size_t capacity;
		
		UByte localStorage[localCapacity*sizeof(T)];
		
};

Basically you have a local storage buffer for a small fixed number of elements which can grow to be any size if necessary. This way, you get the best of both worlds: a statically allocated array, plus the ability to store any number of elements.

I mostly use Visual Studio and Codelite. Codelite's code-completetion is very powerful and there are some features that are hard to resist, but this IDE is not getting much recognition as it should be, it's also actively developed by a couple of developers. And some plugins are developed by communty, like Zoom Navigator in the screenshot. A sample screenshot of codelite and visual studio side-by-side. I just hope more people use codelite and contribute to this project.

 

http://i.imgur.com/pokfrMr.png

That Zoom Navigator looks pretty nifty.

With Xcode 3 (version 4 is sadly mostly single-window), I can have 2 or more full-height (50 lines) windows of code visible at once, even on my 15" notebook display.

 

Have you tried View->Hide Toolbar and View->Hide Tabbar in Xcode 4?

Then maybe "Use separate window" on double click navigation in general preferences to emulate the XCode 3 windowing behaviour.

I've tried that (in fact it is my current setting), the issue is that it doesn't remember window positions or sizes, causing me to have to manually resize the window each time I open one. I spent about a week messing with Xcode 4 trying to get it to my liking but was mostly disappointed, to the point where I re-installed Xcode 3 side-by-side so that I can use both. Other issues include not being able to compile a single file at a time (background compilation doesn't cut it). There are some good parts of Xcode 4 (I like project settings and integrated Interface Builder), but it seems like they tried to stuff as much functionality as possible within a single window interface without thinking about workflow or usability.