@drakide (View Post)

Particles are stored in a huge list, but there is also a particle map - a matrix which contains information about which particle (if any) is in each position. This matrix stores the particle's type and list index.To check which particle is in a particular position, one element of this matrix is accessed.

Here is a fictional example of the complete source code for a neighbour interaction (excluding variable declarations). It accesses 8 elements in the particle map (pmap), corresponding to the 8 neighbouring positions around position (x,y). At no point does it traverse the entire list of particles (parts).

    for (ry=-1; ry<2; ry++)
        for (rx=-1; rx<2; rx++)
            if (x+rx>=0 && y+ry>=0 && x+rx<XRES && y+ry<YRES && (rx || ry))
            {
                r = pmap[y+ry][x+rx]; // Access one element of the particle map, which contains information about the particle at position (x+rx, y+ry), if any
                if (!r) // If zero, there is no particle in this position
                    continue;
                if ((r&0xFF)==PT_BRAY) // Check the type of the neighbouring particle
                {

                    // Do stuff with this particle, using the list index from the particle map

                    // For example, set the life of the neighbouring particle to 4
                    parts[r>>8].life = 4;
                }
            }

TPT can't store all the particle data in a matrix, because TPT allows multiple particles to be in the same place (e.g. photons). With a matrix, there is only room for one particle in each position.

All particles have 56 bytes in which to store particle properties. PIPE squeezes most of the properties of the absorbed particle into properties that it doesn't use, but this is imperfect - only one particle can be absorbed, and some of the properties are lost. So yeah, doing it that way wouldn't really be practical.

At the moment, the particle map doesn't handle multiple particles in the same location (or at least, it doesn't handle them well). It can only store information about one particle in each position.

This does cause a few problems. Some of these problems can be mitigated with various tricks, but this isn't entirely satisfactory and a map of lists is something that I'd like to test out at some point. There are actually two particle maps - one for particles that can block movement of other particles and don't usually overlap, and one for energy particles like photons and neutrons that overlap frequently and don't affect movement. Both maps are recalculated each frame, just before all the physics and particle interactions happen. Access to the first particle map is prioritised so that, for example, INVS does not overwrite an entry for another particle in the same position, meaning that collisions work correctly inside INVS. 

The difference between a particle map and storing all the data in a matrix: The particle map stores 4 bytes of data for each location. 1 byte is for the particle type (DUST/WATR/etc), and the other 3 for the index in the parts array. The 56 bytes of particle properties (particle type, position, velocity, etc) are stored in the parts array, instead of directly in the particle map.