Bay 12 Games Forum

Checking out minecart logic today (which I'm wholly unfamiliar with, btw) and I'm seeing a memory section, followed by a power-to-signal section containing multiple designs.

Aren't all examples of PTS also examples of memory, via toggling gears?  I don't just mean for just minecart logic, but always.

Lacking a little confidence, because I've been known to get things incredibly wrong in the past, lol, hoping somebody will agree with me or explain why I'm wrong.  Anticipating making some changes to that page, adding what logic gates I can find and understand, but also getting rid of some of the redundancy.

Yeah, forgot you need the slopes penetrating the z-level below-- leaves you with a space that's hard to use for computing.

Still, I can't imagine Jong's really at 10 tiles/bit?


 ##
 .#
 %#
 %#
 .#

Even reusing walls, that's 10 tiles per z-level per bit, with another z-level necessary below, then a third z-level scattered with reservoir pockets...  Not to mention space required by addressing, power transfer, power....  You do realize that all of those memory cells need multiple z-levels per bit, right?  I think you have Jong beat for space requirements.

I've endeavoured to delve into the foundations of this kind of powerless minecart signal processing on my wiki user page - http://dwarffortresswiki.org/index.php/User:Larix/MPL but that'd be a very long read and much of it is probably either too basic to warrant explanation, too byzanthine to warrant talking about or too clumsily worded to be understandable (or a combination of those three). It absolutely doesn't help that i have no prior computing education, and i don't mean the "i only know how to program in visual basic lol" 'uneducated'; i barely know that a thing named Visual Basic exists and it took me until today to even understand what the various steps in Jong's testing program actually did and what the hell the PC and IR and whatnot in there actually are.

It's really funny-- I'm looking at your user page right now, and I basically worked along the same path as you, but for creature logic (http://dwarffortresswiki.org/index.php/User:vasiln if you want to read my own basic and byzanthine explorations of DF computing, lol).

Super, totally mind-blowing, because like you, I've never really studied computers, and it was always kind of a mystery to me how they went from "here's an xor circuit" to "here's photoshop, tada!"  Creating addressable memory, an adder, (bit shift, conditional jump, etc), I started to see exactly how these things translate to useful, real world stuff.

I'll check it out in more depth later-- kind of hanging out since I see a big new release is coming, but don't really want to fire up DF until then.  Got your user page open though, see if I can puzzle any of it out lol

That's amazing.

Are you doing more?  Do you have an instruction set planned?  I love this stuff.

I'm seeing fewer than 15 tiles per bit.  Is Jong's really twice as compact as that?  Never looked at his map, but wasn't he using over-under water pump cells?  That should come to 16ish tiles per bit.  And addressing should add another 8ish: two z-levels full of pumps, and one z-level full of gears.

How slow is it running?  It sounds like it should be doing 400-tick instructions, getting everything read or written inside the space of a resetting bridge-- is that right?  Doesn't strike me as slow in the least.  Of course, it's hard to compete with the ease and speed of addressable memory via gear grid.

I have to admit, it's very difficult to work out what's going on (especially since I'm not a minecarter yet).  Do you happen to have, say, two bits of addressable memory someplace?  Working along the same principles?  Less to get confused by.  For instance, was trying to see how scalable it would be, but can't find the doors.

Check out http://www.bay12forums.com/smf/index.php?topic=103682.msg3064909#msg3064909, should answer your questions, includes diagrams

Seconding Tevish.  Give a dwarf a barrel, he drinks for a day.  Teach him how to brew...

Designing a panic room is really very similar to your first steps of settling a new area.  The priorities are the same.  So deciding how to stock it is easy-- just stock it with whatever you need for new embarks.

A walled off section of cavern is the best place for a saferoom, because it has good soil, and likely the potential for some silk.  Make it as big as possible (for trees, mostly), then leave a pick, an anvil, and an axe in there.  Even if it's deep, it's not really far from the surface-- just ten or twenty steps up a staircase.

Don't build or dig too close to it.  The design is such that if your panic-room dwarves need more stone, they dig for it.  If they need more food or booze, they grow it.  If they need more wood, they chop it down.  If there are spare dwarves and they need more cavern, they build an airlock and try to claim some of it.  The idea isn't that the panic-room dwarves have everything they need-- it's that they have the capability to build everything they need.  Just like starting a new fortress.

If you want to go from there, a safe water source is a priority, and not too difficult to set up, not in most caverns.  A little bit of stockpiled (and probably forbidden) food is a good idea.  As many slabs as possible are a good idea.  Moody dwarf traps aren't a bad idea, but they're not necessary.  If there's more than one dwarf in your panic room, though, all you have to do is get that dwarf to build a workshop that can be walled off, and if there's only one, you don't really have to worry about it anyways.

All your panic room dwarves have to do is eat, drink, and not go crazy.  Anything else-- danger room training, armor, workshops-- they can build as they see fit.  If you want greater survivability, you can get it by having a larger number of panic rooms, with independent populations.

Usually, if a fortress is close to falling, the outside is no longer safe, but in certain circumstances (say, drawbridged single entrance, and you fall to a misjudged deep dig), migrants can be very survivable, since they don't really know or care about any of the dying inhabitants.  It's not a bad idea to make a panic room accessible from the map edge.  There are Roach Hotel designs (dwarves get in, but they don't get out) that can make these useful even if the outside is very dangerous.  Civs trigger pressure plates can be very handy.

The best thing to do, of course, is to think ahead, and have those panic rooms staffed by dwarves who have never met any of the other fortress inhabitants.  That gives you a good head-start on the happiness problem.  The only major concern besides happiness, food, and drink is ghosts.

There have been a few code changes since 2011

You should always feel free to edit the wiki.

There's probably a little bit of posturing around ASCII   And probably an exaggerated perception of that posturing, as well.

Nobody really minds if you use a tileset.  There's a strong culture around DF that the graphics aren't important, and that drives a little bit of "Tilesets are for wussies!" but I think it's all in good fun.  I don't think there are any official numbers about the number of people that use a tileset vs the number of people that don't, but it's not like either is particularly uncommon.

The thing to me is that it's really difficult to understand screen shots and diagrams if they use a tileset with which one is unfamiliar.  It's almost like these forums are multi-lingual, with pics cropping up in multiple tilesets, and ASCII playing the same kind of role that English does.  If you want people to understand your screenshots, using ASCII is probably a safe bet, and if you want to understand the most screenshots, familiarity with ASCII is probably the most important.

I'd risk taking a no-caves embark just for the pure ability to make the computer. How would one calculate said floating point integers?

I mean, for the first go, pong wouldn't even have to be playable. I imagine just a grid of hatches, opening to a pit of water to show pixels; blue would be white and whatever other colour would be black in this case. How would I make the computer track the positions of the ball so it could match the paddles, and calculate the movement of the ball?

I really haven't the faintest how to make a floating point unit   I bet if you looked on wikipedia, the info is out there.  Probably take some work to wade through.

If I'm not mistaken, earliest pong implementations weren't floating point anyways.  Movement along the x axis was at a constant speed, and various y speeds were allowed as well.  So when it was moving diagonally, it moved faster.

So something like this would keep track of paddle1_y, paddle2_y, ball_y, ball_x, ball_delta_y, and a few constants, including ball_delta_x (although really I guess it's a variable, because it can be plus or minus).  Every frame, you check:

1) Is ball at x=0 or at x=max?  If so, check ball_y-- is it within a range represented by the position of the paddle, plus or minus the width of the paddle?  If not, somebody loses; if so, then delta x becomes equal to negative delta x (1 - delta x).  You probably want to modify delta y by some value based on distance from center of paddle, or paddle position minus paddle position last frame, or something like that, to keep the ball moving interestingly.

2) Next, ball position x becomes equal to ball position + delta x, and same goes for y.  Write a 0 to graphics memory at old ball position (writable memory linked to your output hatches, tells the hatch to close).  Write a 1 to graphics memory at new position.

3) If ball y position is 0 or -1 (top or bottom), ball delta y becomes equal to negative ball delta y.

4) Get input for paddles.  (AI is probably right out for first iteration; I imagine a set of 4 levers, up/down for each paddle, which isn't really a big deal since a frame will take about a week).  Input is 2 bits: up, down, or nothing.

5) Write a 0 to graphics memory for old paddle positions.  Calculate new paddle positions (just paddle position plus or minus one).  Write a 1 to graphics at new paddle position.  An increment should function fast enough to minimize flickering, otherwise, you need clock cycles devoted to "if paddle_last_frame and not paddle_this_frame then write 0 to graphics bit" which slows down each frame a lot.  Or you need a frame buffer, which means twice as many graphics bits, and would probably lead to flickering anyways.  I recommend just accepting the flicker.

5) If game lost, increment winner's score (I'm assuming you don't need output of this), ball delta y gets modified somehow to keep things interesting, ball position x and position y moved to center of screen.  (Delta x doesn't get modified, because loser has to receive serve.)

So with doable operations in a low-op-count DF computer, you've only got a handful of  variables, a handful of constants, and a handful of operations (with a goto structure, which seems like the easiest for a ultra low memory computer).  Fitting it in 16 (non-graphics) bytes might be hard, but probably you could do it in 32.  Your bytes don't have to be any bigger than your output resolution-- if you're outputting to a 4x4 grid, you could get away with 4 bit bytes.

You're looking at 4 adds a frame, 3 of which could be increments.  So maybe two to four DF days a frame.

You probably don't want floating point stuff in DF.  I don't know how much memory or clock cycles it takes to do a square root, but I bet it's a lot.

If you want to make AI, it's probably easy to make AI that never screws up (would just take a few more bytes), but hard to make fallible AI.  I never managed to make a random function.  A decent random function probably requires a high resolution clock (100 tick increments would be good enough) and more memory and clock cycles.  Clock % (mod) rand_ceiling would probably work good enough.  Mod is expensive for a programmable computer, but if you were willing to make a dedicated random circuit, I believe you could get it working fast enough.

EDIT: With a 4x4 grid, you only need 2 bit bytes, but those aren't large enough to store sufficient operations for your computer.  8 bit bytes allow 256x256 output.  But that's a lot of graphics memory to build.  You probably want 8 bit bytes, and then just whatever output you're willing to build.  I doubt that it's efficient to compress small values into a single byte, you'd probably see more memory involved in compression/decompression than you'd be saving.