Print

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

[TheSilverHammer]

I just tried it and it works fine, so whatever reveal.exe has a problem with, this program doesn't.    This is really cool.   Can you put a filter on it so that it only shows known terrain?  Or can you incorporate the reveal tech so you can get a 3D look of the actual mineral layout and all that?

[sinoth]

quote:Originally posted by schm0:
<STRONG>Depth is a toggle you can set in the init.</STRONG>

True, I had forgotten about this.  My only concern is we don't want to force players to play with these numbers on.  The  tool shouldn't have any effect on play style.

quote:<STRONG>Indoors and outdoors are kinda irrelevant, since the walls, ceilings and floors would define that for the viewer. Dark and light would be nice, but lighting isn't yet implemented in DF, nor in the 3D map viewer. Currently, if it *was* implemented, then the entire underground would be pitch black. And how would you represent hot or cold tiles?</STRONG>

We can't ignore flags just cause they aren't in use yet.  Also, the flags I mentioned are merely the ones we currently understand.  There are at least twice as many more bits of information available, we just don't know what they do yet.

quote:<STRONG>Well, with the extremely small file size of the FDF-MAP, I see no reason why Toady wouldn't implement a similar option in the not-so-near future to export a fortress directly to FDF-MAP.</STRONG>

<STRONG>I guess I'm just saying that there should be discussion of formats, and a compromise should be made. Perhaps Toady can implement some sort of hybrid map that exports pure data instead of a graphic, throwing in all the relevant information to which you refer but keeping the file size small.</STRONG>

<STRONG>Perhaps the two formats can one day be so similar that they become compatible?</STRONG>

The reason I don't like the idea of a combined format is that for FDF-MAP you have to export the entire fortress into bitmaps, then run the compressor.  For the current map_export format, you just have to have DF running.  There is no need for tileset information.  The only way I can see formats combining is if you included the map_extract data inside the FDF-MAP file, which turns into a cumbersome 3 step process.  I'd like players to simply be able to export while playing the game.

Also, I see visualizing and DFMA exporting to be two different actions a player would want to do.  Visualizing will happen more often, to check to see if what they are building looks correct.  The DFMA export (usually) only happens when they are done and ready to show it off.  I don't like the idea of forcing the player to export both formats when they only want to do one or the other.

I do think a combined format would be better for the community... a sort of fortress fingerprint that can be viewed in 3D, or on the web, or whatever.  We have a format that is great for rendering, and another that is great for 2D display with the players tileset.  Combining them is a cumbersome process for the player, unless Toady writes a function to export both at the same time, and we can't sit around and wait for that to happen.

If you really want to think outside the box here... the 2D map information can be completely reconstructed if you combine the memory data with the tileset bitmap.  This process is a lot harder computationally, but removes the "export fortress to bitmaps" step.  Just a thought.

[valcon]

i'm sorry if this issue has been addressed or resolved already but

i read the OP and much of this thread but I couldn't find anything about how to fix the problem with the display occasionally wigging out when moving around the fortress ...  there do seem to be a few specific locations that do it reliably, but, with the frequency with which it occurs it not only suggests that it is parsing something very frequently, not to mention that it makes the thing damn near unuseable.  

has there been a fix suggested, and do you still need saves from forts that have this problem?

[sinoth]

valcon:  I still haven't found the cause yet... any info you have is greatly appreciated, including saves and a detailed explanation of how you can recreate it.  Unfortunately, I haven't been able to recreate the problem on my hardware, so the more detailed you can be the better  

[Mithaldu]

One thing i will be working on is loading both together to get an approximation of the full contents of a map.

Main problems with the fdf-map:
- different tiles can have the same representation, i.e. a swarm of flies vs. a rock wall
- only the top-most object in any tile is visible -> doors, bridges, floors, ramps, stairs, etc. get obscured

Also, we aren't actually guessing at the memory location. Due to Rick's fantastic research it is well known and he has found it again and again over the past versions. Lastly, we're only running through 100 MB, which in itself goes REALLY fast. The thing bogging my script down a bit is the conversion of the extracted information into something usable.

However, thanks to Markavian's posting i was convinced that it may be a good idea to simply try for now to use those maps to guess and fill out what's missing still.    

@ TheSilverHammer:
You can check the documentation of the format here: http://code.google.com/p/dwarvis/wiki/NotesOnMapExtract
Additionally, the file is in perl, under public domain and reasonably well commented.

Re hidden vs. non-hidden tiles: Check the newest version of the 3dwarf package in the op. Sinoth has bundled two versions of map_extract, one doing exactly what you're asking and the other doing the current default actions. Later on i'll allow the player to choose that on runtime. Also, reveal functionality in 3dwarf may come later, when i get around to analyzing vein data and mineral types.
As for why reval doesn't work for you: Maybe you don't have the latest version? Reveal and map_extract practically work off the same code basis and share a lot of algorithmic structure.

--

A general note for people with problems: In 90% of all cases, a problem that cannot be reproduced by a developer is straight-out unfixable. So please give sinoth as many informations a you possibly can, perhaps even a demonstration video uploaded to google video, as well as the safe file, etc.

[ January 03, 2008: Message edited by: Mithaldu ]

[ January 03, 2008: Message edited by: Mithaldu ]

[TheSilverHammer]

I suspect the problem that a few people have with graphical glitches are video driver incompatibility / bugs.   I know under directX when I create a 3d device I make a lot of basic assumptions which are likely invalid on some older hardware that will cause some issues.   For example the Vertex buffers I use are 8k, some older cards do not allow them to be that big.   Some older cards do not support dynamic index buffers, etc...

The problem for any developer is that he or she would really need all the hardware to test on because you can't actually reproduce the problems on the development machines.   I dunno if it is possible for someone on a non-development system to get DirectX debug data that might give a clue to the problem.

Anyway, I would like to once again thank the Developer for this tool.  If I were to ask for a single feature, I would like to ask for a directional light source that can be moved as well as automatically move in a circle in the sky.   The reason I ask for this is because seeing the subtle differences in tiers of terrain is fairly difficult without proper lighting.   When looking at something at a 45 degree angle that has several surface tiers, it is hard to see the different levels without a visual cue like directional shading.   Imagine looking at a grassy hill at high noon vs at 4pm (a simple computer generated one, not a real hill).  You can easily understand the visual difference with that example.

[valcon]

quote:Originally posted by sinoth:
<STRONG>valcon:  I still haven't found the cause yet... any info you have is greatly appreciated, including saves and a detailed explanation of how you can recreate it.  Unfortunately, I haven't been able to recreate the problem on my hardware, so the more detailed you can be the better    </STRONG>

Ok well first off, i played around with it a little more and here is what i've found:

it isn't specific to certain places or geometry, as staring straight up into the sky does it too.

also, and more importantly, it isn't about where you look, but where your camera is sitting.

if you WSAD your way to a certain tile, it distorts everything in the whole map, no matter where you look,

but

if you move the camera off that tile, everything is fine.  doesn't matter what elevation, seems to be a vertical slice.

here are some of my pertinent system info:

this is a LAPTOP, not a desktop, i ran it on here because I didnt want memory hacks on my main computer,

it has a PCIE radeon mobility 128mb video card,

plenty of disk space, no overheating, lots of memory and a big page file,

most current drivers (checked this morning) and dx9c

i'll email you the region folder in a sec

[ January 03, 2008: Message edited by: valcon ]

[coolguy1351]

dead grass does not seem to work yet, just a heads up.

[sinoth]

New release up (v04).  Get it here or the first post.  Two main changes...

For those who experienced glitches, there is now a 'compatibility mode' which is enabled in config.txt.  This should allow you to run the game without glitching, however it is slower than normal mode.

The second change is a moveable sun source.  Press 'h' to go into "sun mode", and you can move the sun with the WASD and RF keys.  Press 'h' to go back into normal camera mode.  When in sun mode, you should see a large white cube as the source of light.  If not, you probably need to zoom out some more.

Many thanks to those who helped test and find the source of the glitch:
YojimboUsaka, Valcon, Greiger, Quintin Stone, mattmoss

For those who are interested in what was causing the glitch, I think it had something to do with my over-usage of display lists.  The compatibility option simply doesn't use any lists... it just brute force renders the scene every frame.  I think older cards have problems shuffling around large numbers of lists (>100).

[Keldor]

Found how to fix a serious bug under Windows Vista:

What happens is the extractor crashes with a "Horribly" at the saving portion of the code, due to a missing file.  This is because the program tries to create a file in a directory that does not exist in the default installation (//lite).  Adding a new directory "lite" in the program folder fixes the problem.

[Keldor]

Found how to fix a serious bug under Windows Vista:

What happens is the extractor crashes with a "Horribly" at the saving portion of the code, due to a missing file.  This is because the program tries to create a file in a directory that does not exist in the default installation (//lite).  Adding a new directory "lite" in the program folder fixes the problem.

[sinoth]

quote:Originally posted by Keldor:
<STRONG>This is because the program tries to create a file in a directory that does not exist in the default installation (//lite).  Adding a new directory "lite" in the program folder fixes the problem.</STRONG>

I can see how that would be a problem, but the archive (3dwarf_04.zip) should already extract a blank 'lite' in the 'prog' folder if you extract all files from it.

[Greiger]

Oh new version of the visualizer. And it fixes the weird screen thingy too! Downloading it now, much thankees!

[Fedor]

This is an amazing project, judging from the screenshots.  But I'm having a lot of trouble getting v04 (downloaded from this thread today, no mods) to work on my particular machine.

Specs:
Pentium 4, 1 GB RAM, 2.0 GHz
ATI RADEON 8500 graphics adapter with 64MB RAM, stock display driver, most recent version (6.11).
Test map takes ~6 seconds to load (all three bars).

Problem report:
Most keys and mouse actions don't work or work only intermittently.  I can't navigate with wasd letters (the program's moved the view exactly once in my 10 minutes of testing).  Moving the mouse in mouse capture mode causes the camera view to jerk about upon occasion but, while I *think* I can see some order to how the view jumps, I'll be darned if I can figure out how to make it move the way I want it to.

It's worse than lag: most of the time, it just doesn't do anything, and it never moves after a pause as one would expect a laggy app to do.  Either it does something immediately or not at all.

Pressing F1 for help brings up a single short line of small brown text to the right of the window, garbled up in a way that makes me wonder if multiple lines are being printed atop one another.

About the one reliable thing I can do is force a reload when I press shift-F8.

My best guess is that either my computer or my video card is way, way too old for this application or there's massive incompatibility.  Given the specs, does this guess make sense?  If it does, consider including some idea of minimum hardware requirements in the readme.  If it doesn't, I'll be happy to provide any additional information you want.

[Symmetry]

I think you should try the compatability mode. ati opengl drivers don't seem to cope well with the way sinoth is rendering this (he should use VBOs instead!   )  

The readme explains what to do.