Print

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

[PTTG??]

Wow, this is an exellent companion to Dwarf Fortress. Thanks! I guess the next step is to see Units and Items in a square... then to have it live... then to be able to give commands from it... maybe.

[Lemnx]

Wow! Al I have to say is wow...

Such a shame that DF already uses so much of the available resources on most computers. A 3-D Real-Time companion would be so nice.

[Mithaldu]

quote:Originally posted by Greiger:
<STRONG>It's an ATI Radeon 9250 with The best Omega drivers available for it.</STRONG>

That might be a problem. I know from past experience that the Omega Drivers take some steps to improve performance and sometimes manage to muck up stuff like mipmaps. That's why i said stock drivers. Omega drivers aren't official.  

[Markavian]

Hey sinoth, I have a folder full of screenshots for you, the viewer works great. My main complaint is the display of stairs. Can you add some new graphics and logic in to display stairs differently depending on their position - like you do for ramps.

At Rivergears, the grand stair leading down to the housing dome doesn't look right:
    ... compare to: The Grand Stair on the map archive. Ok, so its not -that- grand, but it definitely spoils the effect. The stairs should flow downwards from the top from right to left.

Biggest frustration: I accidently switched into fullscreen mode a dozen times because my screenshot key was F11. This is my problem, but I would prefer a warning 'This will change to fullscreen mode, [Ok], [Cancel]'. I only mentioned it because a) it took so long to switch between modes, and b) sometimes when exiting out of fullscreen mode my desktop resoultion got screwed up and I had to access control panel > display settings to reset everything.

The ramps are very nicely done:
   

Keep up the good work,
- Markavian

[ January 01, 2008: Message edited by: Markavian ]

[valcon]

Great program, but I'm having that same problem as the other guy, when I look around or move the camera, every few seconds completely at random the whole thing wigs out and distorts the world and moves the camera really far away, total weirdness ...

[schm0]

The program looks great, but I have one main concern. I'm not sure if there was another thread on this program and I may have voiced my opinion there, but here goes:

Why hack memory?

SL and Markavian have worked hard on turning six or seven PNGs into a 3 dimensional matrix that takes up very little space.

What information can you gain from memory hacking that you can't gain from an FDF-MAP?

The only thing I can think of is material types. For viewing a fort in 3D and not in real time, are the appearance of specific materials really that important?

The benefits for using such a small file format are obvious: load times, FPS for the 3D viewer, running DF and the viewer simultaneously, etc... What do you guys think?

Not to poop on anyone's parade here, just talking out loud. I look forward to continued updates of this project.  

[TheSilverHammer]

Damm dude, this is awesome.  I can't wait to try it out.  I was just going to post and ask if the terrain file format was known so I could create my own visualizer.  Mine would have been very basic at best, and what you have is a lot more then I would have ever done.

[sinoth]

schm0:
As you guessed, material types are not included in the fdf-map format.  Also missing is flow information (depth).  There is also the issue of multiple objects occupying a tile.  For example, if a dwarf was standing on stairs they wouldn't get rendered properly.  Also, although we haven't made use of it much yet, there are 'designation' and 'occupancy' flags in the memory that give a ton of information about a specific tile.  These flags include details such as if a tile is muddy, if it is indoors/outdoor, dark/light, hot/cold.  This type of detail just isn't possible through a screenshot.

Even with memory hacking, there is quite a bit of guess work that goes into rendering the map.  For example, a boulder has no ground type associated with it (because in-game, you can't see the ground of a boulder tile).  So the type must be guessed by looking at the tiles surrounding it.  Trying to render an fdf-map in 3D would entail much more of this guesswork.

As far as file size goes, there isn't much difference between a 100k and 200k file.  Even on dial-up, the difference in download speed is roughly 20 seconds.

You mentioned running DF and the viewer simultaneously.  That argument is also in favor of a memory hacker.  Remember that in order to get an fdf-map file, you have to pause your game and export the bitmaps, then run the bitmaps through SL's compressor.  There is absolutely no way you could do this real-time.  With a memory hacker, though, you could easily scan the memory once every few seconds and update the display accordingly.  In this case, the smaller fdf-map file does not correlate into more FPS or faster load times.

[ January 02, 2008: Message edited by: sinoth ]

[TheSilverHammer]

Does this application work for saved maps instead of just live ones?  I am not sure how memory hacking is supposed to work on secure OSs.  I have been writing some windows apps for a while, and not that I have been trying to hack memory of apps, but I do not know how you can look at another process's memory without it's cooperation.   Under vista, I am not sure you can even use a DLL hook anymore.

Why can't people use the saved files to look at things, is the format unknown?

[sinoth]

TheSilverHammer:
For what you're wanting to do, the lite text file generated by map_extract should be perfect.  The format is very simple: (the '|' character is used as a separator)

code:

Mapname|x|y
-layer_number-
index index index ...
...
-layer_number-
index index index ...
...

It should be noted that x and y are in map chunks, not actual tiles.  To get the actual tile number, multiply the numbers by 16.  So a map of size 6x6 is actually 96x96 tiles.  The indexes are listed from left to right, and top to bottom (just as they are presented in DF).  The layers are organized with the bottom first.  The index numbers are explained on this spreadsheet:
http://spreadsheets.google.com/ccc?key=ppHCNfNceTrmxbXWDzf9aXg&hl=en

Feel free to ask any questions about the implementation.

As far as the save file question goes, I'm honestly not sure. :/  I haven't looked at the save files in that kind of detail before.  I don't think the memory hacking is an issue with Vista... can anyone with Vista confirm this?

[Symmetry]

I have vista and it works fine, although my main account is an admin account I don't run mithaldu's tool as admin.  Do processes have to ask to make their memory protected?

[TheSilverHammer]

There is a lot of things even and Admin can't do in vista.  My real job is to write a security application and vista is fairly locked down.  I had to elevate our application to a 'Local System' account to do some things because even running as admin still didn't let you do everything.

The reason I ask about this tool, which I will try when I get home tonight, is that the reveal.exe fails for me.   I have asked about it and it seems I am doing everything right.  My only guess is that the application lacks privileges (I run it as admin too), and defaults to the incompatibility error.

Maybe it is something else, but if I get home and try this 3d viewer program and it doesn't work, that will be another big hint that memory snooping is off limits in Vista.

I would find is strange that anything like this would work because if you can snoop on another program's memory, how can you really be secure?  I thought all NT kernel apps didn't allow that, although unless everyone is running windows ME or 98, it did allow that.  One thing to note is that I run Vista with UAC turned on, so maybe for people who have no issues are running with UAC turned off.

[Quintin Stone]

quote:Originally posted by sinoth:
<STRONG> :eek:  If you can, see if you can consistently reproduce the error, then send me the save for it.  A screenshot might help too... I haven't encountered anything like that yet.</STRONG>

Sorry I haven't posted anything yet.  I'll try to get some screenshots for you.

In the previous version (3Dwarf 02), what would happen is that the framerate would drop to near zero in certain spots.  If I moved the mouse, there'd only occasionally be a screen refresh (like once every 10 seconds at most).  Then I'd move off that spot with WASD or right-click & mouse move and everything would return to normal.  With this version, it's a different effect, the one I described before.  And it's not when looking straight down, it's any angle.  It seems more a property of the camera's XY coords (and maybe Z?).

[mattmoss]

quote:Originally posted by Quintin Stone:
<STRONG>
Sorry I haven't posted anything yet.  I'll try to get some screenshots for you.

In the previous version (3Dwarf 02), what would happen is that the framerate would drop to near zero in certain spots.  If I moved the mouse, there'd only occasionally be a screen refresh (like once every 10 seconds at most).  Then I'd move off that spot with WASD or right-click & mouse move and everything would return to normal.  With this version, it's a different effect, the one I described before.  And it's not when looking straight down, it's any angle.  It seems more a property of the camera's XY coords (and maybe Z?).</STRONG>

I've gotten the same thing (on the previous rev, haven't tried the latest).

Best I could tell without debugging is that some texture state is getting out of whack. The skybox was "being drawn" with incorrect textures, or so it seemed.

[schm0]

quote:Originally posted by sinoth:
<STRONG>schm0:
As you guessed, material types are not included in the fdf-map format.  Also missing is flow information (depth).</STRONG>

Depth is a toggle you can set in the init.

quote:There is also the issue of multiple objects occupying a tile.  For example, if a dwarf was standing on stairs they wouldn't get rendered properly.

Ok, minor issue solved by the fact that stairs would only be completely obscured by two dwarfs standing on both upper and lower ends of the stairs. But, you make a good point.

quote:Also, although we haven't made use of it much yet, there are 'designation' and 'occupancy' flags in the memory that give a ton of information about a specific tile.  These flags include details such as if a tile is muddy, if it is indoors/outdoor, dark/light, hot/cold.  This type of detail just isn't possible through a screenshot.

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?

quote:Even with memory hacking, there is quite a bit of guess work that goes into rendering the map.  For example, a boulder has no ground type associated with it (because in-game, you can't see the ground of a boulder tile).  So the type must be guessed by looking at the tiles surrounding it.  Trying to render an fdf-map in 3D would entail much more of this guesswork.

Still, it seems less of a hassle to create such an algorithm than "guessing" at which memory location holds what. The file size alone diminishes the amount of memory that DF takes up.

quote:As far as file size goes, there isn't much difference between a 100k and 200k file.  Even on dial-up, the difference in download speed is roughly 20 seconds.

Well, I guess it comes down to this: How much memory does DF use and how much space does an FDF-MAP take up? I'm sure they're drastically different.

quote:You mentioned running DF and the viewer simultaneously.  That argument is also in favor of a memory hacker.  Remember that in order to get an fdf-map file, you have to pause your game and export the bitmaps, then run the bitmaps through SL's compressor.  There is absolutely no way you could do this real-time.  With a memory hacker, though, you could easily scan the memory once every few seconds and update the display accordingly.  In this case, the smaller fdf-map file does not correlate into more FPS or faster load times.
[ January 02, 2008: Message edited by: sinoth ][/QB]

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. And SL and Markavian have already started work on making the map viewer work in three dimensions... which is where I see potential for the 3D map viewer and the DFMA.

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.

(The reason for this as far as the file format is concerned: it's not about download speeds, but more about data crunching. It seems to me that it would be easier to wade through 500K of data than 1GB of memory.)

Perhaps the two formats can one day be so similar that they become compatible?