Archive: 28 posts

---

Hi all, I'm trying to re-create the arcade game Stacker (also known as Pile Up): - http://www.youtube.com/watch?v=gR8w-Ci4qd4 There have been a couple of versions of this made (example (http://lbp.me/v/t-3mcd)) but I'd like to have a go myself. I've started off by trying to replicate one row, with just one light moving back and forwards (see the Stacker vid from 22secs to see what it should lool like). I'm using two sets of hologram lights (one for forward and one for reverse). Each set is wired up to a selector. The selector is activated via the input at the bottom and the timing of the changes is made using a timer. The timer is linked to a counter so that when the leftmost and rightmost lights are activated, the counter fills up and this sets the other set of lights off. At the moment, I have the lights moving back and forward but the problem occurs when the light gets all the way to one end. As an an example, here is the state of the lights: - OXXXXXX (right to left set) (1) OXXXXXX (Left to right set) (2) Where O is the hologram currently lit and all the other lights are inactive. Of course in the actual level, the two sets of lights are overlaid to look like just one set. What I would like to happen next is that the light moves the the right straight away (see the Stacker vid above from 22secs for how it should work). However, what happens is that the light in set 1 resets back to the right (so it will be ready the next time): - XXXXXXO (right to left set) (1) OXXXXXX (Left to right set) (2) And then the left to right set starts activating. This means that there is a delay. Does anyone know how to get this to replicate what happens in the actual game?? osullivp

2011-05-09 18:07:00 Author: Unknown User

---

Personally I'd try to get the left and right movement done with a single selector and set of holograms, not two. If you apply a *negative* timer pulse to a selector (you can achieve this by plugging your timer output into the negative input of a direction combiner) the selector will count backwards, so you could detect when the light hits an edge and switch into the reverse movement direction.

2011-05-09 18:17:00 Author: Dr C Posts: 122

---

I would use sequencers for the lighting effect moving back and forth. You can set it up to go forward/backward using a toggle switch and a timer set to the same amount of time as the sequencer. Just put batteries on the sequencer connected to the lights. I have a similar effect on the title screen of one of my levels. Changing it to three lights would be pretty easy. Then you could use tags and tag sensors to activate the next set of 3, 2, or 1 light(s). You might need multiple sequencers connected to different tag sensors (each requiring a different number of lights/tags to be lit.) Let me know if you need more explanation.

2011-05-09 21:58:00 Author: shane_danger Posts: 283

---

Hi Dr C, Shane_danger, Thanks for your help. I've actually knocked up a couple of tests using both approaches. One thing I should have mentioned was that I need to have control over how fast the lights move (to increase difficulty). I can see how I can do that with the timer version. Is it possible to change the speed of a sequencer outside of design mode? The other thing I noticed (and this happened with my own attempt too) is that the direction change is sometimes a bit glitchy. On the timer version it swaps quicker one way than the other and it does the same on the sequencer version too. I wonder if it's something to do with the toggle switch. It's not a showstopping problem - more of a polish issue... Dr C - just want to check that I've understood your design correctly. Components are as follows:- 7x hologram lights 1x 7 way splitter each output wired to separate light 2x direction combiner 1x timer with output wired to reset (this pulses the splitter). Output also to input of direction combiner 1 1 x toggle (between the direction combiners (output is wired to other input of combiner 1) Top and bottom outputs are wired to combiner 2, the output of which is wired to input of toggle I think I could make this simpler perhaps? Osullivp

2011-05-09 23:19:00 Author: Unknown User

---

Well, in theory you can change the sequencer speed, but I would just have a separate set of sequencers for every row of lights. That would be the simpler way to do it. Each one could have the batteries in different positions or be set to a different time per bar. Don't forget you can put sequencers on sequencers to get more exact with your timings - but you still can't make things happen faster than .1 seconds. As for the timings being a little different forward and backward, you need to play with it to get it just right. It needs to stop roughly in the middle of the battery on either side, OR those batteries need to be half the size of the others. This is a little tricky to pull off.

2011-05-10 03:53:00 Author: shane_danger Posts: 283

---

This is how I pictured the selector circuit; it works glitch-free: 33904 However, judging by the fact that you're ultimately going to want to light 3 lights in each row, you might be better off using a sequencer like shane_danger said. You can alter its speed, just set its input to Speed Scale and apply an analogue signal to it. You can also get it to play backwards in this way if you need to by applying a negative signal. One side note worth mentioning is you can make things happen faster than 0.1 seconds. For example, connect the output of a NOT gate to its own input and you've got an oscillator that will pulse 15 times per second, or every 0.067 seconds.

2011-05-10 05:25:00 Author: Dr C Posts: 122

---

Haha! Funny you should mention Knight Rider, I was thinking about using that to explain what I was trying to achieve! Thanks for the circuit board - really useful. Makes everything clear. I'll try that and also will try the Speed Scale setting on the sequencer version. I saw that and wondered if that was what I needed. One way or the other, I think I am going to need a sequencer for the overall control of the game... Assuming I manage to get the basic functionality of the game to work (i.e. the different levels of lights) then I thought it could be really cool to see if anyone in the community wants to include their levels or objects as prize bubbles. Also, I'm looking forward to creating the mechanical stuff that dispenses the prizes. LBP was designed for just this kind of game! P.S. Dr C, I had a quick look at your Little Big Air Warfare level. Looks awesome and reminds me of a game we made (http://www.pocketgamer.co.uk/r/Mobile/Bluetooth+Biplanes/review.asp?c=1038)when I was working for a wireless game developer (in the pre-iOS days!). I think that game was originally inspired by an Amiga game or something...

2011-05-10 14:43:00 Author: Unknown User

---

However, judging by the fact that you're ultimately going to want to light 3 lights in each row, you might be better off using a sequencer like shane_danger said. You can alter its speed, just set its input to Speed Scale and apply an analogue signal to it. You can also get it to play backwards in this way if you need to by applying a negative signal. One way to get a very precise analog signal is to use circuit nodes. You set up two circuit nodes on a microchip with one feeding into another. Then, you enter a signal to circuit node 1 from your analog source. With that signal still on, you take the output from the second circuit node and plug it back into the first one, making a loop. This loop will maintain whatever analog signal you had put into it. This functions the same as a battery, but with a much finer scale. You can use an analog probe to fine tune your signal. One method I've used is using pistons, tags, and tag sensors with the piston set to forwards backwards and the analog stick as it's input. The tag sensor set to "closeness." If you turn the timing up pretty high, it will move very slowly. Then you can capture the output of the tag sensor. This allows you to move by 1/2% (or less) rather than a battery that can only be adjusted by 1%. One side note worth mentioning is you can make things happen faster than 0.1 seconds. For example, connect the output of a NOT gate to its own input and you've got an oscillator that will pulse 15 times per second, or every 0.067 seconds. I never thought to try this! And I should have been clearer in my post.. You can't set the sequencer to less than 0.1 seconds per bar. But you still have 3 slots within each bar, meaning you can move the lights in .0333 seconds in that method.

2011-05-10 14:55:00 Author: shane_danger Posts: 283

---

P.S. Dr C, I had a quick look at your Little Big Air Warfare level. Looks awesome and reminds me of a game we made (http://www.pocketgamer.co.uk/r/Mobile/Bluetooth+Biplanes/review.asp?c=1038)when I was working for a wireless game developer (in the pre-iOS days!). I think that game was originally inspired by an Amiga game or something... Thanks, Bluetooth Biplanes looks pretty cool as well. It's quite possible it was also based on Sopwith (http://en.wikipedia.org/wiki/Sopwith_(computer_game)), it spawned a bunch of offshoots and really was loads of fun to play. One way to get a very precise analog signal is to use circuit nodes. You set up two circuit nodes on a microchip with one feeding into another. Then, you enter a signal to circuit node 1 from your analog source. With that signal still on, you take the output from the second circuit node and plug it back into the first one, making a loop. This loop will maintain whatever analog signal you had put into it. That's interesting, I didn't know you could 'trap' signals like that. I'll keep that in mind if I ever need a signal resolution finer than 1%.

2011-05-10 18:02:00 Author: Dr C Posts: 122

---

dr c has a great method if you would change just a little 4 multiple lights you would have evrything the same except the selector ouptuts. say you wanted 4 lights active at once just put a 4 port OR gate and copy the logic 4 times. on the 1st 7 port selector ouptut 1 and 4 would wire up. then the second wire up ouptut 2 & 5, then 3 and 6 , & finally 4 & 7.

2011-05-10 19:12:00 Author: Unknown User

---

I've been having a bit more of a twiddle this evening. Dr C your circuit board worked a treat, thanks. It cleared up the glitches I was experiencing at one end of the cycle. I also began to understand the above discussion on timings: 0.1 seconds actually isn't that quick is it!? I moved to the next level and added two lights and all seemed to work fine. The main two challenges now are that a) it's not clear how to reset things - for example, the selector seems designed to remember a state and b) how to make all the lights blank - again the selector keeps the last output on. I guess the sequencer has the reset input so I could use that. As for turning all the lights off, that's not clear to me at all. I thought about having some AND gates between the outputs of the selectors and the lights. I could then switch out one input to the AND and thereby withdraw the power. In fact this would also enable me to cycle the selectors back to the first setting too (to reset). Another solution I thought of was to go the mechanical route and have tags on pistons that light the lights as they go by. You then end up with 15x3 pistons though (since there are 15 lines in the display and there will be 1,2 or 3 lights on at once). I guess what I'm essentially trying to do is emulate a dot matrix display!

2011-05-10 23:01:00 Author: Unknown User

---

well you could add an extra slot on the selector that doesnt wire to anything and use that 4 your reset it would also turn all the lights off. there r ways to go faster than .1 sec. if i am correct each logic placed will generally take up 1 frame if there are so many frames per second you could do a pulse then add in logic that doesnt do nething like place a node on a MC and place multiple of them. to slow down the pulse but would be faster than .1 sec

2011-05-11 04:50:00 Author: Unknown User

---

Regardless which approach you take, selector or sequencer, you should use a separate one for each line, not try to reuse a single circuit for 15 lines. And don't go the mechanical route, this is very doable with logic. If you need to reset things, that's easy - for a selector, turn on any of its numbered inputs briefly and the corresponding output will turn on; for a sequencer, use the reset input like you said. As for blanking all the lights, the easiest way is just to turn off the whole microchip. Otherwise you can use an AND gate for every light, or even do what BabyFace suggested and have an extra unused output on the selector (that's not normally triggered) that you can turn on.

2011-05-11 06:08:00 Author: Dr C Posts: 122

---

Thanks for all the tips. Plenty in there to help me move a big step forward! As mentioned, Stacker involves the player having to press the 'stop' button at the right time in order to position the currently moving set of lights on top of the stationary set of lights in the row below. I'm currently trying to figure out how to determine if the current set of lights are directly above the set of lights in the row below. Here is an example: - XXXOOXX (1) (O represents a light in the on state, X represents a light that is off) XXXOOXX (2) In theory this should be fairly straightforward since the position of the selector in row (1) should be the same as the position of the selector in row (2). Reading the Wiki documentation for the Selector reveals that each output is either 0% or 100%. However, it seems that I need either a percentage value representing the position of the selector (which I can then compare to the other) or a numerical value. Searching through the forums and the interweb though doesn't reveal an obvious way to do that. A few ideas that I have had are: - 1) Using the 7 bit register that I've read about to store the value of the selector 2) Putting some kind of counter/timer just before the cycle input to the selector so that the value can be stored. 3) finding some way of processing the outputs of the selector to convert them to an analogue % or integer (maybe using the ADC circuit I've read about) 4) reading the lights themselves and figuring out the position from that. Perhaps by determining if the light is on and then counting the tag number. However, I'm not really sure what would be the best method. All suggestions welcome!

2011-05-11 16:27:00 Author: Unknown User

---

In theory this should be fairly straightforward since the position of the selector in row (1) should be the same as the position of the selector in row (2). It's not quite that simple. Selectors 1 and 2 could be out by as much as 2 blocks and the game could still continue, assuming the moving lights are 3 wide in the lower sections. And you've got to deal with different widths of the moving sections - ie smaller widths in the higher rows (assuming you're making this game identical to the one in the video). I'd definitely read the lights. At button-press time, AND each light in the current row with the corresponding light in the row below it, and turn them off if there's no match. It could take quite a few gates in each row to get it done, but logic gates are cheap on thermo. That's the way I'd go about it at least. If you'd like a picture of something resembling the circuit that's floating around in my head let me know and I'll build a demo version.

2011-05-12 18:37:00 Author: Dr C Posts: 122

---

you could use and gates to determine whether the player has stopped it correctly. say light 7 is on you could place an and gate so the next row will only start if & only if row seven is lit on the next 1. or you could use a tag system to do the same

2011-05-12 18:43:00 Author: Unknown User

---

Dr C. I see your vision more clearly now and it's beyond my abilities :-) I think I'd better explain the method I have used to implement the 2 and 3 light cases. I have wired the outputs of each selector to 2 (or 3) lights. Thus I have needed more than 7 lights overall in those cases. I can see how it would be much easier from a detection point of view to treat each row like a proper dot matrix display. I guess I'm seeing an alternative design now where there would be just 7 lights per row. Then I'd have 3 selectors per row, one for each case (1,2 or 3 lights). The outputs of these selectors would then be wired to a set of logic prior to the lights that would group the lights together. I guess this would use OR gates since the left most light would be used in all cases (1, 2 or 3 lights). Then there would be another testing layer between the rows that would be comprised of the AND gates you mention. Thus, the switching part (the selectors) and the lights would be quite simply designed and all the heavy lifting would be done by the logic in between. If I could reduce it down to one set of lights per row it would certainly make it a lot simpler. In fact, how about turning the whole thing digital and just represent each line as binary? I could feed in a signal to the selector in the form of binary to the lights (via a register) and just do a compare on the binary values. I could store the left right seqence of lights as timers or batteries with a preset value. I could then even store characters and scroll messages as in the real game! I've got absolutely no idea how to implement that though...

2011-05-12 21:45:00 Author: Unknown User

---

I think I have this all figured out in my head, but I can't explain it..... There would be lots of tags and tag sensors (set to require 3, 2, 1, etc). I will put it together and post a picture.... with some attempt at a description

2011-05-13 03:35:00 Author: shane_danger Posts: 283

---

Further to my post, I've been doing some more reading around the forums and found this (https://lbpcentral.lbp-hub.com/index.php?t=50920-Need-a-better-algorithm-for-my-ADC&p=788182&viewfull=1#post788182). It's an example of a 7 bit register (values from 0-127). Would be great to try and use something like this in the level. Basically, If I could represent the movement of the light as bit patterns and have the output wired to the correct selector inputs. For checking whether the lights in adjacent rows are aligned, it would still probably be easier to compare things on a bit by bit basis though (rather than comparing 7 bit values). Also, I take on board Dr C's point about the lights not having to be totally aligned to still be valid. I should have called out that I was intending to have a first pass version where only completely aligned rows would be allowed...It's of course much trickier to cover cases where there is only a slight overlap and then having to drop non overlapping lights.

2011-05-13 17:43:00 Author: Unknown User

---

it would only be an xtra chip or two of duplicate logic

2011-05-13 18:20:00 Author: Unknown User

---

Further to my post, I've been doing some more reading around the forums and found this (https://lbpcentral.lbp-hub.com/index.php?t=50920-Need-a-better-algorithm-for-my-ADC&p=788182&viewfull=1#post788182). It's an example of a 7 bit register (values from 0-127). Would be great to try and use something like this in the level. Basically, If I could represent the movement of the light as bit patterns and have the output wired to the correct selector inputs. I really think you're going down the wrong path here. Using binary registers is a whole lot of extra complexity for an inferior result (the difficulty of catching partly misaligned rows etc - I assume that eventually, beyond your first version you are going to want to do that). Producing the 3 bouncing light pattern isn't hard to achieve, either with a selector (and some OR gates) or a sequencer. Directly comparing the row of lights to the row immediately under it is also pretty doable. And completely eliminates the misaligned row issue. I'll whip up a demo circuit of this stuff tomorrow so you can see what I'm talking about.

2011-05-13 20:49:00 Author: Dr C Posts: 122

---

I really think you're going down the wrong path here. Using binary registers is a whole lot of extra complexity for an inferior result (the difficulty of catching partly misaligned rows etc - I assume that eventually, beyond your first version you are going to want to do that). Producing the 3 bouncing light pattern isn't hard to achieve, either with a selector (and some OR gates) or a sequencer. Completely agree. I didn't put too much time into this yet, but I made the first set of three lights that move back and forth and a second row that tells a third row how many matches there are. I still think the sequencer is the way to go. You just line up the batteries on the sequencer and connect them to OR gates. Changing the speed is as easy as adjusting the seconds per bar on the sequencer. I'll probably finish it up tonight... I'd like to see how it compares to Dr. C

2011-05-13 23:16:00 Author: shane_danger Posts: 283

---

OK, here we go. First the pattern generator: 33990 Since shane_danger is using a sequencer, I've used a selector. It's similar to the circuit I gave before, but with a bunch of OR gates so 3 lights at a time will be lit instead of 1. Now to compare the lights: 33993 For simplicity I've only put 2 lights in this row, not 7 (the green and blue gates are for lights 1 and 2 in the row, respectively). How it works: when the yellow selector is in its initial state, the lights will be purely controlled by the pattern generator (orange microchip). When the button is pressed the selector will go into state 2, and those lights remain on only if the corresponding light in the previous row is also on. So this will take around 22 gates for each row of 7 lights, but it's pretty easy to wire up.

2011-05-14 06:33:00 Author: Dr C Posts: 122

---

I guess we're all in different time zones hence I've been experimenting with stuff without the benefits of the recent posts from Dr C and others...Didn't want you to think I've been ignoring advice! Just for the record, I'm based in London (GMT)...You'll be pleased to know I've dropped the idea of using a register :-) Here's what I've got so far: 33998. Here's how it works: - 1. Each chip to the left hand side of the lights contains a 1,2, and 3 light pattern generator based on the selector based design that Dr C provided in an earlier post. The selectors are attached to a single set of 7 lights (per row) via OR gates. So I've got rid of the multiple sets of lights per row I was using previously... 2. Each pattern generator has 3 states a) on and moving b) on and static c) off and reset. 3. Whilst I have included all three pattern generators in each row (and hence incurred some wastage), I think this is cleaner. 4. I then have a separate chip along the bottom containing a 16 port selector (15 ports for the rows plus I port for global reset). 5. Each output is wired to a) the activate port of the current row and b) the on but stay static port of the previous row. Thus as the button is repeatedly pressed, the rows are stacked as in the image. 6. After all the rows are filled the final button press resets the whole set. Of course, this only covers the pattern generator side of things and I'm yet to implement the light test. I have a few reflections on the design: - 1. There are a lot of wires! For example, each row has 3 pattern generators connected to the 7 lights via OR gates. Some of the OR gates have 4 or 5 inputs. Also, the controlling selector (along the bottom) has 15 ports which are attached to three sets of 15 circuit board nodes (representing the 3 states per row). Would be good to understand if there is a clever way to reduce this since there is quite a lot of lag when making adjustments (even though I've set all the chips to not show wires). 2. I think there is a slight bug in my reset logic. In addition to turning the chip for the row off, it is supposed to reset the row so that when it is activated again, it always starts on the right hand side. It does work but sometimes resets to the left rather than the right. I need to look into that...I don't think it's anything too big but will have to be implemented 15x3 times! 3. Having come from a Java programming background it's a real shock to be working at such a low (essentially bit) level!!! Many thanks for all your support.

2011-05-14 13:34:00 Author: Unknown User

---

sometimes with logic it's something that you have to except that there might be a number of wires. but to reduce wires and the size of your MCs when they are closed. you can use a number of tags and tag sensors from outputs to inputs istead of wires.

2011-05-14 18:43:00 Author: Unknown User

---

Now that PSN's back up, if you want to drop me a line there sometime I'd be happy to come and take a look at what you've built so far.

2011-05-16 09:00:00 Author: Dr C Posts: 122

---

Yes, good news that the service is back up. Hope it stays that way! Will look you up next time I'm on...

2011-05-16 11:41:00 Author: Unknown User

---

sometimes with logic it's something that you have to except that there might be a number of wires. but to reduce wires and the size of your MCs when they are closed. you can use a number of tags and tag sensors from outputs to inputs istead of wires. I love wireless gates, you can even eliminate OR gates by just having multiple switches turn on the same tag sensor. This is especially useful when you have 6+ inputs for one switch, the OR gates with too many inputs will cause a TON of lag in create mode. I use wireless switches whenever it is possible/practical.

2011-06-28 00:37:00 Author: sp0ngyraver Posts: 407

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.