Bullet Bob and Bullet Bill SLOW TIME

[Dr. Dos]

I got bored and slowed down ZZT. First with Bob.

@bob
#cycle 1
:stop
#end
:touch
#bob:touch
#touch

It takes about 13 Bobs to get results. At 15 the lag makes a noticable difference. At 20 it gets annoying. And for the hell of it, at 90 Bobs it takes 2 seconds for a bullet to placed on the screen and 7 seconds for the bullet to move a single space.

I made Bob's slowmotion something you could toggle with this:

#cycle 1
:loop
#if slowmo x
#loop
:x
#bob:touch
:y
#if not slowmo z
#y
#end
:z
#bob:stop
#loop

Then I tried out Bill. Bill is much more effective object # wise to get result, but he rapes a counter to get his results.

@bill
#cycle 1
#end
:touch
#give score 32767
#take score 32767
#bill:touch

With 3 bills there's a slight lag like 13 or 15 Bobs. 5 Doesn't seem to make a difference either. 10 Bills seems like 20 Bobs. Then for the hell of it I filled the rest of my screen and tried 132 Bills. 6 seconds for a bullet to move 1 space. Granted this was a bullet already in motion and timed with the system clock.

http://zzt.org/Dr_Dos/billbob.brd

I don't know what use this can be, it slows everything down. Bullet Time I guess but the controls lag just as much so you can't really get an advantage.

I also remember doing this awhile ago changing empties to solid. This had a side effect of a seizure and death. It also made the board unwalkable half the time.

[Swashbuckler]

How many Bob's does it take to crash ZZT?

[Quantum P.]

This is no big news to somebody with hand-me-down computers. Back when I was using a 486, the shimmering torches in the hallways of Warlock Domain would give me a bit of lag. So did the starting board that all the MIG games have.

On the other side of things, if you are trying to prevent lag in a complex program, make sure that you use /i's in your loops. For example, if you want to have an object check the player's health, instead of doing this...

Code: Select all

#cycle 1
:loop
#take health 1 agh
#give health 1
#loop
:agh
Oh dear, looks like you died.
Game over.

You would do this...

Code: Select all

#cycle 1
:loop
#take health 1 agh
#give health 1
/i#loop
:agh
Oh dear, looks like you died.
Game over.

If you check the player's health once, you don't need to check it again that cycle, as it couldn't have changed. Instead, use /i to wait until next cycle; there's no sense in wasting execution time in an infinite loop until ZZT gives time to another object. It's a rather small optimization, but the savings can pile up if you've got an engine with a ridiculous number of loops.

[Commodore]

I managed to do something like that, using ZZT on the fastest setting the bullets and movement of things is absurdly quick, but by having a single object on the board that constantly writes a blank message at the bottom of the screen, it's slowed down just enough to be awesome.

[Ryan Ferneau]

This topic opens the possibility of a Nevada Bill.