In response to A Pack of Retards
A Pack of Retards wrote:
Wouldn't this be better than recursively calling update_loop?

No, because it never returns. Its just not good design in my opinion (I'm not an expert or a pro, though). I prefer a proc that exits the call stack each iteration when dealing with loops.
It is probably actually better to have it iterative instead of recursive. The reasoning here is, calling the new version of the procedure does carry some (very small, mind you) overhead. sleeping the current stack however wouldn't have that overhead.

Both sleep() and spawn() need to schedule a stack, it's just with sleep() you're scheduling a pre-existing one, and your spawn() use must create one (and tear the old one down, when finishing).

If you do want to stick with the spawn approach, though, it may be better to use something like an event scheduler, to bunch up the scheduler use in the case of large numbers of pixel projectiles. Being biased, I recommend http://www.byond.com/developer/Stephen001/EventScheduling

If there's performance issues with it, I'm happy to work with you on that.
In response to FIREking
You should probably design your update_loop() to use an iterative approach rather than a recursive approach, as in most situations the former is faster than the latter; this may however be an exception if memoization is applied to the latter. By its very nature, recursive procedures use more memory than iterative procedures and also fills up the stack quicker, which results in a slower procedure, and even offsets(not returning what you expected) numbers sometimes.
Due to the spawn(), it's not actually recursive in the classic sense. The stack won't grow, as the calls are decoupled. What you do suffer from though, is create/delete of stack frames.
So I actually just tested spawn() vs while() and it turns out the spawn() is about 5-10 world.cpu faster
Is this in the case of say ... 1000 of these procedures running in parallel?
In response to Stephen001
Yeah, about 800 of them simultaneously.
Interesting. I wonder why?
In response to Stephen001
I tried while(loc) should I try while(1)

Not sure if loc evaluating to true is slower than 1? Probably not...
You do have a variable access and null check there, so ... it might make some difference.
There's not going to be a way to exit the while() loop without a variable check... because I'm using garbage collection for speed.
I want to say using src would work for the sleep() scenario if it works for the spawn() one.
In response to Stephen001
The spawn version is checking for valid loc and bailing if its null every iteration...

The problem is, if I remove that check and put while(loc), it apparently isn't the same amount of computational pull (it weighs more, in that regard).

Edit: Results of test

cpu is the cpu usage at the time of the snapshot
cpu average is the total average of the cpu at run time
projectiles is the number of projectiles alive at time of snapshot
projectiles fired is the total number of projectiles fired during world life
bots is number of bots firing projectiles

spawn method
============
cpu 40
cpu average 32.2404
projectiles 835
projectiles_fired 20167
bots 256

while method
============
cpu 46
cpu average 39.1399
projectiles 819
projectiles_fired 20330
bots 256

________________________

spawn method
============
cpu 39
cpu average 38.9574
projectiles 815
projectiles_fired 100723
bots 256

while method
============
cpu 46
cpu average 44.7125
projectiles 799
projectiles_fire 100781
bots 256
I should probably post updated loop that I'm using

Here's spawn method:

    proc/update_loop()
//update position
if(!loc) return

px += vx
py += vy

if(!check_bounds()) del src

//update x, y, pixel_x, pixel_y to reflect new location
src.set_pos_px(src.px, src.py)

//did we enter a new tile?
if(last_x != x || last_y != y)
last_x = x
last_y = y

if(loc) loc:collide_here(src)

spawn(world.tick_lag) update_loop()


Here's while method:

    proc/update_loop()
//update position
while(loc)

px += vx
py += vy

if(!check_bounds()) del src

//update x, y, pixel_x, pixel_y to reflect new location
src.set_pos_px(src.px, src.py)

//did we enter a new tile?
if(last_x != x || last_y != y)
last_x = x
last_y = y

if(loc) loc:collide_here(src)

sleep(world.tick_lag)
Page: 1 2