If I'm getting this right, you can store several bits of information in this circuit then access them later in the same order?
It's actually random access, so you select an address (1-4) and it outputs whatever is stored there. You can also write to that address. The order doesn't matter at all, so it behaves just like regular memory.
I've been experimenting with repeaters lately and came up with a way to read from and write to delay line memory that might prove useful for shrinking RAM modules. It works by using a clock that pulses once per memory cycle (one cycle is the time it takes for the data in memory to go around the loop once) and changing the phase of that pulse to select individual data bits in storage. This is hooked up to an input mechanism that changes the bit at the selected location to reflect the input data (if the input clock is enabled) and a D-latch to store the read data to keep the output from pulsing.
(The phase selector and address lines are flipped in the schematic because I wanted them on the other side when I built it.)
This model stores 4 bits using 3 repeaters and one repeater/torch combination unit (purple) that allows bits to be turned off. The clock on the back of the phase selector uses the same configuration of repeaters (including the repeater/torch unit) to make sure the timing is the same. The phase selector is just a 2-bit mux that selects from 4 lines with the output from each stage of the clock on each line. The clock needs to be started manually by placing a torch and quickly destroying it, but a one-time starter shouldn't be hard to construct.
This is just a proof-of-concept, so I haven't spent any time trying to shrink it further. It should be possible to use one clock with 8 data storage units to give an 8 bit word size, or even more if necessary. Storage units can be stacked vertically, maybe even on top of the clock if there's a better way to arrange them. The biggest space savings over traditional memory is with the clock/data loops using repeaters, since adding extra storage is only a matter of adding another repeater to each loop.
The only major problem with this design seems to be with the size of the phase selector. I haven't found a smaller way to construct it, and relying on a large multiplexer for address selection is going to be a problem for configurations with more than 4 bits per line.
If anyone has ideas for shrinking that or any other part of this design let me know. Input is also welcome on any other ways this design can be improved, or on whether there are better ways to store data that still allow for random access.
(If you have an ueber-compact RAM design, PLEASE share it!), I'll finish the computer with as much RAM/ROM as I can hold in the loaded chunks.
I built this 16-byte SRAM module a while ago, but it's not very easy to construct or stack. I don't think there are any really practical ways to build RAM modules yet. They're all huge and really slow. Maybe something clever can be done with repeaters, since those weren't around when I was working on that.
Here is the smallest D-latch I've seen. I haven't had a chance to try anything with repeaters there either, so something smaller might be possible.
edit: the finished is precisely 17wx100Lx24h includes EVERYTHING, nothing is outside of the dimensions
Chaining 64 of these 1-bit full adders side-by-side gives a total volume of (64*(5+1))*6*3 = 6,912 blocks. Yours is 17*100*24 = 40,800 blocks, nearly 6x larger. It's an impressive build, but this is definitely not the smallest.
Here's a slanted 7-segment display I came up with. Not sure if anyone has done it this way before, but it isn't as wide and saves some vertical height and doesn't require as much redstone as other designs to look good. It looks pretty bad from the ground though, so ideally it should be below your viewing platform. The wiring in the back is a mess as I haven't had much time to try other ways to do it.
This doesn't make sense. People who copy the game are always going to have an easier time playing it than legitimate users whenever copy protection is implemented. It's been demonstrated a hundred times over with SecuROM and every other copy protection scheme out there. Customers are the only ones who end up being inconvenienced here, and the people who copy the game, those who wouldn't have purchased the game anyway, will continue to do so with little interference.
The only thing that should be required to determine that the user is a paying customer is having a valid login. If the user logs in from a second location just close the first session. That's how other games do it, and it keeps from having to show nag messages or stalk users by IP address (which really sucks if multiple users are behind NAT, for example) or other means.
With the 1.5_01 update Minecraft has been using 100% CPU and getting what I assume is ~1-2 FPS on the menu screen (no F3 stats there). The whole interface lags and world creation takes 2-3 minutes. I didn't have these problems with the last update and was getting about 30 FPS in-game. Playing around with the graphics settings didn't help at all, and neither did reinstalling Minecraft.
My specs aren't great and I know people here are quick to blame the computer rather than the game itself, but something definitely broke this time around. Unfortunately this doesn't seem to affect many people, and I'm wondering if anyone has found a workaround. Anyone else having this problem?
Edit: Restarting Chrome mysteriously fixed the problem, even though I don't even have Java enabled in Chrome and have never played the game in the browser. Can't imagine why that fixed it.
Schematic: Download (sorry about MediaFire, Megaupload has decided not to work for me and tinyupload is down)
Capacity: 16 bytes (16 8-bit words)
Final size: 87x40x13 (only two little wires stick up on the top layer, I couldn't find anywhere else to put them :/)
Redstone cost: 5296 wire, 2428 torches, 7723 ore
Performance is much better than before but not as good as I'd hoped. It takes 4 ticks to write data successfully (sets can be done in 2 ticks, but resets take longer). The R/W bit has to be high for 4 ticks to allow the data and clock signals to propagate. The data also cannot change for one tick after the R/W bit is turned off, otherwise it puts the cells at whatever address is selected into an indeterminate state. That's probably confusing, so this graph may help explain it better:
It doesn't matter what the data is set to for that one tick right after the R/W bit is set. Since these are one tick out of phase it's a little hard to control them with another circuit though, so realistically it probably takes 6 ticks to write if you can coordinate the signals properly. In the schematic I had to add 4 sets of torches to the input lines to add the necessary delay to get it to arrive at the same time as the clock signal, but nothing can be done about that 1 tick without resorting to the N/S trick.
It takes something like 21 ticks for the data to propagate back to the output from the beginning of the write cycle. That's not terrible, but it's not impressive either.
Addressing takes ~12 ticks.
I think I'm going to take a break from this for a while. The latency for these things seems like it's always going to be too high and I'm starting to think that getting access times under 1 second in-game is probably unrealistic.
Performance tends to be one of the last things you worry about when writing a game (within reason).
Not trying to be a troll or something, I am a flash game developer and one thing I learn from programmers around me (which none as cool as Notch I'm afraid) is neglecting optimization often cause terrible or even unfix-able problems at the end. Including having to remove certain features after they been made, because the features have been wrote in worst way.
It's one thing to choose sane algorithms and another to do low-level profiling and optimization. The latter is generally what people refer to when talking about optimization, and the former should be a consideration made during the development process (as you said). The specific problem people are having (I'm assuming this is with the lighting... if there are other things going on I'm not aware of them, but that's the main problem I'm having) seems like an algorithm issue more than anything else, which is why it should be handled sooner rather than later.
I'm going to say CPU is the primary factor with the performance problems most people are having. That's not Java's fault either. Before the Halloween update I'd regularly get 90+ FPS on my hardware, but ever since that near-infinite loop lighting bug was introduced (with the Halloween update) performance has been terrible. People with faster processors can get through the ridiculous number of loops the lighting code is doing faster, but everyone else suffers. I've noticed that every time the game is stuttering and getting really low FPS the red bar (CPU, I'm guessing) is all the way to the top in the F3 screen.
So the game is the problem. That's not because of Java or the graphics (it was fine before and nothing particularly graphics-intensive has been added) it's just due to the code being seriously inefficient. Hopefully this gets a lot better soon, because as it stands dropping to 9-10 FPS during every sunrise and sunset is really obnoxious.
Quote from rosedragon »
I wonder why I don't see optimizing performance on Notch's checklist :/ .
Performance tends to be one of the last things you worry about when writing a game (within reason). I would say that the latest performance issues are caused by this specific bug though (or some other bug introduced with the Halloween patch), and should really be fixed soon because they're making the game nearly unplayable at times. I guess Notch doesn't notice because so many people have computers fast enough to handle it and people tend to blame their hardware.
Here's a preview of the full 16-byte unit I've been working on based on the new design with the improvements I mentioned in my last post. Everything seems to be working much faster than the original design, but it's a little larger at ~90x40x13. I'm going to profile it before going any further. Since it uses trees for the clock, data, and addressing it should be possible to dump operations in the pipeline without interfering with each other as long as there's a minimum amount of delay between them which I have yet to measure.
This is also built to use a bidirectional I/O bus. To my knowledge none exist yet, but there are some bidirectional repeaters that work in-game but not in the simulator and I'm hoping that with a simulator update it'll be possible to get a bidirectional bus set up. If it's not possible then the internal input and output sections can be split up so I won't have to significantly change the design.
Anyway, here it is. Sorry for the GIF, I'll have a full diagram up after I profile.
Bottom level: Clock tree
Ground level: Address input (left, 4 wide), I/O lines (center, 8 wide), internal input lines are below, output above, R/W signal (9th line to the right of I/O)
Top level: Address decoder
Is it the position or the orientation of the boat that actually matters? Mine always seemed to work for a few trips and suddenly I'd fall through the boat every time. Is this because I'm moving into/away from the SW corner to go up and down? Is it better to just move along one axis?
I've tried pretty much every positioning trick mentioned in this thread and they all work for a few minutes and never work again until I make a new boat.
That's really cool. I'm surprised that the cart goes in just the right place every time (I couldn't come up with a way to do that other than dropping it from the top), but I guess the door booster helps with that. Animals will probably wreck it though, so some fences might be in order.
I'm tempted to build this but I'm still dealing with falling out of the bottom of the boat most of the time.
0
It's actually random access, so you select an address (1-4) and it outputs whatever is stored there. You can also write to that address. The order doesn't matter at all, so it behaves just like regular memory.
0
(The phase selector and address lines are flipped in the schematic because I wanted them on the other side when I built it.)
This model stores 4 bits using 3 repeaters and one repeater/torch combination unit (purple) that allows bits to be turned off. The clock on the back of the phase selector uses the same configuration of repeaters (including the repeater/torch unit) to make sure the timing is the same. The phase selector is just a 2-bit mux that selects from 4 lines with the output from each stage of the clock on each line. The clock needs to be started manually by placing a torch and quickly destroying it, but a one-time starter shouldn't be hard to construct.
This is just a proof-of-concept, so I haven't spent any time trying to shrink it further. It should be possible to use one clock with 8 data storage units to give an 8 bit word size, or even more if necessary. Storage units can be stacked vertically, maybe even on top of the clock if there's a better way to arrange them. The biggest space savings over traditional memory is with the clock/data loops using repeaters, since adding extra storage is only a matter of adding another repeater to each loop.
The only major problem with this design seems to be with the size of the phase selector. I haven't found a smaller way to construct it, and relying on a large multiplexer for address selection is going to be a problem for configurations with more than 4 bits per line.
If anyone has ideas for shrinking that or any other part of this design let me know. Input is also welcome on any other ways this design can be improved, or on whether there are better ways to store data that still allow for random access.
0
I built this 16-byte SRAM module a while ago, but it's not very easy to construct or stack. I don't think there are any really practical ways to build RAM modules yet. They're all huge and really slow. Maybe something clever can be done with repeaters, since those weren't around when I was working on that.
Here is the smallest D-latch I've seen. I haven't had a chance to try anything with repeaters there either, so something smaller might be possible.
There's also a vertical D-latch design:
0
Chaining 64 of these 1-bit full adders side-by-side gives a total volume of (64*(5+1))*6*3 = 6,912 blocks. Yours is 17*100*24 = 40,800 blocks, nearly 6x larger. It's an impressive build, but this is definitely not the smallest.
0
0
It's actually not, because legally speaking copyright infringement is not theft. And for what it's worth, the law doesn't reflect an unquestionable view of morality.
1
The only thing that should be required to determine that the user is a paying customer is having a valid login. If the user logs in from a second location just close the first session. That's how other games do it, and it keeps from having to show nag messages or stalk users by IP address (which really sucks if multiple users are behind NAT, for example) or other means.
0
My specs aren't great and I know people here are quick to blame the computer rather than the game itself, but something definitely broke this time around. Unfortunately this doesn't seem to affect many people, and I'm wondering if anyone has found a workaround. Anyone else having this problem?
Edit: Restarting Chrome mysteriously fixed the problem, even though I don't even have Java enabled in Chrome and have never played the game in the browser. Can't imagine why that fixed it.
0
Use a T flip-flop. There are a couple designs in the wiki and a number of better ones in the old thread.
0
Schematic: Download (sorry about MediaFire, Megaupload has decided not to work for me and tinyupload is down)
Capacity: 16 bytes (16 8-bit words)
Final size: 87x40x13 (only two little wires stick up on the top layer, I couldn't find anywhere else to put them :/)
Redstone cost: 5296 wire, 2428 torches, 7723 ore
Performance is much better than before but not as good as I'd hoped. It takes 4 ticks to write data successfully (sets can be done in 2 ticks, but resets take longer). The R/W bit has to be high for 4 ticks to allow the data and clock signals to propagate. The data also cannot change for one tick after the R/W bit is turned off, otherwise it puts the cells at whatever address is selected into an indeterminate state. That's probably confusing, so this graph may help explain it better:
It doesn't matter what the data is set to for that one tick right after the R/W bit is set. Since these are one tick out of phase it's a little hard to control them with another circuit though, so realistically it probably takes 6 ticks to write if you can coordinate the signals properly. In the schematic I had to add 4 sets of torches to the input lines to add the necessary delay to get it to arrive at the same time as the clock signal, but nothing can be done about that 1 tick without resorting to the N/S trick.
It takes something like 21 ticks for the data to propagate back to the output from the beginning of the write cycle. That's not terrible, but it's not impressive either.
Addressing takes ~12 ticks.
I think I'm going to take a break from this for a while. The latency for these things seems like it's always going to be too high and I'm starting to think that getting access times under 1 second in-game is probably unrealistic.
0
It's one thing to choose sane algorithms and another to do low-level profiling and optimization. The latter is generally what people refer to when talking about optimization, and the former should be a consideration made during the development process (as you said). The specific problem people are having (I'm assuming this is with the lighting... if there are other things going on I'm not aware of them, but that's the main problem I'm having) seems like an algorithm issue more than anything else, which is why it should be handled sooner rather than later.
0
So the game is the problem. That's not because of Java or the graphics (it was fine before and nothing particularly graphics-intensive has been added) it's just due to the code being seriously inefficient. Hopefully this gets a lot better soon, because as it stands dropping to 9-10 FPS during every sunrise and sunset is really obnoxious.
Performance tends to be one of the last things you worry about when writing a game (within reason). I would say that the latest performance issues are caused by this specific bug though (or some other bug introduced with the Halloween patch), and should really be fixed soon because they're making the game nearly unplayable at times. I guess Notch doesn't notice because so many people have computers fast enough to handle it and people tend to blame their hardware.
0
This is also built to use a bidirectional I/O bus. To my knowledge none exist yet, but there are some bidirectional repeaters that work in-game but not in the simulator and I'm hoping that with a simulator update it'll be possible to get a bidirectional bus set up. If it's not possible then the internal input and output sections can be split up so I won't have to significantly change the design.
Anyway, here it is. Sorry for the GIF, I'll have a full diagram up after I profile.
Bottom level: Clock tree
Ground level: Address input (left, 4 wide), I/O lines (center, 8 wide), internal input lines are below, output above, R/W signal (9th line to the right of I/O)
Top level: Address decoder
0
I've tried pretty much every positioning trick mentioned in this thread and they all work for a few minutes and never work again until I make a new boat.
0
I'm tempted to build this but I'm still dealing with falling out of the bottom of the boat most of the time.