Thanks again for all the comments yesterday. Louise was less impressed than I expected but then I think she thinks we're all weird.

The hospital have kindly agreed for me to plug my laptop in at the ward as long as the wireless is off, even though it isn't PAT tested. They have been really good about everything really.

So the plus side of living in a hospital during the day is that I can get loads of work done on Squed.

Today I got copy-paste for the Actors sorted. Actors are map shapes and decals at the moment with game objects being added later but I decided to treat them all as the same in the editor which has worked out okay.

As I was using my binary_ifstream and binary_ofstream to serialize the Actors to and from the files (basically just a binary mode std::stream with << and >> overloaded for binary read/write), I was able to save quite a lot of hassle and create a binary_istream and binary_ostream base that binary_ifstream and binary_ofstream derive from. I then created a binary_istringstream and binary_ostringstream that use std::stringstreams internally.

As a result, I could quite easily serialize Actors to memory buffers instead of files using the existing methods.

So it becomes a case of serializing selected Actors to a binary_ostringstream, copying its contents into a GlobalAlloc'ed buffer and putting this on the clipboard as user-defined data. I can then retrieve this buffer on paste, copy it into a binary_istringstream then de-serialize its contents back into the level. It means I only have to update the Write(binary_ostream&) and the constructor for each Actor sub-class that takes a binary_istream and the copy-paste system and file loading/saving systems are sorted automatically.

I then discovered that marquee-selecting from a large group of Actors was taking a lot of time (seriously, two to three seconds from release of mouse to process) so spent the last few hours profiling the code. As I suspected, but am trained by GameDev to confirm with tests, it is my SAT code that is the bottleneck.

I'm currently pondering how significant it would be to add an AABB class of shape to the SAT library (at the moment these are represented by polygons) as the selection rectangle is always an AABB. Seems like I'd still have to do projections onto all of the perpendicular axes to the Actor bounding polygon and early-out is not really the solution as the slow-down occurs when selecting large groups of Actors. For this reason, spatial system for pruning intersection tests is not really going to be helpful either for the editor.

Current optimisation is to first check for an intersection with the Actor's bounding AABB (which is generated each time the Actor orientation or size is changed), early-out with a negative if not, then check if the Actor's bounding AABB is completely contained within the selection AABB, early-out with a positive if so. These are both pretty trivial tests so saves a great deal of SATs.

Unfortunately the high number of SATs still required around the edges of the selection AABB still seem to be causing a few seconds delay on my laptop (possibly not on the desktop, I don't really know at this stage) so I'd like to improve that performance.

I'm sure there must be a more efficient way to check for an intersection between an AABB and an arbitrary polygon than a polygon to polygon check. Brain threads are a little limited at the moment with Louise's health running on one core and work stress (absurdly high at the moment) on another but hopefully somewhere in there I can schedule some thoughts about this.

Obviously I could avoid half the projections, including generating the normalized axes, for a polygon vs AABB test and just take the x and y coords of the polygon's vertices directly for those tests. But I'm not convinced that that would have more than a maximum 50% speed up, so going from two to one second delay is not really worth pursuing.

I'm wondering right now if it is possible that I could early out somehow if the line formed by the edge of the selection AABB intersects the polygon, and if that could be computed any quicker. Don't really know at the moment.

For the majority of positive-intersection cases, one or more vertices of the Actor will lie within the selection AABB. It is also possible that, since testing a point against an AABB is also trivial and requires no projections, it may be faster to first check to see if each vertex of the Actor polygon is within the selection AABB and early out positive if so.

That last paragraph is probably the answer. I can think of very few corner cases where that would not be the case, and (this is stream of conciousness) for half of those there would be the opposite optimisation of the Actor polygon containing one of the vertices of the selection AABB.

So, as a plan, check for an AABB vs AABB intersection, false out if not. Then check for a completely contained Actor AABB within selection AABB and positive out if so. Then check each vertex of Actor polygon against selection AABB and positive out if found, then check selection AABB vertices against Actor polygon (more expensive but still cheaper than full poly-poly test) and positive out if so. Finally give up and do full SAT treating selection AABB as polygon.

Might work. Probably best to review tomorrow after sleep.

Like most of us (I think) all of this stuff is a good way of coping with (avoiding thinking about) RL issues. [random bearded bloke] bless Louise and all of the fantastic nursing staff at our local hospital.

Night. x