Logic Switch Creator Pack

Quote:

---

Originally Posted by dcf

It's only with mechanical logic gates with the 0.1 second timings that one runs into delay errors.

---

Source?

Quote:

---

Originally Posted by BSprague

Hopefully that settles it, as I do not think that an item programmed by MediaMolecule would actually have to go through all of the steps that a mechanical object has to go through to reach its goal.

---

Sadly, it's not as simple as that. Delay effects occur in real world electronic circuits, no matter what speed they are running at. Whether the components have fast propogation or slow propagation there is still a propogation time that is non-zero. One gate has to process its inputs into outputs before the next one in the chain can process its inputs. This leads to timing issues and some quite subtle effects and design constraints known as race hazards / race conditions. They are a pain to understand and account for. In the proposed system there would be no way to understand them intuitively, as there currently is due to the moving parts. You'd just have a magic box that doesn't do what you want/expect and no visual clue as to why.

ZOMG!!11!! logic craet pk GLITCH!!11!! Lulz! :rolleyes:

It has nothing to do with the processing speed, it's a fundamental issue with logic design and a perfect example of why being able to see moving parts makes the system more accessible.

Also, not exactly a downside but they would have to introduce specific delays so it would make sense to match these up to the 0.1s model. If it was all calculated as quickly as possible, a loopback could potentially kill a processor core and knacker the engine. Contrived example where setting the input to 1 would result in the system never settling:

output <= input AND NOT(output)

Code:

---

.

            |-----|
input ----- |    |
            | AND |-------------- output
    |--not--|    |    |
    |      |-----|    |
    |                  |
    |-------------------

.

---

I'm not just naysaying here btw, it's just that the whole thing is way less simple than it seems on the surface.

Quote:

---

Originally Posted by rtm223

output <= input AND NOT(output)

Code:

---

.

            |-----|
input ----- |    |
            | AND |-------------- output
    |--not--|    |    |
    |      |-----|    |
    |                  |
    |-------------------

.

---

---

If I'm understanding that right, one input is always active and the other NOT is active when the output isn't. So then at the start of the cycle, both inputs would be true, because the output isn't active yet. This would cause the output to become true, making the NOT false, and therefore inactive, correct? In that case it would simply shut off, not jump into an infinite loop. I'm not sure if it is possible to do in LittleBigPlanet. For example, try making a bomb that shoots out a bomb that shoots out a bomb that shoots out a bomb, etc. You'll realize that you have to nest each one inside the previous one, and it will only go as far as you have the patience to set up. You can't simply make it a never-ending setup, LittleBigPlanet just doesn't work like that. And I understand the 0.1 mechanical delay thing, but it could be applied to the whole system, so that instead of every action taking 0.1, it would recognize the complex logic at work and calculate it all, while maintaining that 0.1 second for syncronization's sake.

And there still could be a visual cue, like each wire is set up in a row, and if it is active, a check appears next to it. When all are checked, a green light appears and the AND gate fires. That is one of the many ways a visual cue could be used to show off how an AND gate in LittleBigPlanet works. Now I just wish there was an option to show wires in play mode somewhere under the lighting section that toggled them all on or off for demonstrational purposes.

An explanation of that circuit as it changes with time:

Code:

---

.
Columns are time, input, output, NOT(output)


| t || i | o | !o |
|---||---|---|----|
| 0 || 0 | 0 |  1 |
| 1 || 0 | 0 |  1 |
| 2 || 0 | 0 |  1 |  Stable until input goes to 1
| 3 || 1 | 0 |  1 |
| 4 || 1 | 1 |  1 |  Input AND NOT(output) = TRUE
| 5 || 1 | 1 |  0 |  NOT(output) = FALSE
| 6 || 1 | 0 |  0 |  Input AND NOT(output) = FALSE
| 7 || 1 | 0 |  1 |  NOT(output) = TRUE
| 8 || 1 | 1 |  1 |  Same as state 4.

.

---

Note that at time 4 and 8 the state is the same - therefore the system will oscillate through states 4-7 until input drops to FALSE again. If you try to process this accurately all at once, the function will never end and the CPU core will lock down. There is no neat solution to that, really - you can bail after a certain number iterations, but that's a very sloppy solution. It should also be clear that the interval between each time increment is irrelevent - it can be as long or as short as you like.

You example of nested emitters is correct, but doesn't apply to loopbacks on wired systems. It is perfectly possible to wire up this system in LBP with mechanical gates - I currently use a similar, stable system for P-switches. I can't see why it wouldn't be possible to wire up a supplied gate object in this way. You wouldn't want to create an oscillator like this in LBP (it's a contrived example) but you can. The fact that the diagram alone isn't enough to indicate the unstable nature supports my statement that it's difficult to know what's going on when all you have is a diagram (or a set of functional blocks wired up).

Quote:

---

Originally Posted by BSprague

so that instead of every action taking 0.1, it would recognize the complex logic at work and calculate it all, while maintaining that 0.1 second for syncronization's sake.

---

Assuming the complex logic has no loopbacks in it.

Quote:

---

Originally Posted by BSprague

And there still could be a visual cue, like each wire is set up in a row, and if it is active, a check appears next to it. When all are checked, a green light appears and the AND gate fires.

---

Yes I thought of this, the gates would likely have a light built into them just like the mag switches. The problem here is you want all the logic to be caluclated at once, so you will just see inputs and outputs to the entire network, no intermediate / internal signals. You can still get race conditions and problems due to delay effects even if there are no loopbacks and would have to understand the theory to deal with it. If you can't see intermediate signals changing then you would be back at the magic box analogy. So, you slow down each gate to propogate in 0.1 seconds as I suggested earlier - I wouldn't fancy following even a moderate network of logic gates as flashing light signals, switching at 0.1s, in real time.

The main point here is that the speed of the gates is an advantage of the suggestion. It's a disadvantage of the current mechanisms.

Except it isn't. Speeding up the gates to be faster than the 0.1s synching point is an absolute nightmare for various practical reasons as I have described above.

The only way around it realistically is have 0.1 second registers and create a pipeline. This would require the player to understand the relevent design concepts so would be bad. Alternatively you ban loopbacks, which means that some wires can't be connected to some gates, which breaks the existing model of wiring, may be confusing for some and extremely limiting to others. More limiting than the existing system. It also wouldn't solve the issue of race hazards in "1-way" logic.

Keeping it slow is a far more practical option.

...but I know this...

A logic gate creator pack is a must... I'm like a lot of posters in this thread before the topic went all Einstein Theoretical... It would be a great boon for LBP in general. Those who understand gates already and have built their own would have a new toy, in which to; theorize, scavenge, deconstruct, experiment, and generally use in ways that nobody appreciatively foresaw. The averagely informed creator would have one less thing to fret over... rather than having to entirely comprehend logic he would have a tool (and don't forget those cute Mm mini-tutorials) that would allow maximum effect with a minimum of tinkering outside of some good ol fashioned trial and error. For those creators who have no interest in any understanding of logic gates... yet want to emulate something they've seen... well now these pursuits would be attainable. And those who didn't want to be bothered... well, wouldn't be bothered. A Mm gate packs would not benefit everyone... and a bad level would still be a bad level... but generally speaking It would be a 'smart tool' to have access to as a creator.

A Logic pack that accomplishes all this and eases demands of the thermometer... I'm all in. In fact, I demand it! Now what are you gonna do with all your newly found 'free' time, RTM?

rtm:

I still say that you are fundamentally incorrect with this. Not because you don't have a good grasp of electrical engineering but because you are misapplying it.

LBP does not use real world physics. The assumption you are making here is that somehow LBP code will create a virtual computer circuit and simulate it. Very simply put, that's not what is going to happen.

All that's going to happen is the game will run a computer function. An incredibly basic one at that. It's not a hardware simulation. It's a software algorithm.

I know you're looking at this from a hardware perspective and your concerns would be correct if the game ran a hardware simulation. However these points simply don't apply to the incredibly simple software functions that these logic gates would get translated into. If I can do it on a 10 year old computer with a billion times the variables using an excel spreadsheet, the ps3 isn't going to have a problem.

The thing you're objecting to seems to be people creating recursion loops by wiring something to itself. This is a very simple limitation that can be placed on the tool to stop this. Excel does the same thing. If you try to create circular logic it stops you and tells you that you can't do that. I know this is a powerful feature in real logic gates but that also leads to all the real world complexities you describe.

There are things that can be done with real world physics that can't be done with LBP physics and the reverse is also true. The same would be true with LBP logic gates. Probably the two limitations I would expect to see placed on these things would be no circular logic and some sort of nesting limitation, implemented through the thermometer, to prevent slow-down from occurring.

I'm actually looking at this from the POV of a software engineer considering the implications of developing a system to simulate digital logic gates in exactly the way you describe. "Just running a computer function" to porcess logic is a hell of a lot more complex than actually running the real world logic. For example, the circuit I described is perfectly reasonable in hardware. In software, you cannot run that as fast as possible without a lot of implications. It's the running as fast as possible I have an issue with. This will impact ANY computer, it's a simple limitation of calculating logic networks in real time.

I know excel prevents looped logic and this could be done in LBP, or you could limit nesting. Rememeber that Excel is not really capable of realtime simulation. My point is that applying similar limits to a realtime simulation means thar the logic pack would be a step backwards from the current system, because it would be so limiting. A better limitation IMO is the timing limitation. This solves the problems of looping in a far neater manner. You stay at the same speeds you were before but still get many of the benefits and you don't lose the ability to do things that you can do now. It also means that you aren't putting limitations on the user design for cryptic reasons, so this would certainly help with being intuitive.

Nothing is going to prevent race hazards so that's an issue regardless. The only thing to hope is that the people who would struggle to comprehend them would stick to simpler systems.

As I've said several times through this thread, I'm not against the idea in itself, there are just a lot of practical implementations to it.

And gravel, I'll be using my free time to answer all the threads entitled ZOMG!!11!! logic craet pk GLITCH!!11!!!11!! ;)

rtm:

What I'm really pointing out here is that you are making the assumption that it will be implemented incorrectly. :)

Clearly interface is important. Designing good interfaces is not easy. However, a good interface will make this suggestion not only easy to use for the average player but implicitly prevent these problems.

I'm certainly not suggesting that Mm include the industrial transistor gate simulators used by the computer industry to design computer chips. What I'm suggesting is that Mm gives users some basic switches so creators can more readily make cleaner mechanisms.

I will update the OP shortly with a suggested implementation.

I'll see what your suggested implementation is and post up a counter one if I feel like it. We can always resort to just kicking the *bleep* out of each other in a carpark to resolve this if necessary!

Edit, so it looks like DCF is being slow today, my guess is he's drawing pictures of his interface? Who knows. I've just drafted my proposal for how such a system could be implemented, in such a way that it can be practically designed and implemented from an engineering POV and also should be very easy to use. It has no downsides VS the current mechanical system and would not be limiting for advanced users. I'm pretty sure I managed to squeeze in all the features that people have suggested (I think).

My Proposal

Basic Stuff
The proposal consists of a set of primitive devices (that can just be slapped down in a level and used "out of the box") and a more complex circuit device. I will cover the primitives first then move on to the circuit.

1. Primitive devices will take on/off signals as inputs and output whatever signal they like. Potentially they could take direction inputs, but this doesn't really make sense.
2. Each of the primative devices I describe here will take 0.1s to propogate (i.e when an input changes, the output will update 0.1s later).
3. The devices are designed to be placed on objects and wired up in the same way you would existing tools, except that they will have an input and an output and in some cases multiple inputs.
4. Each device will only have a single output (see converters below) and the output state will be indicated with a light.
5. For the basic gates, standard symbols will be used.
6. All devices will have tweakable visibility.

Gates:

1. AND - taking multiple inputs
2. OR - taking multiple inputs
3. XOR - taking multiple inputs
4. NOT - taking single input

Multiple inputs should be user defined (i.e as many as you like)

Latches:
RS - Set-reset, with option to favour set or reset if both are held high
T - toggle, will change output state when input goes from low to high
P - The permenant switch, this should have an option to reset it in case you trigger it in create mode!

Converters:

• A single device to change from any signal type to any other signal type (input and output tweakable)
• Included so that multiple inputs can be pumped out of a single gate without the multiple wires getting confusing.
• These will also propogate in 0.1s, for consistancy.
• By setting both input and output to the same signal you can create a D-type latch.

Timers:
Various timers that can stay on for t seconds, or trigger a one shot after t seconds etc. t would be expressed in increments of 0.1s. I couldn't really be bothered to think this one through, but these would be an exception to the 0.1s rule.

Note on wiring
The above solution still allows for loopbacks, you can wire anything to anything else in the network. gates can wire to other gates, gates can wire to themselves etc. The downside is that the networks will run slowly (though no more slowly than currently)

Circuit device:
Is a little box which takes n inputs and m outputs (n and m user defined). Inside the user is allowed to create a circuit from the primitive devices above. The following limitations are in place:

1. All wiring must be 1-way, there can be no loops
2. All inputs must be connected to something
3. All outputs must be wired to something inside the circuit.
4. The timers and the D-type latch may not be used.

Behaviour of the circuit device:

• Wiring within the circuit device will be routable to aid design
• The circuit device will calculate it's entire contents within 0.1s
• A circuit capture tool will be provided to allow you to debug your circuit with slow propogation times, then move it into the efficient circuit device
• Whilst loopbacks will not be available inside the circuit, circuits may loop back to themselves externally

Summary
The primitive devices will allow a beginner user to throw down a gate or two and wire them up, with no need to understand the mechanical processes currently employed. Thermo and development time will be improved, as will the compactness of creatures that require logic. The logic will run around as fast as it currently does, so there is no loss in this proposal, compared to the existing system.

The circuit device will allow intermediate users to create a logic network and have it compact and switching very fast - much faster than the existing methods, with only small downsides of not being able to loopback.

Advanced users will be able to use multiple circuits to create Register Transfer Level systems, using a 0.1s clock pulse and so will be able to create pipelined systems.


I recon this has only benefits and no downsides to the existing mechanical implementations.

Okay, my idea for an implementation has been edited into the original post. Please note that I only show AND/OR/XOR switches. Others can certainly be added later. The key things that I'm looking for in the solution are:

1) Ease of use.
2) Speed.
3) Low thermo.

Pretty similar then eh. Great minds think alike, although you could blame the fact that we were running off al the same info in this thread.

I really like the way you laid out the circuit builder, you could even have it so the editor won't let you move a wire to the left the gate it's coming out of - you wouldn't even need to explain it then! I was thinking of it being just haphazard!

Adding implied delay in each gate outside of the circuit would allow you to have no restrictions on wires though (gates can wire to each other and themselves etc)

Both proposals are great and virtually the same :)

I would love a logic gate pack and these sound like it would be easy to make complicated logic because it will be a uniform setup and all in a nice compact environment :D

I'm happy to combine things to make the best possible suggestion.

I should also mention something I'd like feedback on. Currently I have it written that logic switches can't be wired together. This could be made more intuitive by adding an additional behavior digital logic (maybe called electricity with a lightning symbol). Only logic switches would accept this new behavior. However, logic switches wouldn't have this as an option in their tweak menu. This would implicitly prevent them from being wired together (except in circuit board mode). This would also enable the delay switch to work intuitively simply by allowing this as a behavior in the tweak menu. In circuit board mode, the logic gates would automatically be set to electricity and it couldn't be tweaked.

I don't know if the extra clarity is worth the addition of a new behavior type for switches though. Ultimately I left it out of the implementation proposal.

DCF, if you make the gates have an implicit 0.1s propogation time outside of the circuit board (as per my proposal), then restrictions on wiring become unnecessary because each gate will only be able to update once every 0.1s anyway, so calculation of loops would be stable and stretched out over time. Only restriction is that all signals feeding into gates must be on / off type signals and the left-right restriction inside the circuit.

Quote:

---

Originally Posted by rtm223

DCF, if you make the gates have an implicit 0.1s propogation time outside of the circuit board (as per my proposal), then restrictions on wiring become unnecessary because each gate will only be able to update once every 0.1s anyway, so calculation of loops would be stable and stretched out over time. Only restriction is that all signals feeding into gates must be on / off type signals and the left-right restriction inside the circuit.

---

This is true, however it also limits the use by failing to solve the speed issue. The idea of an adjustable delay that goes from 0.1 seconds and up is a sound one. However, it would be really nice to be able to have players with little logic experience be able to just plot an AND gate into their level and not worry about a delay.

This is why I'm suggesting the delay as a separate component. Also, because people may want to use the delay outside of logic switches. In fact, I can't remember where I heard it, but supposedly a delay relay is one of the things Mm currently has in the pipeline.

The speed issue is solved in the circuit device. A player with little logic experience dropping an AND gate would not even consider the delay, I think. I can't think of an application where you would want a single AND gate and the 0.1 second delay is a major problem. It's what we have now and it seems to be fine for simple applications...

Quote:

---

Originally Posted by rtm223

The speed issue is solved in the circuit device. A player with little logic experience dropping an AND gate would not even consider the delay, I think. I can't think of an application where you would want a single AND gate and the 0.1 second delay is a major problem. It's what we have now and it seems to be fine for simple applications...

---

I think I've suggested this before, but why not calculate the 0.1 second delay globally, so the entire circuit updates in that time, not just a single gate. I think that speed gains are the major thing that everyone wants out of this, in addition to simplicity.

Because that limits applications by limiting the wiring for processing reasons, as I have tried to explain.

My proposal allows for an entire logic network triggering in 0.1s, by using the circuit device as I outlined. You do get the speed increases if you need them. I don't really get why the 0.1s synchronisation is a major deal, it is how LBP works and it exists as a feature of all of the existing switches etc (except the paintball switch, most of the time) and is how things works atm.

edit - it's probably worth noting that I wouldn't expect the technical details of timing to be part of the tutorial, further than on the circuit they could say that it goes really fast. The more advanced users that will want to do more advanced tasks would notice the effect anyway.

further edit - some examples of applications with the timing I suggest:

1. Simple AND gate application. Slap down a gate & wire it up. Takes 0.1s to switch - is exactly the same as mechanical gates.
2. Simple network ( a AND (b OR c) ). Slap down 2 gates & wire them. Takes 0.2s to switch - is exactly the same as mechanical gates.
3. Complex network with many many gates. Put it in the circuit device. Switches in 0.1s. Is much much faster than the existing mechanical gates
4. A processor core, with working ALU, PC and local registers, that could process a stored program. Has a throughput of 10Hz (i.e 1 instruction processed every 0.1 seconds).

Plus of course the general thermo and neatness benefits in all of them. And you don't have the limiting factor of chaining them through mechanical parts if outside of the circuit device, which would need to be explained to the players, without really explaining why...

I don't use this logic stuff, but I always have a lot of problems (I still haven't done my first proper level since day 1), so if this stuff can help, and so it seems, I'm with it.

dcf, I'm in total agreement with this concept.

Another thing to consider is efficient use of one's time, which the concept would provide this benefit. Any concept that makes sense, and could save the creator some time, is a neccessity in my book. We already spend months on levels, with no compensation other than a rating, heart, positive comment, or token recognition.

Regarding timing, I see the increments as being a major obstacle. Presently we can go from .1s to .2s, and so on, as you stated, but there have been personal applications where I needed to go from .1s to .11s, and being unable to do so prevented me from implementing what I truly desired. I believe an increase in resolution is a neccessity as well, even if the fastest time is .1s. 10ms increments in timing would go far to resolve a lot of timing issues.

Rick

out of curiousity Rick, what was the application where 0.01s increments were vital?

I'm not doubting you had one, but I was working on the basis that any synchronous system will theoretically work at any clock speed, the only real issue to LBP is how fast it goes and thus affects the user. On this basis I can't see an application for 0.01s timings because we can't see things happen that fast! If you have an example that blows my whole theory out of the water then it would be good to hear (for some reason I actully like to be proven wrong :p)

Quote:

---

Originally Posted by rtm223

out of curiousity Rick, what was the application where 0.01s increments were vital?

I'm not doubting you had one, but I was working on the basis that any synchronous system will theoretically work at any clock speed, the only real issue to LBP is how fast it goes and thus affects the user. On this basis I can't see an application for 0.01s timings because we can't see things happen that fast! If you have an example that blows my whole theory out of the water then it would be good to hear (for some reason I actully like to be proven wrong :p)

---

Hi rtm223:). I'm referring to the Plasma Generator I designed for my level Takken. Initially I wanted to emit 100 Plasma rings with lifespans of .05s, spaced 10ms apart with 1 ring dissapearing in a specified location and the next appearing 10ms later and placed slightly above the previous ring. So, each emitted ring (or object) would overlap a space previously occupied by an object. I tried this with .1s intervals, but the net result did not have the fluidity I preferred and it significantly increased the amount of time it took to complete 1 full cycle. I resorted to decreasing the number of rings emitted to 10, and using .2s intervals. I guess this would be an acceptable compromise for most, but it's not what I wanted.

Using some analogies for clarity:
1. If I were to create a wave effect for a level that had water, my desire would be for the movement to appear as fluid-like as possible (near perfection, seamless to the eye), which cannot be accomplished with the present timimg limitations.
2. Also, consider the default refresh rate of a typical monitor, which is 60 cycles per second, and compare that to a refresh rate of 10 cycles per second. At 10 cycles per second, the brain is capable of seeing the scan lines as the image is refreshed, and the difference between the two refresh rates is very noticeable.

Rick

Hey Rick, just wanted to point something out... the human eye can only see a "refresh rate" of about 24/second. Granted, 10 is still nowhere near 24, but they could do well with even a .05 interval, instead of a .01 interval

Quote:

---

Originally Posted by comphermc

Hey Rick, just wanted to point something out... the human eye can only see a "refresh rate" of about 24/second. Granted, 10 is still nowhere near 24, but they could do well with even a .05 interval, instead of a .01 interval

---

The human eye can pick up delays on the order of ms (1/1000th). 24 is the number from video that is sufficient to create the illusion of continuous movement. Human eyes can however tell that there is a delay between, let's say, you press R1 to grab a grab switch and the mechanism engages 1/10th of a second later.

Quote:

---

Originally Posted by comphermc

Hey Rick, just wanted to point something out... the human eye can only see a "refresh rate" of about 24/second. Granted, 10 is still nowhere near 24, but they could do well with even a .05 interval, instead of a .01 interval

---

24 is definitely better than 10 comphermc.:)

In my earlier post above, I was taking into consideration the optic nerve being capable of transferring data at a rate of 7Mbits per second, and the brain having the capability of processing a full image in 34ms. The brain will also divert processing power to scrutinize image anomalies, which results in a significantly higher processing rate, as the non-critical data is discarded. Obviously this rate will vary, as it is dependent on the amount of data representing the anomaly. In our case, the anomaly could be a transient spectral spike or spectral void.

So, in my humble opinion:blush:, any change in timing resolution should be at least 1 order of magnitude, to ensure a more seamless effect. I guess that mindset has been instilled over many years of designing products that exceed a customer's specification--erroring on the side of caution so to speak.

Rick

Makes sense to err on the side of caution. I agree that being able to further tweak timing would be nice, but I don't see MM working on a patch for this.

Related: would allowing a .01 second timing interval slow the system down? It seems like there are enough things to process as it is without having to refresh at ten times the rate. I'm no computer/programming expert, so I'm grabbing in the dark here. I do understand that if you decrease the time step, then the game would have to run the iteration to check for logic/triggers at ten times the current rate. Would this cause a lag or slowdown, or are these iterations so minuscule by comparison to all the other calculations going on?

Edit: let me guess...Engineer?
Edit2: Your public profile tells me so. It appears that we share a few interests, although I'm no Engineer. I was studying Engineering for a while, but switched to just plain Math and Physics...teaching, ftw.

A very good question comphermc!

Since I didn't write the code, I can't give a definitve answer, and would be speculating.

However, I can say a common programming practice, used to avoid such issues, is the use of a technique referred to as multi-threading. I'm 99.5% confident Mm's Programmers used this technique, as it is a standard.

In basic terms, each thread performs a specific action/actions for a designated period of time, then it relinquishes control to the next thread in the queue. The time that a thread is waiting is referred to as Sleep time. Since Sleep times are determined by a thread's priority ranking for a given action, Sleep times can be adjusted to optimize an application's performance.

Rick

Rick, so you are looking at an increase in sychronisation for the entire system. Effectively speeding up the heartbeat of the LBP engine by a factor of 10. Fair enough, I can see many visual applications that would benefit from this. With regards to DCFs example of a grabswitch delay being visible... It's true, I can't argue with the fact. I just can't think of any time when the individual 0.1s delays on switches etc ruin gameplay, you kinda have to be looking out for it to notice that IMO. But maybe thats just me?


Yeah, so most of this post is a big ramble that isn't gonna interest most people, so I thought I would summarise it :) Feel free to skip to the end to get the jist


The following is largely based upon speculation, Not having access to MMs code and bearing in mind I'm used to different achitectures and OS than the PS3. I've made about 20 assumptions / guesses below and you know what they say about assumptions :p

We currently see the phsics engine lag under certain situations (even if we discount network lag), so the engine is struggling. Upping the heartbeat by x10 would multiply the procesor overhead would need to increase greatly. Imagine 10x as many emitter collision calculations, magswitches, proxswitches, etc in your level and what that might do to your thermo. I'd also imagine that collision detection would be upped, based upon the fact that if you are going fast enough that you can go through walls (the movement of my ordered inputs tool relies on being synced with the 10Hz heartbeat else it does just that). My guess is that a large amount of the engine is synced into the 0.1s heartbeat, and it's mostly the visuals that aren't. That's a fair bit more processor overhead to find in a system that is already struggling, and that will result in a direct hit on thermo.

Not to mention breaking existing levels - if you have a piston timer, that triggers after 0.6s and then they up the heartbeat. You might find that it now triggers a 0.52s. Not much of a deal unless you've synced stuff along the way and now it's all out of sync with each other.

But, ignore the last point and assume its a purely processing issue. I'd say with 100% confidence LBP is multithreaded, an app like this would be rediculous to write without, and it's a multi-core system with the cores all working together, so it would need to be. It's still lagging under certain conditions though, so an increase in calculations could not be saved by something that already exists.

What could be done is to increase the CPU useage. I think I read somewhere that Uncharted 2 was going to be the first game to use all 6 cores. This implies that LBP doesn't... So the game could be enhanced to utilise the full processing power of the Cell. Would this be an easy change? I don't know. It could be a simple as setting some register bits and letting the scheduler do it's thing, but I very much doubt it. It would probably be a major effort to re-optimise it to 6 cores.

Also, Multiprocessing does give a perfomance increase but scheduling and sychronisation overheads are also significant so it doesn't give you as much as you might think. If I recall correctly the jump from 1 to 2 cores gives around a 70% increase in performance, but once you take the step from 8-16 you can actually lose performance, even if the application is optimised.

-------------------------------

Summary
Basically, I'm not against the idea of increasing the heartbeat, but it's another thing that would be nice but may well not be practical. In simple terms, the computational overhead on a system that already struggles would be increased and that surplus would need to be found from somewhere. Now I think that might be possible but it's probably a big old job to restructure the engine for it. If not you are looking at a reduction in total thermo available.

And I can think of common examples where the upping of a heartbeat could break existing levels. Timed systems could take a massive hit, and MM have taken pains so far to not break existing levels (not always successful, but they have tried). All the glitched materials etc. still work - they didn't have to do that, but they did to stop people's levels from breaking.

I like the idea of being able to not have a delay if one doesn't want it for the grab switch activating an attack mechanism. So unless a delay is needed, such as when hooking multiple of these things together, I'd like to see it avoided if at all possible.

In this particular suggestion, for logic switches, I'm going to suggest the delay tool works in 0.1 second increments, like the rest of LBP.

I think RickRock_777 should make an additional suggestion for some sort of video tool. A video tool could create essentially a video screen on a flat layer that could operate much faster than everything else. This would be because the physics never change, only the visual. The video screen would be the object as far as the physics engine is concerned and it would operate at the same frequency as everything else. The image on the screen could change. 3D stickers already work this way. They move about without appearing to jerk and they can even be placed on moving objects. True, there is a glitch if you put too many close together but still. I think a tool that is a video screen that essentially lets you load a bunch of stickers into it and let it play during the level, changing pictures at whatever interval you set from 30 times a second (LBPs visual speed) to a slide show that switches every several seconds. This could be a very useful and cool tool for creators!

However, I'm going to suggest this goes to another thread. Logic is intimidating enough for some people without the addition of these technical discussions! I'd like people who see the suggestion and read the thread get the feeling that this is something they can do, even if they have no background in computers!

Quote:

---

Originally Posted by dcf

In this particular suggestion, for logic switches, I'm going to suggest the delay tool works in 0.1 second increments, like the rest of LBP.

I think RickRock_777 should make an additional suggestion for some sort of video tool.

---

Forgive me dcf...apparently I misunderstood your intent when you mentioned the .1s delay being noticeable, and assumed you were looking for improved resolution with the implementation of more complex logic gates.

Rick

This is a good thread. This would save me time AND thermo. Enough said.

Quote:

---

Originally Posted by DrunkenFist_Lee

This is a good thread. This would save me time AND thermo. Enough said.

---

That's the basic idea :)

I didn't bother reading much of the first post but i think the OR/AND/XOR switches are a great idea, and although i didn't really understand it the circuit board would be a great alternative to having a load of dark matter floating around :p

I'll read through it properly at another time, i'm a bit tired at the moment :)