ID:138736
 
Code:
mob
verb
test()
set src in view()

var/image/i = image('color.dmi', locate(1,1,1), "pink")
var/counter = 25
var/flip = 1
src.client.images += i
i.icon += rgb(0,0,0,155)
spawn while(src)
if(flip) i.icon += rgb(10,0,0)
else i.icon -= rgb(10,0,0)
sleep(0.1)
counter --
if(counter <= 0)
counter = 25
if(flip) flip = 0
else flip = 1
sleep(1)


Problem description:

Yes, I realize this isn't good code etiquette or even objectively useful but for the sake of understanding, please answer specifically the question I am asking.
You have an infinite loop that gives you only a 1/10 second delay...

sleep() and other time related functions are in the scale of 1/10 of a second (a tick), NOT in seconds (1 sec = 10 ticks, 1 min = 600 ticks)... well, assuming that world.tick_lag (or whatever is called) was not modified.
In response to GhostAnime (#1)
Its for a graphical effect that requires blending colors over time... I was under the impression spawn sent it to another thread?
In response to FIREking (#2)
Dreamseeker is a single-threaded application so unfortunately that's not the case. I'm not quite sure how they implemented spawn in a single thread but I suppose there's an internal scheduler and spawn just schedules something for execution.

Also, like GhostAnime said, sleep(0.1) is a bad idea. Because Dreamseeker works on ticks your spawned loop doesn't even sleep for a single tick! So it's akin to a loop with 0 sleeps.
In response to BrickSquadron (#3)
I am not sure how you can avoid using sleep(0.1) and expect to do any real-time computed animations... If i want some text to glow between red and dark red (in-theory we arrived at these colors because of values so there's no way we could have resources for it prior), and my world is operating at 30 FPS, i will need to use small increments of sleep (sleep(0.1)) in order to accomplish any sort of graphical changes over time. Correct?
In response to FIREking (#4)
The smallest amount of time you can sleep is world.tick_lag.
sleep(world.tick_lag)
In response to BrickSquadron (#3)
spawn() works in a singlethreaded environment because only one piece of code is running at any given time. Try running this code:

mob/verb/test_spawn()
for(var/i = 0, i < 10, ++i) spawn(20) world << i


Every time I run it it outputs in a predictable order.

Or try this:

var/some_global

mob/verb/test_spawn()
for(var/i = 0, i < 10, ++i)
spawn(20)
some_global = i
world << "[some_global], [i]"

world << "Done spawning"


No interleaving.

But trying this:

var/some_global

mob/verb/test_spawn()
for(var/i = 0, i < 10, ++i)
spawn(20)
some_global = i
sleep(1)
world << "[some_global], [i]"

world << "Done spawning"


produces output that's predictable, but different - the executions are interleaved.

Essentially, there's one proc executing at any given time, but there's a list of to-execute procedures that's (possibly) flipped between every time a proc hits a sync point. sleep() is a sync point. set background = 1 inserts a sync point in a proc every so often. Calling spawn() is a sync point (for the parent - try replacing sleep(1) with spawn() in the above code).

The scheduler seems to be relatively predictable, considering how consistent the results are, but I'm not sure if that's useful to know.

Disclaimer: This is probably wrong in some substantive fashion. It might even be totally made up. Likely not a complete description - in particular, almost certainly more operations are 'sync points'. Uses nonstandard terminology. Part of a normal diet. If symptoms persist, see your doctor.