Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Untelligent]

Apparently the Minecraft guy finished his 16-bit one last week.

You know what this means. We have to upgrade to 32-bit to one-up him.

[Asmageddon]

Unfortunately this won't be possible - Minecraft has much larger maps, materials designed specifically for stuff like this, while in DF we'd have to use something else, which would probably be very CPU-intensive.
Even building a 16bit computer would be very hard, and even then, it would run too slow to be even amusing.

[Jeoshua]

Problem here is, one 32-bit number, represented as a fluid logic array, would take 32x2+1=65 tiles, assuming the need for separation between each channel.  So that's over 1 1/2 region tiles just for one integer.

So yeah, I don't think that's going to happen.  Not unless you want to use a 16x16 embark to try and make it, and can handle a site with at least 100 layers: all computer.

[Chessrook44]

So yeah, I don't think that's going to happen.  Not unless you want to use a 16x16 embark to try and make it, and can handle a site with at least 100 layers: all computer.

Dude.  We're dwarves.  This is Dwarf Fortress.  Ridiculously huge and pointless is our bread.

Magma's the butter.

[dree12]

The only way we can get remotely close is to either:
a) Abandon binary in fluid logic;
b) Use more space-efficient animal logic.

Unfortunately, non-binary fluid logic is so far impossible. Animal logic is so far unreliable.

[expwnent]

The minecraft guy just made an ALU. The dwarf fortress guy made a full (virtual) computer.

[Untelligent]

A while back it was just the ALU, but he finished it recently.

[abadidea]

Technically, we only need a 17-bit computer to 1-up him  Although I would be quite content with an 8-bit cpu plus gpu, or ppu (picture processing unit) as they were called in the days of yore.

Untelligent, off-topic but I think you would like this picture my little brother drew. http://kasek.deviantart.com/gallery/#/d340yq2

[NW_Kohaku]

Well, what if we removed the caverns, HFS, and maybe even the magma sea, and just made the whole embark only be 20 to 30 z-levels tall of straight stone, and whatever the minimum z-levels above is?  (Might need to embark at least partially on an aquifer for reliable water.)

Then you could have an exceptionally broad embark without hitting memory caps.

Or you could stack multiple floors of fluid logic.

[Lav]

Unfortunately, non-binary fluid logic is so far impossible.

Are you sure? I was experimenting with non-binary fluid logic in 40d days, and even though I didn't complete my experiments at that time, I still think my experiments had solid theoretical backup.

The idea was to generate water "signals" ranging from 2/7 to 7/7. Those signals would then travel along the "bus" until they hit one of the processing units. The bus is just a sequence of water pumps sending the signal forward at high speed. A processing unit is a branch from the bus, and the on/off state of the processing unit is determined by the state of the next water pump in bus queue and the state of the water pump which is extracting the signal from the bus. When the bus pump is ON and unit pump is OFF, then the processing unit is not active.

Only one processing unit is active at any given time, which determines the state of the machine in general.

Once in the processing unit, the signal travels at lower speed through the sequence of pressure plates, activating first at 2/7 water, then at 3/7 water, and so on until 7/7 water. Thus the processing unit is able to differentiate 6 different signals and switch the entire system into the corresponding next state. The water is then discarded. Note that the processing unit is de-facto yet another shorter bus.

Important note: while the bus operates at high speed, the processing unit (including the pump extracting the signal from the bus) is operating on fixed frequency. Thus the detectors (fine-tuned pressure pumps) have enough time to get the signal from the unit bus.

In brief, the signal lifetime is as follows:

1. Signal is generated at Signal Generator and stored in the Buffer. At any given time the Buffer is storing a number of 2/7, 3/7 etc signals ready to be sent into the Main Bus.

2. Once the machine is switched to the next state, appropriate signal is released from the Buffer into the Main Bus. It then travels along the bus at high speed until it hits the pump which is deactivated (i.e. it reaches the Processing Unit which is currently active).

3. On the next repeater tick, the signal is extracted from the Main Bus by the Extractor Pump and sent into the Unit Bus.

4. The signal then travels along the Unit Bus at lower speed (as Unit Bus pumps are controlled by a repeater) until it hits the pressure plate matching the signal value. The Detector pump is immediately activated and removes the signal from the Unit Bus.

5. Once removed from the Unit Bus, the signal hits the final pressure plate, which is switching the entire machine into the next logical state and tells the Signal Generator to send the next signal into the Main Bus.

Brief schematics:

  (bus)
<<*<<*<<*<<*<<   (from signal generator)
     V
     V
     2>>
     V
     V      (processing unit)
     3>>
     V
     V
     4>>
     V
     V
     5>>
     V
     V
     6>>
     V
     V
     7>>

Legend:
* is just a pit-stop in the Main Bus.
>> denotes pumps.
2-7 denote fine-tuned pressure plates.

East-to-west pumps are the Main Bus. Top north-to-south pump is the Signal Extractor, the rest are the Unit Bus. West-to-east pumps with matching pressure plates are Signal Detectors. Further logic is not displayed.