Archive: 6 posts

---

To create the perfect stopwatch that calculates the time that has passed between moment A and B, you want to use the NOT gate as a timer. What you want to do is wire the output of the NOT gate into the input of the same gate. The gate should now be pulsing at a very fast rate. The thing is, we actually know what this rate is. It pulses at a frequency of 15Hz. This is I believe because LBP2 simulates the environment at a pace of 30Hz (in other words the logic runs at the same speed as the framerate, which is 30fps). Since the NOT gate has to turn off before it can turn on again, it requires two frames for each pulse. This leads to the 15Hz frequency mentioned above. Anyways, the reason you need to use a NOT gate instead of a timer is because a timer has a dead frame when it resets, so a 0.1s timer that resets itself actually pulses at 0.1s + one frame, or 0.133s. So you either have to account for this, use some other system or run a faulty timer that runs 25% slower than real time. The way I've gone around this is by setting up a selector and NOT gate based stopwatch. As we determined before, the NOT gate runs at 15Hz. In terms of time, this means that pulses come every 0.066 seconds. Assuming we start up the system at 0.0s, that means that after one pulse cycle we're at 0.066s, 0.133s after the second and at 0.200s after the third. So we make a three way selector that cycles through all options every 0.2s by wiring the NOT gate into the increment input of the selector. Once the three way selector has been created, wire the OUTPUT1 of the selector onto two 5-way-selectors. These account for tenths of seconds. The other one handles even numbers: 0.0;0.2;0.4;0.6 and 0.8. The other one handles 0.1;0.3;0.5;0.7 and 0.9. Whenever the 3-way selector is at OUTPUT3, the odd number display should be active (0.133s compared to 0.066s or 0.2s, remember?), at OUTPUT1 and OUTPUT2 the even number display needs to be active. You can do this by activating separate microchips based on the 3-way-selector's output. Then wire the OUTPUT1 of the even number five-way-selector into another selector's increment input. This selector should have 10 outputs; it accounts for single seconds. Now wire *again* the topmost ouptut of this new selector into another selector. This latest selector should have 6 outputs (for numbers 0 to 5) as it accounts for ten seconds. If you want to count minutes too, repeat the same thing: 10-way-selector for single minutes, 6-way-selector for tens of minutes. You can even continue to account for hours, but that's probably overkill. If you do this, you now have the most accurate timer possible in LBP2. If you run two NOT gates you can get signals to pulse at 30Hz, but unfortunately the game considers signals pulsing at that speed constantly on, so selectors won't react to that setup. The sweetest thing about this setup is that it is extremely simple to stop the watch whenever you want. All you need to do is put the inital NOT gate into a separate microchip, and whenever you want to stop the clock, disable that microchip. You have just successfully paused the clock. Finally, all you need to do is wire each output of each selector into the corresponding number displayer, be it holograms or whatever you want. To summarize the first three selectors, here's what the outputs need to display: Selector 1 (3-way) outputs: 0 6 3 Selector 2 (5-way, even tenths of a second) outputs: 0 2 4 6 8 Selector 3 (5-way, odd thenths) outputs: 1 3 5 7 9 All subsequent selectors: 0-9 or 0-5 I've tested this setup and it runs perfectly accurate for ten minutes. If there is slowdown in the framerate when you play, the clock slows down as well. This is a good thing, because it means that if the game starts to slow down you won't get penalized by the timer. So no matter how many or few explosions occur around you, you will always be able to run the same distance with a sackboy in the exact same time according to the game even if the game starts to drop in framerates. I hope my description was clear enough. I could put up a level that has my own stopwatch as a collectable prize if you want. In the meantime you can check out the stopwatch in action in my Time Attack level: http://lbp.me/v/zdm5gv NOTE: Just so that it is clear to everyone, even though this system displays hundreths of seconds, the only discrete times displayed in between seconds are: 0.00 -- 0.06 -- 0.13 -- 0.20 -- 0.26 -- 0.33 -- 0.40 -- 0.46 -- 0.53 -- 0.60 -- 0.66 -- 0.73 -- 0.80 -- 0.86 -- 0.93 -- 1.00 And I have not been able to figure out how to display the frames in between these times. There might be a way to pull it off and display every single 0.033s, but I tried and failed. Whatever the case, whatever number you see by this setup, it is accurate to the 0.066s and doesn't lie.

2011-03-29 00:01:00 Author: Linque Posts: 607

---

If you do this, you now have the most accurate timer possible in LBP2. If I'm reading this correctly, then your granularity is only 0.066s, which is not the most accurate timer possible in LBP2. Granularity of 0.033s is the theoretical limit and totally possible. I'd suggest replacing the not gate in a microchip with an XOR looped into itself for starters (because you will lose the extra granularity by forcing the NOT down to zero when you stop the system). You'll then need to modify the first stage of the counter to combine the output state of the selector with the output state of the XOR. This gets a little confusing due to the latency because you are using the bottom input of the selector, but off the top of my head ANDing each input with the XOR output should give you 0.000, 0.067, 0.133 and ANDing each output of the selector with the inverse of the XOR should give you 0.033, 0.099, 0.167. You'll need to configure your starting condition to have the XOR with a positive output to make it work as well I think. But yeah, doubling the granularity is not that complex to achieve in logic. In words... bit more tricky

2011-03-29 00:23:00 Author: rtm223 Posts: 6497

---

Don't know if you noticed but I edited the post to add a note to the end about the accuracy. I tried to get the 0.033s granularity to work, but the problem is that the tenths of seconds are not able to keep up. You're not able to switch between the odd and even number tenths of seconds at the same time as you're supposed to move from 0.066s to 0.100s, so the display won't show the correct number. Don't know my description above makes sense to you, I hope it does. I tried to get it right for a long time and couldn't get it working for the life of me. There *might* be some solution that is much much more complex than my setup (lots of logic gates instead of microchips), but I don't feel the added one frame accuracy is worth it. Also, my apologies for advertising this system as the most accurate timer possible. I should've said that it's the most accurate timer I was able to create despite great efforts to get it even more accurate. EDIT: After reading your post again, I think I'll give it one more shot myself with your suggestions and see if I can get it to work this time. On paper it does seem like it's totally feasible and I thought I had it all figured out myself as well, but for some reason it didn't work out. Feel free to try it out yourself too if you want. If you're able to pull it off and I'm not, I would very much like to borrow your timer for my levels.

2011-03-29 00:32:00 Author: Linque Posts: 607

---

What happens when the framerate drops? Is physics still calculated at 30fps?

2011-03-29 01:14:00 Author: thor Posts: 388

---

If the framerate drops, so does the physics/logic simulation rate. They're tied together.

2011-03-29 05:24:00 Author: Linque Posts: 607

---

Granularity of 0.033s is the theoretical limit and totally possible... Sure is. I had to build a frame-accurate 'stopwatch' to produce the results in this post (https://lbpcentral.lbp-hub.com/index.php?t=47951-Guide-to-Speed-Rotation-and-length-units-in-LBP2-UPDATED-SOME-NEW-INFO&p=765993&viewfull=1#post765993).

2011-03-30 15:17:00 Author: Aya042 Posts: 2870

Posts: 1077139    Threads: 69970    Members: 9661    Archive-Date: 2019-01-19

Aus dem Archiv wurden alle persönlichen Daten wie Name, Anschrift, Email etc. - aber auch sämtliche Inhalte wie z.B. persönliche Nachrichten - entfernt.
Die Nutzung dieser Webseite erfolgt ohne Speicherung personenbezogener Daten. Es werden keinerlei Cookies, Logs, 3rd-Party-Plugins etc. verwendet.