So you're trying to use the object-oriented language to do something that isn't object-oriented, but still actually is object-oriented? You have a particle engine datum (object) that manages every projectile (data stored in a list) and sets the appearance of screen objects.

Or, you use an object.
It has its own data.
It has its own functions.
It was designed to work with the engine.

Instead of this:

 every tick:

 for every projectile:
     move projectile by its velocity

You want to do something like this:

 every tick:

 for every set of data in the list that represents projectiles:
     particle_data[relevant_projectile_data_set][position_x] += particle_data[relevant_projectile_data_set][velocity_x]
     particle_data[relevant_projectile_data_set][position_y] += particle_data[relevant_projectile_data_set][velocity_y]

     //  check collisions
     for every nearby atom
         if relevant projectile's position intersects the atom
             projectile hits atom and dies

 for every client
     for every screen cell
         if there is a projectile at this cell
             set appearance to particle_data[relevant_projectile_data_set][icon_state]
         else clear the cell

But the data you're manipulating does have locs, bounds, and other things that are required for bullets to physically function properly.

The built-in functions don't actually do anything by default. There's nothing wrong with that. There's no problem with the built-in way of doing things.

Why don't you make a shooter using pixel movement and see how laggy it is? Mine was made before native pixel movement and runs fairly well over good internet connections.

The only variables and functions required:

 density
 icon
 icon_state
 loc
 x
 y
 z
 bounds (the combination of x, y, width, and height)
 step_x
 step_y
 locs

 var vel_x, vel_y

The only variables that change during flight:

 loc
 locs
 x
 y
 z
 step_x
 step_y

The procs called that matter (only when collision detection is necessary):

 Move
 Enter
 Cross

No problems here. Variables and procedures that aren't used cause no lag issues.

Your way involves a bunch of objects (most of which aren't used) being managed by some datum you wrote yourself that handles all the physics.

The built-in way is managed by the BYOND engine. If you think you can beat the built-in framework, go ahead and do it. You're simply using the wrong engine and programming language to begin with, but good luck.

Most programmers today probably take no notice of the bitwise operators, but perhaps they can be very effective in BYOND.

Since bitwise operations require about the same processing power as multiplication

I'm sure many image editors and sprite engines have made direct use of the bitwise operations on the actual binary data of images.

Bitwise operators are also only performed on integers(or binary numbers), so they don't expand beyond that nature.