Archive: 26 posts

---

There's been a fair bit of info flying around at the moment about Adder/Subtractiin circuits, 7 bit registers, ADC/DAC converters, so on and so forth. My mind is hungry to get into this level of logic appliance as the potential avenues this knowledge may open up gives itself enough credence to put in the effort to learn. The one majour hurdle for me though, and quite possibly allot of other fairly decent logic heads, is these circuits seem to always be explained as something with a function in and of itself. I can't seem to think of any realistic practical applications for such circuits. Adder and subtraction circuits are the easiest to see what they would be good at. If you for instance wanted a specific analogue value entering a component of your logic network to trigger a set amount of 'fill or un-fill' for a further analogue value for some reason or other. Not to mention they are wonderfull at maintaining a high level of control and understanding of exactly what is happening within the circuitry. This is where i kind of fail though, beyond the above. the rest of the 'uber-logic' described in these wonderfull and advanced tutorials and guides falls very much into the ethereal realms of metaphysics where they only potentially exist to fill hypothetical and mysterious functions well beyond my current scope of ability to apply anything of that level in a practical context in game. So a plea goes out to those of you who don't have this mental block to explain to the rest of us hungry to learn yet academically incapacitated in the ways of computer science and the deeper echelons of boolean logic, exactly how these different systems can be applied within a larger logic framework to carry out a specific function. You could describe how you personally have used a 7 bit register, or Comparison gate, or DAC converter, so on. Or simply explain the theorem behind one or more of these circuits, why for instance a register consisting of '7 bits' seems to be enough for the LBP2 engine, and not more or less. Then hopefully those of us really willing to take on this information can now also carry thought through into actually encorporating it into level design, as i am sure was the original tutorials intended purpose's. I believe i am 1 of many in the same boat, so i believe this needed explanation will also stimulate a larger portion of this comunity into active discussion of such circuitry, in turn bringing the otherall knowledge qota of us all up a notch or two

2011-02-25 13:23:00 Author: Epicurean Dreamer Posts: 224

---

DAC and ADC are probably the only things that I use (mostly because its the only thing I understand). Haven't bothered with registers, since, like you, I have no idea what they could be used for.

2011-02-25 14:43:00 Author: SSTAGG1 Posts: 1136

---

So far for me DAC/ADC and adding/subtracting has been the most useful. Right now I'm working on an RPG level, and this stuff is at the core of how the combat system works. When an attack is peformed, the defender's defense is subtracted from the attacker's attack, and that number gets plugged into a sequencer that has a battery running across its length. As long as the battery is active, a NOT gate pulse generator sends out pulses that the defender's health bar picks up, causing it to lose points. The pulse generator also feeds into a 100 point counter, and the value from that is subtracted from the difference between the attacker's attack and the defender's defense. Once the counter is equal to that value, the sequencer reads 0, which shuts off the battery and resets that counter, so that the defender loses exactly the right amount of health. A similar method is used to determine the turn order. I'm not sure, but I think the advantage of a seven-bit register is that it lets you deal with more precise values. Analog signals pick up some very small margin of error when you process them, so if you're doing some intensive stuff it might throw off your math. If you use the register though you're spitting out exact values at the end that haven't been processed at all. I think you can also use it to reduce latency? Not totally sure. I'm still very dumb when it comes to this stuff, I didn't learn about it myself until very recently as well. I think a lot of it isn't particularly useful unless you're gonna go absolutely bananas with the logic driving your level.

2011-02-25 15:57:00 Author: Speed Racer Posts: 156

---

Right after getting my signed 7-bit register working, I struggled with exactly what you are asking - "What good is it in LBP2?" The advantage of using a digital register is the value can be modified and a comparison done at 15Hz. Sequencers are always involved with comparing analog values, and incur latency. Using digital circuits eliminates a major portion of the worry about race conditions or timing issues - mainly because the digital components are more black and white when it comes to timing. Even with this advantage, it's not readily apparent what use a digital register would be to creators in LBP2. But a couple recent requests sent me back to the lab, because solving those issues using a purely analog approach was difficult, if not nearly impossible - at least for me. Take for example the request for a Health Bar that had a maximum Hit Point value that could be temporarily modified or increased as the level of the player increased. Using an analog design means either scaling, or embedding predefined components for each possible value. And if you wanted to transfer the current damage to the new Health Bar, it becomes even more complex. However, by using a digital register, your maximum hit points is only used for comparison. And sequencers are not necessary thus not incurring the timing issues I mentioned earlier. What I plan on doing with my digital register is embed it within chips that appear for all intents and purposes to be analog. But these digital internals help me solve problems imposed by analog signals.

2011-02-25 16:01:00 Author: Shanghaidilly Posts: 153

---

Right after getting my signed 7-bit register working, I struggled with exactly what you are asking - "What good is it in LBP2?" The advantage of using a digital register is the value can be modified and a comparison done at 15Hz. Sequencers are always involved with comparing analog values, and incur latency. Using digital circuits eliminates a major portion of the worry about race conditions or timing issues - mainly because the digital components are more black and white when it comes to timing. Even with this advantage, it's not readily apparent what use a digital register would be to creators in LBP2. But a couple recent requests sent me back to the lab, because solving those issues using a purely analog approach was difficult, if not nearly impossible - at least for me. Take for example the request for a Health Bar that had a maximum Hit Point value that could be temporarily modified or increased as the level of the player increased. Using an analog design means either scaling, or embedding predefined components for each possible value. And if you wanted to transfer the current damage to the new Health Bar, it becomes even more complex. However, by using a digital register, your maximum hit points is only used for comparison. And sequencers are not necessary thus not incurring the timing issues I mentioned earlier. What I plan on doing with my digital register is embed it within chips that appear for all intents and purposes to be analog. But these digital internals help me solve problems imposed by analog signals. Yeah but I ended up making it work just dandy with a purely analogue solution. You correctly pointed out that making the leveled-up health bar remember what health you were at would be hard, but I'm actually not concerned about that, simply because the level is supposed to be in the spirit of games like Mario RPG or Paper Mario, where you actually do get all your health back when you level up. The analogue solution I ended up settling on turned out to be very simple, with far less logic than a register would have required. The only downside to it is that it's a tiny bit slower than I'd like but that's not really a major deal.

2011-02-25 16:11:00 Author: Speed Racer Posts: 156

---

The analogue solution I ended up settling on turned out to be very simple, with far less logic than a register would have required. The only downside to it is that it's a tiny bit slower than I'd like but that's not really a major deal. Which is one thing I was trying to solve. The other thing I wanted to do was to provide a chip that had only inputs. In other words, what I wouldn't want to do is design a chip for someone else that required them to modify the internals to get it to work for their application. So if your starting health bar is 38 points, you would just hook up a battery set to 38.

2011-02-25 16:21:00 Author: Shanghaidilly Posts: 153

---

Maybe I'm just not remembering your responses from the thread, what exactly was your solution? Based on what you're saying it sounds like you plug the value from the register into the negative half of a combiner, plug the battery set to the max HP into the positive end of it, and when the combiner spits out 0 you trigger the knocked out status for the character in question. Is that at least sort of right? That would actually be pretty nice, and would do in a clock tick what my system can take up to 6.6 seconds to pull off. The only problem that jumps to my mind is that it doesn't produce a nice display for the player. It doesn't seem like there's an easy way to translate it into, say, time emptied from a timer. If they're at full health, then you can take the inverse of the combiner value and feed it into a timer for one second, and I think that would make it proportional? But then when you take damage again it gets a little messy, you'd have to do something like reset the timer to take the new value, which wouldn't look good. Or I guess you could take the value in the timer, subtract the direction combiner value from it, and plug value into the timer for one second. I think that would reduce it by the right amount? I'm not positive since I don't have the game in front of me right now but that sounds right. Okay, fair enough! Assuming I'm right about all of that then the register solution is superior to my own. Wait a second, no! you could just directly compare the analog value of (attack - defense) to the value being output by the battery. Unless I'm missing something there's no reason to put it through a bit register first, is there?

2011-02-25 16:38:00 Author: Speed Racer Posts: 156

---

Wait a second, no! you could just directly compare the analog value of (attack - defense) to the value being output by the battery. Unless I'm missing something there's no reason to put it through a bit register first, is there? Sure. That works well for a turn based game where you can collect all the damage and heals with simple add/subtracts, then just do one comparison at turn-end to see if you're dead. But what if the health bar needs to be updated in near real time, like for a shooter? It would be constantly checking, and there's where I think the application of using digital, just for the ease and speed of comparisons, comes in.

2011-02-25 21:51:00 Author: Shanghaidilly Posts: 153

---

Sure. That works well for a turn based game where you can collect all the damage and heals with simple add/subtracts, then just do one comparison at turn-end to see if you're dead. But what if the health bar needs to be updated in near real time, like for a shooter? It would be constantly checking, and there's where I think the application of using digital, just for the ease and speed of comparisons, comes in. Okay, fair enough. I'm not sure that the register would make it any quicker, but I can certainly see how it might be.

2011-02-25 22:51:00 Author: Speed Racer Posts: 156

---

I'd like to see someone build a multi-layered perceptron in LBP. Once one of those is built, we'll be able to use AI learning instead of procedural AI.

2011-02-25 23:09:00 Author: munrock2 Posts: 96

---

I may have missed some important info here, but why exactly would I want to convert my health bar from addition / subtraction increments on a timer to registers. (I also don't know how to do this, but I'm sure I can find out how by reading through some posts / tutorials again) What I'm using right now is just a series of impact sensors to detect a tag on a projectile, this then sends a pulse to the addition/subtraction system with an AND gate to set signal strength, and modifies a timer health bar. I also created a tag strength based damage system. I use 10 tag sensors, each detecting one additional tag (so the first detects 1 tag, the last detects 10 tags). Then I add together all the sensed outputs, and put that through the health bar. Each projectile has a different tag strength, and the tag is activated by an impact sensor. The first method works quickly, haven't really analyzed the speed of the second yet, but it works. How might a 7-bit register improve these systems?

2011-02-25 23:20:00 Author: SSTAGG1 Posts: 1136

---

With a register, you are not constrained to scaling the amount being held, and you can add or subtract any amount. you like. Also, you can make the register as large or small as you like just by adding another bit. For example, I am using a 4 bit setup to store a value between one and 10. I have tag sensors attached to some logic on each bit to add to it. Whenever I want to add a value, I just trigger whichever combination of those four tags that I need, and it's done. It all works in one frame, and gives me far more control than if I were using a timer. I have these tags on each place of precision in my number, so it's very easy to add anything from 1 to 999 in one pulse. I have that outputting through a set of AND gates into my numeric display which has a latency of 1 frame. So in two frames I can add a value, and update the display. Then, when the game is over, it is a breeze to just dump that value into score givers.

2011-02-26 01:15:00 Author: tdarb Posts: 689

---

How many bits would be required for a range of health 10-30000, and damage ranging from 1-10000? I've got drones that barely need to be hit to be destroyed (they're meant to waste attacks so mother ship is not damaged), as well as Giant Orbital Bases that require an armada to destroy, or several superweapons, or just lots of patience. Those numbers are what I would like to achieve, but the whole system needs to be easy on the thermo as well, which is why I kept it simple with just a basic addition setup. My experience with all this stuff is zilch, so sorry for taking a while to understand it. What I'm missing is how exactly the register is subtracted from or added to. How would you deal with values over 100? By scaling? How would it work then? Is there a link or guide to help me with using these as health and damage bars? That or a picture usually gets me on the right track. I'm going to reread all the logic tutorials and blogs. Maybe then I'll be able to reply with some actual understanding of how to do this. EDIT: For my purposes, there is no real use to actually displaying the number. All I need to do is damage and health.

2011-02-26 03:00:00 Author: SSTAGG1 Posts: 1136

---

Sure. That works well for a turn based game where you can collect all the damage and heals with simple add/subtracts, then just do one comparison at turn-end to see if you're dead. But what if the health bar needs to be updated in near real time, like for a shooter? It would be constantly checking, and there's where I think the application of using digital, just for the ease and speed of comparisons, comes in. Well nuts, now I'm thinkin' about this more and I'm not sure one method is really any faster than the other. Bear with me for a second. My suggestion is to send an analogue signal equal to the total amount of accumulated damage to the negative side of a combiner, plug a battery set to the maximum HP of the "actor" to the positive side of the combiner, and when the combiner is outputting a 0, you trigger the logic for death. Your idea is, as far as I can tell, roughly the same thing but you're representing the accumulated damage with a 7-bit register. I'm guessing that you look at what the max health battery is, and that turns on an AND gate wired with each of the bits that you would need to add up to get to the battery value. I might be wrong about that but I think that's the basic concept? Neither of these ideas seem like they have much lag to me. I don't have a full grasp on how latency works, but I believe the only things that add frames of latency are positional sequencers and loops, right? Mine has neither of those. Yours might use a sequencer? I'm not one hundred percent sure on how you're suggesting to use the register so that might be wrong. The stuff I said does introduce some lag, but only in the display of the information to the player. The actual math is done instantaneously AFAIK. And if you wanted you could easily create a different type of display that eliminates lag, for instance making some hologram start pulsing red when you fall below 1/3rd health or something. Actually now that I'm thinking about it my suggestion for a timer-based display might not work how I was thinking anyway. I dunno, I could absolutely be missing something, or forgetting about another possible source of latency, but as far as I can tell both systems go at basically the same speed, yours just takes a detour.

2011-02-26 03:07:00 Author: Speed Racer Posts: 156

---

to do it directly, 30000 would require 15 bits. If you are doing it as just health without need for a visual display, it would be very easy to implement that, and may work a lot better for you. If you want a display, it looks like that could be quite a bit of wiring, but I'm not sure. At a very basic level, these registers are just binary numbers. each bit represents a one or zero. in a four bit register 1=0001, 2=0010, 3=0011, 4=0100, 5=0101, and on up. This is what I am using for my numbers. It's what's known as a BCD (Binary Coded Decimal). I just chain these BCDs together to get my final number. However, registers on their own could represent anything from letters, to colors, to entire pictures if you want. It's really just a storage space where you can save a given value. RGB colors are really just three different 8 bit registers as far as the computer is concerned. as always rtm's logic blog is great for this. the LBP1 portions cover more of the binary stuff. Also, I've found this site to be really helpful http://www.play-hookey.com/digital/ and you will probably need one of these http://acc6.its.brooklyn.cuny.edu/~gurwitz/core5/nav2tool.html

2011-02-26 03:28:00 Author: tdarb Posts: 689

---

That is one advantage that binary registers have, they have no issue with numbers over 100.

2011-02-26 03:41:00 Author: Speed Racer Posts: 156

---

Aw man, 15...... I wonder how much thermo it'll take up. I'd need one for health, and another for damage/healing? For every unit...... I think I'll stick with my simple damage system for now. __ EDIT: I think, because I don't actually need the value to be super exact, and I'm never actually seeing it, using my tag strength impact/tag sensor system would work. BTW, I'm explaining this to myself as I write it, so ignore the really basic stuff. By dividing the tag strength by whatever I need the output damage to be (if I need to divide it), I could achieve a very wide range of values without using a relatively thermo intensive damage calculator (instead, each projectile would get a timer to create very low values) . Instead of 15 bits, I would only need around 10 combiners with a single impact sensor and 10 different tag sensors (10 is how many simultaneous impacts I expect to occur, could easily change). I would make the max time 0.1 seconds, and divide to achieve the damage range I need of 1-10000 (so timer max 10000, current 1). This works for a unit with 30000 health, since the 1 damage hit does 1 damage, but for a unit with less health, I would need to multiple this value by X amount to reach the right ratio. So for a unit with 1000 health, I would need to multiply by 30, which would occur after all inputs were added (which would rarely result in overflow, but if it did, I'll just waste it.

2011-02-26 03:52:00 Author: SSTAGG1 Posts: 1136

---

you don't need seperate registers for hurting and healing. plug your register into two different and gates The other input for one and gate would check to see if some sort of "healing" tag is active, and the other input for the other and gate would look for a "hurting" tag. Plug both gates into a direction combiner.

2011-02-26 04:36:00 Author: Speed Racer Posts: 156

---

Ya, I realized that. Hence why I put the slash for Damage / Healing. Anyway, I'm using a different method that allows me to use any strength of value easily without having to create a 15 bit register. See my post above.

2011-02-26 05:07:00 Author: SSTAGG1 Posts: 1136

---

If you have a working system then go with that, but just for giggles I will describe the same process with a 14 bit register. You would only need 14 bit for 10000. Setting it up is rather easy. It's just 14 toggles each attached to a simple adder composed of a couple of AND gates, a Couple of ORs, and an XOR. Now, run them through an AND gate so that when the correct combination of toggles for 10000 is hit or exceeded, you encounter the kill condition. Now to calculate damage. If you want one point damage, just flash a tag that corresponds to the 1 bit. It triggers the adder and adds 1. You want 100 points damage, flash the tag that goes with bits 3, 6, and 7. If you want to do 1000 you can do that by hitting the right tags. You do your healing the same way by adding the two's complement. Any range of damage/healing is possible with just a simple flashing of tags. don't even need any extra parts. You can use your same system of tag sensors requiring N tags to handle simultaneous hits. This would take a tiny bit more initial setup, but manipulating the projectile/hit strength would be much easier since it is just direct damage with no scaling involved. If you have a working system, you should probably stick with it. I'm just posting this for reference. It is what I am considering doing if I can find an easy way to translate it to decimal numbers for display. If I didn't need that I would be using this already.

2011-02-26 05:36:00 Author: tdarb Posts: 689

---

Well, it's mainly to cut back on thermo usage, so whichever system takes up the least amount of thermo, I'll use. The whole point of producing my system is that I can do it with a single tag, and just adjust the strength of it. With your explanation of how the bit system works though, I think I understand it a lot better. The issue is that it would require different tags for each toggle, and multiple tags on each projectile. I dunno how expensive any of this is on the thermo, so I'm going to go ahead and make both. I do like the bit system's flexibility though. EDIT: Nvm, I lost ya at the couple of ANDs, ORs, and XOR. Also, how to convert the combinations into a value which would be used to add/subtract from the other register for health. Just forget about it, I've never done binary before, so learning how to use it in a single day, probably not the best. Unless you have a picture, I'll give up for now. EDIT 2: Just read through rtm's logic blog some more and realized I skipped over the section on using binary for analogue values. EDIT 3: Yeeaaahhh, no. Turns out I didn't quite get it. Could someone please post a pic of the actual addition/subtraction process (or explain it in more detail). I still don't see how a register could produce a value which can be used to modify another register (I see how the different values are made though.....in binary, not in anything you can put into a directional combiner to add/subtract). Do you leave the binary signals as is and directly use them to adjust the other register....so much I don't know, bah! Perhaps some sleep will help me understand this a little better. EDIT: No, sleep, but I designed a method that uses: - ones, tens, hundreds, thousands, and ten-thousands place (eg: 7 _ _ _ _ for the ten-thousands place) - values 0-9 for each value - A multiplier that modifies value to correct value - Additions to combine all values - 50 impact sensors (1 for 'death&apos - a healing tag that alters damage to healing (switches path to the opposite terminal terminal of combiner) - takes up about 1/4 of a thermo bar..................................... not good.....I imagine there is a simpler method to do this. EDIT: Okay, starting to get it. Each bit represents a set value (1, 2, 4, 8, ...), and I just activate whichever values I want to occur by putting sending a signal to which ever bits are required.

2011-02-26 05:57:00 Author: SSTAGG1 Posts: 1136

---

I've been working on it again, and have found a zero latency solution. The trick is to not use the toggles at all. The basic adder looped back on itself becomes the storage for the bit value. Now I am just trying to figure out how to decode it to decimal for my display. If you'd like to take a look sometime add me and I will show you what I have. I'm still learning a lot of this stuff too, so it may not all be gorgeously laid out, but it's getting there.

2011-02-26 19:14:00 Author: tdarb Posts: 689

---

i would suggest you have a look at this. (http://www.lbpcentral.com/forums/blog.php?4150-Logic-Blog) reading through the earlier posts really helped me in LBP1, although some of it is completely beyond me . i too hope to learn a bit more about practical applications of logic, but to be brutally honest i think it takes a certain kind of brain to excel at this stuff *sigh*

2011-02-26 19:25:00 Author: Skalio- Posts: 920

---

@tdarb: I think that'd be helpful. I've been looking at the designs for the samplers, since they AFAIK, work on the same principal of using the registers to obtain a value. I just found a purely non-display function made in LBP2, exactly like you described originally, which explained a lot. Found a model of it on the internet, should have something working soon. The problem I have is how to actually take one value from or add to another. Right now I convert the bits into values, which are then subtracted from a timer (after some division to obtain the right order). The way explained seemed to say that the value could be directly compared to another register, saving the final value for additional modifications. I must be slaughtering the language here, since I have no formal education of using this stuff, but I hope that helps to explain my issue / method. Question: Is add/subtract just a matter of determining if the bit is true, then: add a true = carry, add a false = no change, subtract a true = false, subtract a false = no change. And if false: + true = true, + false = nc, - true = carry subtraction to next bit (how???), - false = nc.........? That seems logical, though I am seriously doubting my logical capabilities right now. Maybe if I just go ahead and make it again, I may be able to do it.

2011-02-26 19:33:00 Author: SSTAGG1 Posts: 1136

---

Question: Is add/subtract just a matter of determining if the bit is true, then: add a true = carry, add a false = no change, subtract a true = false, subtract a false = no change. And if false: + true = true, + false = nc, - true = carry subtraction to next bit (how???), - false = nc.........? That seems logical, though I am seriously doubting my logical capabilities right now. Maybe if I just go ahead and make it again, I may be able to do it. That is pretty much it yeah. To add two bits, you use XOR. A XOR B is true if either is true, false otherwise. (0+0 = 0, 0+1 = 1, 1+0 = 1, 1+1 = 0) The carry is A AND B. (1+1 = 0+carry) The combination of XOR and AND like that is known as a half adder. It's only half because it doesn't add in the carry from the previous bit. How do you add in the carry? Simple, perform a second addition between the result of the first, and the carry from the next lower bit. OR the carry result from the main addition and carry addition to get the new carry.

2011-02-26 20:59:00 Author: Tygers Posts: 114

---

Alright, so I got the bits down, with the addition and subtraction (pretty much copy and paste from here (http://www.play-hookey.com/digital/binary_subtraction.html), but how do I get the adjusted value to become the new A value, so that B (add or subtract) can modify it again? Will have to test further to see what is happening. Also, when I add or subtract the bit, it results in the same answer, with a C output. Is this correct? Once I finish it'll probably make more sense. EDIT: Nvm, mixed up the bit output and the carry... EDIT 2: Woot, it works (well, so far) EDIT 3: Thanks tdarb.

2011-02-26 21:22:00 Author: SSTAGG1 Posts: 1136

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.