Bay 12 Games Forum

Works for me, Windows 7 with no settings changed for ttt.exe. FPS display is off, and I started the server with DF in the main menu, just like you said.
The colors are off and there's some occasional flickering, in the form of vertical sections going black for a moment, but you can definitely see what's going on.
All this, less than a day after someone urges the programmers to get on it. Awesome.
Here's the picture:

Spoiler (click to show/hide)

The actual game is at the bottom, with the server and client on top of it.

I'm verifying these results. I've gotten everything up and running(with flicker and color weirdness), though the results are strange/unworkable if you try a standard DF download(none of graphical update clients), with vertical stripes of mildly accurate tiles, though I doubt support for the old-style graphics would be necessary.

If this ever gets off the ground, I would love to donate cycles. I'm running a dual-core Intel E8400 clocked to 3.73ghz, with a full 32-bit complement of RAM, so running one(or more!) true community forts would be kind of fun, as long as I don't have to ruin run them myself.

Pre-recent optimizations, on an E8400 clocked to about 3.7Ghz, I can manage 30+ FPS with 200 dwarves and 200 animals, a lava moat, a working aqueduct system that is capable of being pretty well controlled, on a 9x9 mountain map with about 90 z-levels and a real river, a cave river, chasms, a volcano, and potentially HFS that I haven't found yet. I haven't done any sort of metagaming to improve my FPS, either, and I have all options enabled. I imagine you'll get similar or better.

$25 USD here. Merry Christmas, Bay 12, and may all your kimberlite bear diamonds. 

Avoid death as much as possible: No suicide-missions, throw-away dwarves, or mass-butcherings. Any "extra" dwarves just farm to make up for their expenses. Each dwarf and pet gets their own grave; dwarves get a fullly decorated room, which is usually assigned after death, due to not having the resources to maintain that many graves. Nobles get spared, because I'm not terribly convicted against cheating to make up for impossible mandates. I've temporarily modified hammer damage before, or created reactions in which I can convert an equally-valuable or more expensive metal into the needed material. However, I've had dwarves run consecutive sentences in jail for years before, which is never very healthy for them. I've only had to manually save one from jailing consequences, though, since they usually get just enough of a break to grab a drink and a nap.

I use traps initially, since my forts tend to be very economical at first, but once I have a standing army, I reduce it to the bare minimum. No impossible-to-access areas, though I am not against restricting access. My current fort has a magma moat with five bridge entrances. All bridges except for the main road access bridge may be lifted, and really only exist to give quick paths around the moat for my dwarves.

All dwarves get full-sized rooms. Not noble sized, but a regular 3x3 block. Depending on the number of masons available, they may or may not be fully furnished.

Anything that isn't specifically trying to kill me is spared if possible, except for game animals when needed. Any captured goblins are released once a siege is over, and I attempt to do the same with any other entity I manage to catch. Unfortunately, this usually doesn't work with megabeasts, who then attack and get one-hit-KO'd by my legendary swordsdwarf/wrestler/armor user/shield user Captain of the Guard, whose name is longer than the aforementioned chain of descriptions.

I included 7^3 as part of my math because I assigned each inner cube its own material data, which I assumed required a full byte due to the number of options available. I tried to make a comparison between wanting smoother scaling and just picking a larger map and scaling everything down mentally, if it helps.

Quote from: Mithaldu on October 07, 2008, 10:05:30 pm

It wouldn't do you shit, since CPUs that cost more don't go beyond a certain speed, they only increase the number of cores, which is completely negated by DF being single threaded. At best you could run multiple DF games at the same time.

In the end it would be a collosal waste of money with zero gain over simply buying a good computer.

Thus, with THAT budget, instead of investing in more cores you just get a bleeding fast single CPU and overclock it to hell and back, with a liquid helium coolant system!

"Jesus, 400 dwarves at 100fps? What the hell is your CPU temp right now?"

"about a degree or two above absolute zero, why?"

The CPU would be the only thing keeping the rest of the room from instantly freezing.

Quote from: Xehon on October 12, 2008, 05:25:11 am

Quote from: ChJees on October 12, 2008, 05:08:16 am

The Terrain Data will be 7 times bigger too .

Not necessarily. Most Data would still be for blocks of 7. Stuff like material info and the like Terrain would be just like water, x/7. Oh, and this would allow to have less than 7/7 water freeze realistically.

So if I have 4/7 obsidian and 3/7 granite, which is on top?  What about 2/7 obsidian, 3/7 granite and 2/7 obsidian?  Are they the same?

A way around that would be to only allow a tile to have limited types. It could have a biome-designation, which would describe soil availability/composition, and a designation for the type of stone, which would limited to only one object.

My main issue would be displaying it. You would either need an extraordinarily complex display/mining/construction system which would be painful to use(so that you'd know which tiles were usable, and so that you'd be able to set the mining/constructions to be usable), or a full 2,5/3D interface(which would still make designations a bit obnoxious). Unless you have some ideas for that, considering the current interface of z-levels would only be able to give useful information with a division of only one(as it is now), possibly up to three or four.

A second question of mine would be whether or not this should be expanded to give each square's x- and y-based layering as well, to be completely fair to those of us that are huge fans of these under-represented dimensions. This would result in 7^3 = 343 Intuitively Derived and Described Material Cubes(TM) per tile, giving us quite a handy tool for quickly reading a tile's most important characteristics, and allowing for more accurately represented rounded corners. Of course, one could ask if this would be too much to store in memory, but really, if you do out the math, it would only give us around 6,303,744 more bits per mapsquare per z-level. On my current map of 9s x 9s x 89-z, this would be only 45443690496 extra bits!  That's only ~5.3 GB, and anyone that doesn't have at least 12GB of RAM on their Dwarf Fortress computer is an undedicated coward and should be made into mittens post haste.

Though, of course, the real use of this system would be to allow us to fit up to 342 more creatures in each tile before they have to start laying down.