Print

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

Faster than 40d, no problems

42 (26.1%)

Faster than 40d, problems

72 (44.7%)

No slower than 40d, no problems

14 (8.7%)

No slower than 40d, problems

16 (9.9%)

Slower than 40d, no problems

2 (1.2%)

Slower than 40d, problems

3 (1.9%)

Doesn't work (please explain)

12 (7.5%)

Total Members Voted: 160

[Baughn]

To zoom users in general:

The middle mouse button does not reset zoom anymore, instead it switches zooming modes. You press f12 to reset it.

I'll get a proper guid up in the first post soon.

[Baughn]

..geez, what happened to the window dialog box? It's all box-y. ;_;

[Baboonanza]

I'm not commenting on the OpenGL aspects, but the new map output function.

The effort is very nice, but the format leaves something to be desired. As far as I can tell it outputs a very large text file over 6 meg in size (for one layer? and that's on a very small map). The file consists of:

Code: [Select]

Tile: Air
Material: White sand
Info: inside, dark, above ground
---
Tile: Air
Material: Red sand
Info: inside, dark, above ground
---
Tile: Air
Material: White sand
Info: inside, dark, above ground
---
Tile: Air
Material: White sand
Info: inside, dark, above ground
---
Tile: Air
Material: White sand
Info: inside, dark, above ground
---
Tile: Air
Material: Pelagic clay
Info: inside, dark, above ground
---
Tile: Air
Material: White sand
Info: inside, dark, above ground
---
Tile: Air
Material: White sand
Info: inside, dark, above groundWhich is impractical for the purposes of parsing into another representation. It would take a long, long time to load this map given all the string lookup and various other processing required.

What is needed is a binary form that contains tile information in a similar format to DFs internal structures. For each tile something like:
[tile_type_enum][material_type][material_index][water_level/type][other_flags]

The external application can then reference the RAWs to find the names/colors of materials.

[Baughn]

Better yet, a format that starts off by describing how the binary should be interpreted, then goes off in binary. So you don't need the raws.

I'd disagree that this version is too slow, though. Yes, 6MB is too much, but a reasonably efficient program could still parse it in quite a lot less than a second. Just don't use python.

Here, I'll show you: *writes a parser. Check back later.*

[ilsadir]

I exported a map into the raw text files, and I agree it isn't parser-friendly.

How do you determine the x-y dimensions of the map?  The files output something like fortressname-blah-blah-N-M-level, but N and M don't appear to be the correct numbers (i.e. I exported from a 6x4 map, so the numbers shouldn't be 274x48 like they are).

[Rose]

why not something standard like CSV or XML?

those are standardised and there's alredy parsers for them a plenty

[virus_found]

Still won't compile from 96726cf4ce0fcd

[Baughn]

It should've. Never mind..

At this point, just use the latest version; it works now.

[Baboonanza]

Well, I've changed my mind somewhat after writing a quick parser. It doesn't include anything that I can't already access directly in DF memory, but this is definitely an improvement over having to find offsets for every version.

Building, items and creature information is included. Multi-tile buildings have an entry for each tile, with a coordinate. As stated above, I can't work out the map dimensions but the last number in the filename is the z-layer I presume.

Output from my parser:

Spoiler (click to show/hide)

Scanned file: C:\Documents and Settings\User\Desktop\df_28_181_40d13_win\Guildbranded-raw_map-region2-421-2604-15.txt
Time taken: 1.600000 seconds
Hidden tiles: 29123
Water tiles: 1289
Magma tiles: 0

Types:
 soil wall: 3956
 grass1 ramp: 1128
 grass2 ramp: 1149
 pool: 1285
 soil floor2: 71
 soil floor1: 83
 grass floor2b: 4314
 stone ramp: 218
 grass floor3: 4372
 tree: 2540
 grass dead ramp: 2
 soil floor3: 97
 grass floor3b: 4334
 grass floor4: 4258
 grass floor1: 4210
 grass floor1b: 4274
 soil floor4: 88
 shrub: 2786
 grass floor2: 4383
 grass floor4b: 4434
 stone pebble3: 420
 soil ramp: 27
 stone floor2: 416
 stone pebble1: 445
 stone floor4: 398
 stone pebble4: 468
 stone boulder: 199
 stone floor3: 419
 stone floor1: 378
 sapling: 485
 stone pebble2: 412
 dead shrub: 1
 Air: 1771

Materials:
 Red sand: 49437
 Slate: 3773
 White sand: 611

Flags:
 inside: 3960
 dark: 3960
 subterranean: 3960
 outside: 49859
 light: 49859
 above ground: 49859
 stagnant: 1289

Creatures:
 Red sandDeer: 2

Spoiler (click to show/hide)

Scanned file: C:\Documents and Settings\User\Desktop\df_28_181_40d13_win\Guildbranded-raw_map-region2-421-2604-11.txt
Time taken: 1.453488 seconds
Hidden tiles: 0
Water tiles: 0
Magma tiles: 0

Types:
 Air: 82944

Materials:
 White sand: 76107
 Red sand: 337
 Pelagic clay: 401
 Clay loam: 341
 Black sand: 380
 Silty clay: 358
 Sandy loam: 365
 Sandy clay loam: 370
 Sand: 334
 Sandy clay: 350
 Peat: 312
 Siliceous ooze: 359
 Silty clay loam: 366
 Clay: 370
 Yellow sand: 382
 Calcareous ooze: 364
 Silt loam: 336
 Loam: 377
 Silt: 373
 Loamy sand: 362

Flags:
 inside: 82944
 dark: 82944
 above ground: 82944

1.6 seconds makes it slower than reading the data from memory (including buildings/correct stone types) by a factor of 2-5. I would expect the files to get much, much larger for a normal fortress. The test map I ran it against had little in the way of buildings and items. If you've got 10000 stone lying about this is going to be sloooow.

Exporting from DF is really quite slow too, and it needs to be possible to export the whole map in one go, preferably to a directory containing the layers as different files.

A a binary would relieve the speed issues, personally I think it's too slow at the moment.

Edit: The 'Red sandDeer' in the output above is a bug in the DF output code as it's present in the original file. The last output string was 'red sand', so there probably some accidental concatenation going on.

[Mephansteras]

I had voted as 'Doesn't work', but that turned out to just  be a problem with my interface file. So it works, and I'll give you a better review once I've had a chance to play with it a bit.

[Baughn]

Well, I had fun writing a map-dump compressor - code at http://hpaste.org/fastcgi/hpaste.fcgi/view?id=6583#a6583, or in the DF/libgraphics git repository.

It parses the entire file in three seconds on my system. Not great, but good enough for unoptimized, high-level code. The file it spits out is a tenth of the size for a simple map, but would probably get bigger rather fast - its only semblance of compression is that it uses 1, 2 or 4 bytes per tile element based on how many different elements there are.

And basically because I could, I made it multithreaded. One thread per file, but you can pass it as many files as you like.

[Mephansteras]

How would I get this thing to actually get me a full-screen view on my laptop? I can only get about half the screen to actually be used, and it's way to small for my tastes.

[drawf_irons]

A bizarre bug: In adventure mode, I am completely unable to visit map tiles using > on 40d13. A quick check using identical saves on 40d11 or 40d reveals no such problem.

[Eidalac]

Loads a hair faster than d11, and seems to run just a -bit- faster, but that's with 150 dorfs and 200+ animals, rivers, moats, lava ect.  FPS reads the same as in d11 (16ish in my worst areas), but it _feels_ smoother.

We'll see what it can do when I get my mist generator online.

Now I have to get my mouse working so I can play with the zoom-y-ness.

No real time to test anything, but I did also notice the text in some of the sub menus (designations, building, ect) is... not right, as in AbuDhabi's screen shot.


Man, you guys make me sad I don't have time to do any coding these days.

Keep up the good work all.

[Corona688]

What do translucent tilesets in a one-tile-per-square system actually do?  Or is that supposed to mean graphic sets?