Page 14 of 20

Posted: Fri Jul 16, 2010 9:00 pm
by Saxxon
It may also have to do with how timing in ZZT is staggered. This was done so that all things of the same cycle don't have to be processed at the same time which helped to alleviate the pressure on the processor on older machines.

You increase a base timer value by 1 every tick. I think the formula for determining whether or not a stat element will be processed is this:

(ObjectNumber + MainTickValue) % Cycle

If 0, the object will be processed. Due to the staggered setup, sometimes object procs will be skipped completely or done more rapidly depending on how MainTickValue changes. I think it is still modified in ZZT regardless if the game is paused, it might be on an interrupt timer.

Posted: Sat Jul 17, 2010 12:21 am
by Dr. Dos
The results I've gotten though were with nothing on the board with stats other than the player, a single duplicator, and an object for a timer. Only one duplicator on screen at a time.

Posted: Sun Jul 18, 2010 11:30 am
by Saxxon
Dr. Dos wrote:The results I've gotten though were with nothing on the board with stats other than the player, a single duplicator, and an object for a timer. Only one duplicator on screen at a time.
Are you getting the results you expect?

Posted: Sun Jul 18, 2010 11:52 pm
by Dr. Dos
I would expect consistency. At first I figured cycle 1 was going to end up with 15 cycles * rate + 1 which works well for the first half of possible rates, but then you get the 86, 91, 98, 113 pattern at the end.

Posted: Mon Jul 19, 2010 2:31 am
by premchai21
Dr. Dos wrote:I would expect consistency.
That may turn out to be an uncatchable hobgoblin, to thoroughly mangle a saying.

With a duplicator {cycle 1, step [−1 0](west), params [0 8(fastest) 0]} and a timer object {cycle 1, params [35(#) 0 0]} with the code

Code: Select all

/i#give score 1
#if blocked w #end
#restart
in the horizontal arrangement [boulder duplicator empty timer] with the player two spaces below the duplicator and the stat record order [player duplicator timer], I get a final score counter of 13, 14, or 15 on different runs, with no pattern that I've detected. (For instance, it doesn't seem to depend on the direction the player steps to do the initial unpause, or on the game speed.)

On the plus side, this may mean you have considerable leeway as a result! Wahahahaha!

(Appended by edit:) I forgot to mention the configuration, though it probably doesn't matter: this is running ZZT 3.2 on a fairly stock DOSBox 0.74 on Debian GNU/Linux AMD64 unstable (sid), CPU Athlon 64 X2 4200+, kernel Linux 2.6.32-5-amd64 (Debian version), world file generated with a slightly patched KevEdit 0.5.1.

Posted: Mon Jul 19, 2010 2:38 am
by Commodore
I can't think of anything that would be broken if the times were approximated. No one really uses the precise timing of duplicators in any programming trickery that i've seen

Posted: Mon Jul 19, 2010 2:50 am
by Kjorteo
Honestly, I would have said "no one uses ____" for most of the more obscure and archaic oddities, but lately I've learned not to put anything past premchai.

Posted: Mon Jul 19, 2010 7:28 am
by Dr. Dos
premchai21 wrote:
Dr. Dos wrote:I would expect consistency.
That may turn out to be an uncatchable hobgoblin, to thoroughly mangle a saying.

With a duplicator {cycle 1, step [−1 0](west), params [0 8(fastest) 0]} and a timer object {cycle 1, params [35(#) 0 0]} with the code

Code: Select all

/i#give score 1
#if blocked w #end
#restart
in the horizontal arrangement [boulder duplicator empty timer] with the player two spaces below the duplicator and the stat record order [player duplicator timer], I get a final score counter of 13, 14, or 15 on different runs, with no pattern that I've detected. (For instance, it doesn't seem to depend on the direction the player steps to do the initial unpause, or on the game speed.)
I was never moving in my tests, but upon running around in different ways did get differing results similar to yours.

Sweeney :drussrox:

Posted: Tue Jul 20, 2010 7:33 am
by Saxxon
Saxxon wrote:It may also have to do with how timing in ZZT is staggered. This was done so that all things of the same cycle don't have to be processed at the same time which helped to alleviate the pressure on the processor on older machines.

You increase a base timer value by 1 every tick. I think the formula for determining whether or not a stat element will be processed is this:

(ObjectNumber + MainTickValue) % Cycle

If 0, the object will be processed. Due to the staggered setup, sometimes object procs will be skipped completely or done more rapidly depending on how MainTickValue changes. I think it is still modified in ZZT regardless if the game is paused, it might be on an interrupt timer.
Going to quote the earlier post and say that timing will never be consistent between runs of the game world because of this. An object's process tick depends solely on three things: its Cycle, the Main Timer, and the Object Number.

Posted: Tue Jul 20, 2010 11:50 am
by premchai21
Saxxon (edited for concision) wrote:
Saxxon wrote:(ObjectNumber + MainTickValue) % Cycle
Going to quote the earlier post and say that timing will never be consistent between runs of the game world because of this. An object's process tick depends solely on three things: its Cycle, the Main Timer, and the Object Number.
Possibly. The empirical test makes a stronger unpredictability statement for duplicators specifically, given that the test case has all entities at cycle 1 from the beginning, which should mean "every tick" if the formula you provide is correct—unless you're implying that duplicators have a separate virtual cycle value of some sort.

Posted: Tue Jul 20, 2010 10:43 pm
by Kjorteo
Or that the object number is significant. Perhaps try to run the test again after having dumped a bunch of other objects on the board and then the duplicators, with and without erasing the other objects again first?

Posted: Wed Jul 21, 2010 2:13 am
by premchai21
Kjorteo wrote:Or that the object number is significant. Perhaps try to run the test again after having dumped a bunch of other objects on the board and then the duplicators, with and without erasing the other objects again first?
I would tend to think that the object index is significant, but also that the duplicator's virtual cycle modulus is not strictly equal to its original stat cycle. It may not be dependent on it directly either; the stat cycle seems to only create an initial delay. Either of these may be what Saxxon meant earlier. See test world 0201-01. Particularly see board #2, where sometimes the duplicator's total ticks to duplication (as measured by the timer object) is reduced by 5 or so and sometimes it is delayed until the entire chain of death objects above disappears, suggesting a linear (over time) offset being applied within a virtual period of 3 ticks. Maybe. Sort of.

Posted: Wed Jul 21, 2010 5:29 pm
by Saxxon
premchai21 wrote:
Saxxon (edited for concision) wrote:
Saxxon wrote:(ObjectNumber + MainTickValue) % Cycle
Going to quote the earlier post and say that timing will never be consistent between runs of the game world because of this. An object's process tick depends solely on three things: its Cycle, the Main Timer, and the Object Number.
Possibly. The empirical test makes a stronger unpredictability statement for duplicators specifically, given that the test case has all entities at cycle 1 from the beginning, which should mean "every tick" if the formula you provide is correct—unless you're implying that duplicators have a separate virtual cycle value of some sort.
Your post encouraged me to do some more testing with duplicators.

These were the steps I took:

1. Go into ZZT's editor and place a line of duplicators across the title board from left to right, setting the speed to the slowest. This gives us cycle 27.

A slow cycle makes it easier to see what's actually happening. When an editor places a duplicator, it does so using a cycle that is a multiple of 3. The formula is: Cycle = (9 - P2) * 3. The game seems to automatically set a Cycle based on this formula when loading.

2. Create another line of duplicators, this time from right to left. Save the world.

Saving the world makes it easier to reset everything.

3. Exit the editor and observe the title screen.

Notice the duplicators animate in the order you placed them. This shows that object index has a direct relation with when an object is processed. They don't animate all at once, but since they are cycle 27 every single object with a matching cycle will have been processed after each 27 ticks.

4. Enter the editor, wait a second, then exit the editor.

Some of the duplicators miss their process frame because the main timer ticked while the game was in editor mode - either that or the main timer just resets to 0. Whichever the case, there is definitely a main timer influencing the processing.

5. Reload the world. Wait.

It'll take a minute or two but some of the duplicators will actually miss their processing tick. This is because the main timer rolls over. I'm not sure what the limit value is. Additionally, the first duplicators that animate are different each time.

-

This makes timing relationships among objects unreliable unless they are Cycle 1 which would force them to be processed every tick (even things of cycle 2 could get staggered by 1 tick.)

Posted: Wed Jul 21, 2010 6:25 pm
by premchai21
Saxxon wrote:A slow cycle makes it easier to see what's actually happening. When an editor places a duplicator, it does so using a cycle that is a multiple of 3.
Not quite:
Saxxon wrote:The game seems to automatically set a Cycle based on this formula when loading.
This is almost right. A duplicator's cycle is actually reset each time it is updated, AFAICT. One can observe this by forcing an initial cycle of 200 for a duplicator; its initial processing is delayed for a long time, but afterwards it operates according to its speed value. This is observable in saved games; the duplicator's stat record cycle value is overwritten with 3(9−P2).

The rest of what you said seems consistent with my previous experience, though I haven't bothered to directly reproduce it first-claw.

Posted: Wed Jul 21, 2010 6:49 pm
by Saxxon
premchai21 wrote:
Saxxon wrote:A slow cycle makes it easier to see what's actually happening. When an editor places a duplicator, it does so using a cycle that is a multiple of 3.
Not quite:
Saxxon wrote:The game seems to automatically set a Cycle based on this formula when loading.
This is almost right. A duplicator's cycle is actually reset each time it is updated, AFAICT. One can observe this by forcing an initial cycle of 200 for a duplicator; its initial processing is delayed for a long time, but afterwards it operates according to its speed value. This is observable in saved games; the duplicator's stat record cycle value is overwritten with 3(9−P2).

The rest of what you said seems consistent with my previous experience, though I haven't bothered to directly reproduce it first-claw.
You are right, I just tried playing around with the settings. It does reset on update. Also, it seems the editor uses an initial cycle of 2 - not sure of the significance of that, just found it interesting.