ntrf

Each entity in source engine has two hitboxes - one in quake physics world, and another in havok (or vphys) physics world. This second hitbox is called "physics shadow".

Depending on type of the entity one of the hitboxes is dominant. Each frame results of havok physics simulation for barrels, rollermines, vehicles and etc will be copied over quake hitboxes of entities. For NPCs, rockets and elevators state is copied in reverse direction - quake to havok.

Player is special. Normally quake hitbox will overwrite havok shadow, but only if its movement is not blocked by any havok hitboxes. Player's hitbox will be copied in reverse - from havok to quake - if (a) havok hitbox is valid (not stuck in quake world), (b) player is touching a vphys object.

Quickclip works, because in vehicles havok hitbox has collisions masked out for everything except pickups (health, ammo). When you exit a vehicle, collision mask for havok physics should be changed to normal, but only if vehicle is present in the world. Barnacle fo

andy-williams

// Problem:
// We have lots of data that we want to process that can be easily parallelised
// We want to process all our data and combine the results
// "Map is an idiom in parallel computing where a simple operation is applied to all elements of a 
// sequence, potentially in parallel.[1] It is used to solve embarrassingly parallel problems: those 
// problems that can be decomposed into independent subtasks, requiring no 
// communication/synchronization between the subtasks except a join or barrier at the end."
// - https://en.wikipedia.org/wiki/Map_(parallel_pattern)

void Main()

chanks

Turning PostgreSQL into a queue serving 10,000 jobs per second

RDBMS-based job queues have been criticized recently for being unable to handle heavy loads. And they deserve it, to some extent, because the queries used to safely lock a job have been pretty hairy. SELECT FOR UPDATE followed by an UPDATE works fine at first, but then you add more workers, and each is trying to SELECT FOR UPDATE the same row (and maybe throwing NOWAIT in there, then catching the errors and retrying), and things slow down.

On top of that, they have to actually update the row to mark it as locked, so the rest of your workers are sitting there waiting while one of them propagates its lock to disk (and the disks of however many servers you're replicating to). QueueClassic got some mileage out of the novel idea of randomly picking a row near the front of the queue to lock, but I can't still seem to get more than an an extra few hundred jobs per second out of it under heavy load.

So, many developers have started going straight t