type -------designation-flags-------- -------occupation-flags---------The one i don't quite understand is this one: hatches as doors but total=floor.
Hi. This is a fasinating thread and I've got a related question (I'm also playing with 3D visualisation).
DESIGNATION_MATGLOSS_BIT1-4 seems to be an index into a list of stone types that make up the layers for the map. However, I can't find the relation between this index and the array of stone types loaded from the raws. Presumably there is some sort of intermediate array, but I can't find it.
Does anyone have any info on either the form or location of this data? Or am I barking up the wrong tree?
Cheers.
I'm sorry, but it will be a while before anything comes of this. I posted it at a time where i expected roughly a month before i had enough data to work with.
It will be some time until i can take enough of a break from work to actually invest in this. :/
added Z levels and colour visualization
added Z levels and colour visualization
Could you explain this?
My projected starship fortress would need in the region of 140.
Tamren: This has nothing to do with changing dwarf fortress. This is about 3Dwarf.
I agree with the guy with the spathi cypher.Huh?
Anyway, that video is a neat proof of concept.Haha, it's a lot more than that. Right now it's mostly a question of fleshing it out. :) (Currently working on a toolchain to convert Wavefront objects to perl code, since making ramps by hand is fucking tedious.)
I agree with the guy with the spathi cypher.Huh?
Due to the incredible complexity of ramps, there are at LEAST 256 possible physical representations of them, and that's only taking into account the situation on the same 2D layer.
Ah. Perl. The language I'm most familiar with, and the one upon which I cut my teeth, is C++. However, I know enough about perl to at least be able to read this. Thank you!
Also, yeah, I'm acquainted with SVN. I used TortoiseSVN before, and it was fairly nice. However, that was quite a while ago... I'm on Linux, now. My IDE of choice, Eclipse, has handled SVN before, so I know how to set it up. Thank you, again.
May your semicolons never be forgotten, and your pointers never cause a segfault.
Oh... no. I haven't tried running this on wine yet. I'll give it a shot tomorrow, though. It's 23:00 here, and I'm tired. I've only used utilities for Dwarf Fortress once, and that was on my windows partition, while I was fooling around. I'll let you know what I find out when I try.Ah. Perl. The language I'm most familiar with, and the one upon which I cut my teeth, is C++. However, I know enough about perl to at least be able to read this. Thank you!
Also, yeah, I'm acquainted with SVN. I used TortoiseSVN before, and it was fairly nice. However, that was quite a while ago... I'm on Linux, now. My IDE of choice, Eclipse, has handled SVN before, so I know how to set it up. Thank you, again.
May your semicolons never be forgotten, and your pointers never cause a segfault.
Hmm, does this utility work for you? I can't get any of the 3rd party stuff to work under WINE - my guess is that each program must be running in its own protected space so they can't find the DF window. Is there an option I need to pass to wineserver or something?
- Added models for boulders, shrubs, trees, saplings.
- Added brightness variations for various similar tile types (for example grass) via array in internals.
- All models draw their initial brightness modifier from the internals table now.
- Restricted brightness values in the model generator so it wouldn't generate pure black or white tiles.
- Disabled hiding of hidden tiles that are atop unhidden ones.
- Added culling of invisible polygons to floors (and similar, like trees, etc.) and walls.
- Added mouse sensitivity setting to config.
- Simplified the creature model for better performance.
- Creatures now get updated more frequently (almost real-time).
- Position is now calculated by using the viewport coordinates when no cursor is active.
- View range can now be modified via buttons in the lower left corner.
- Small bugfix to clamp cell access to map when range is too big.
Toady, I don't know if and when you'll answer this, but if you have a look in: Why are there creatures with insane coordinates like 50k+? :o
Yep so you heard it here first... They are stored... IN SPACE!!!
New version:Yeah, this doesn't work for me anymore. I tried an older version a couple of days ago which worked fine, but when I open this one, the window freezes, and the console prints the same 3 lines over and over again:
http://dwarvis.googlecode.com/files/Lifevis_R179.rar
Did some refactoring so it looks like a real application now. Added some gui niceness which allows you to cut off slices at the top and added models for stairs as well.
And a new version of Lifevis is done. :)Sweet, I got it working this time...
However, all the dwarves are just tiny dots for me. If I get very close I can make out that they are dwarves, but from any distance they are undistinguishable. But good work on finding the dwarf and building positions :)I'm still experimenting there. One problem is, i'll eventually need to fit building stuff, up to 4 creatures and also items in one square. So i can't start it off with creatures filling the whole square.
Have you had any luck with rock materials yet? If you are interested I can give you a full explanation (though my offsets are a bit out of date), it's more complicated than I ever would have imagined and my previous explanation was incomplete. I also have some info on determining the material types of constructed walls/floors.I haven't looked at that at all so far. Any kind of explanation that would save me research time would be greatly appreciated. :)
This means that any slowdown you may experience will absolutely only come from OpenGL bogging down under the load of how much it has to draw.If OpenGL rendering is what's slowing it down then you're doing something wrong :). Seriously, the numbers of triangles you're drawing is trivial, the trick is just knowing how to correctly and efficiently cache the geometry data on the video card. My suggestion would be:
Which leads to the next thing. I think i have solved the problem of "Omg, i have 10 layers of stones in my stone bunker and the 3000 item are bogging down the performance!" The problem here is: I figured, since items aren't very static, i wouldn't need to put them in a display list. Reason being: Display list generation isn't very cheap and requires for me to create structures to organize them. However i'm pretty much forced to do it in some way.Each object's model should be stored *once* in vertex/index buffers as outlined above (or a display list if you really want to). Then draw this model as many times as necessary to represent the visible objects, and it won't make any difference whether they are moving or not.
Middle-click + drag is the zoom. :)
Middle-click + drag should be pan, IMO. Mouse WHEEL should be zoom. Right Mouse is rotate.I hate it when everyone and their dog assume I want/have a mouse wheel with 3+ buttons.
Middle-click + drag should be pan, IMO. Mouse WHEEL should be zoom. Right Mouse is rotate.I hate it when everyone and their dog assume I want/have a mouse wheel with 3+ buttons.
Left+Right should be zoom.
Right rotate.
Left interact.
And keyboard shortcuts for all of the above. (Yes, I do have a computer that I do use that doesn't have a mouse attached to it).
I hate it when everyone and their dog assume I want/have a mouse wheel with 3+ buttons.
Left+Right should be zoom.
Right rotate.
Left interact.
Whoa, I didn't do the stairs, that was tripwire. I just contributed the fortress in those screenshots.Ack, thanks for correcting me, post modified. ^^
OpenGL!!!How to put this ... I'm pretty much doing all of that already. ^^
Mouse buttons!Guys, if you want to have idelogical wars about this, do so, but somewhere else please? The implementation that is currently there happened as follows: First i wanted to turn around, but not all the time and with some freedom, so i put it on the left mouse button and ensured it scans as long as it's held, even outside the window. Then i played around with glut and found it has some menu stuff, so i played with that and put it on the left button. Sometime later i realized, moving around to get close to stuff is fucking awkward, i need zoom. But left and right were in use already, so i used the next free mouse button i had. Absolutely zero thought went into the layout, it all happened as it was needed.
Everyone, Forums-Poster is throwing a tantrum!
How to put this ... I'm pretty much doing all of that already. ^^Apologies :) I suspect using VBOs would still give you some advantage but as you say they may be more difficult to use from Perl. One thing to consider using display lists is that I believe they are optimized more efficiently by the driver (ie straight to VBOs) when they contain only geometry calls (no state changes). This might be something to try.
You can check a post from me on that topic here: http://forums.somethingawful.com/showthread.php?threadid=2917631&userid=125080&perpage=40&pagenumber=2#post350470768
Summary: I was completely off-base and apparently trying to for-loop through 15000 items per render call is a tad too much. I'm not exactly sure what i can do about that yet. Maybe it's the fact that on each loop instance it instances a new copy of the array index, but in the end i'll figure something out.
Also, VBOs scare me. Working in Perl i can't use ANY c++ examples, since the syntax is slightly different and the variable typing radically so. Aside from that i've also been unable to find a simple enough example to go in and experiment with, since all examples seem to be "let's draw this uber-complex shit with VBOs", instead of "how do i draw a single triangle with VBOs?".
Display lists are nice and easy. They have begin, end, a number, and that's it.
I wouldn't know whether it was faster or not, since I only got about eight or nine frame updates before being forced to kill the process after ten minutes,Uh, thanks for only answering half my post, i guess? Please note for the future, that whenever you talk to software developers, it is absolutely imperative that you answer *all* questions they ask you. Otherwise you might not bother in the first place as you're wasting their time.
Apologies :) I suspect using VBOs would still give you some advantage but as you say they may be more difficult to use from Perl. One thing to consider using display lists is that I believe they are optimized more efficiently by the driver (ie straight to VBOs) when they contain only geometry calls (no state changes). This might be something to try.No need to apologize. :)
As for the objects, I can think of one or two methods to reduce your overhead that should be simpler than normal frustum culling etc., although I'm basing this on a guess that they are stored similarly to constructions. If this is the case then they are ordered by tile coords (z then x then y if i remember correctly). This immediately allows you to skip multiple items in a single tile, since they will all be consecutive. As you also know which tiles are visible you should also be able to limit drawing to visible objects, especially by z level culling. To avoid iterating through the whole list to find certain coords I would suggest using a binary search, which is what Toady uses in DF.I tried skipping of items when there are more than one per tile already. The cpu cycles needed to track that negated any gain that the skipping gave. Besides, i may want to actually draw all visible items on a tile later on. ^^
As you can tell, I have an interest in the subject but I'm just trying to help so please don't take offense if I'm telling you stuff you already know ;) At some point I'll have a look at the code and see if I can help but not knowing Perl is a bit of a hinderance there.It wouldn't actually be much of a hinderance, since Perl is made to be very human-readable and i generally write pretty clean code. (Although lifevis is in dire need of refactoring and cleaning.)
Edit: And if it helps, here is my (limited) knowledge of the construction/building structure:The matgloss thing is new to me, which is pretty awesome. :D
offset, length, field
0x0 WORD x-coord
0x2 WORD y-coord
0x4 WORD z-coord
0xC WORD stone matgloss index (ie. 192 = bauxite) of contruction material
I never got as far as working out how none-stone constructions worked.
...Anyhow, the new version should give you a marked performance increase. Could you also upload your save on drop.io so i can see if i can make some optimizations for problems encountered specifically in your save?This doesn't show the processes tab, but I assure you, the CPU field was 97.
As for being forced to kill the process: I don't believe that, period. The only way you could actually lag shit out enough to make the X on the window unresponsive is by getting your ram filled. Lifevis however has an automatic ram limiter, which is currently set to 300 MB, as you should know by reading the config file.
This doesn't show the processes tab, but I assure you, the CPU field was 97.Completely normal. Any 3D application will use as much CPU as it can get, in the case of lifevis even a bit more than DF can grab, since it can partly run threaded. Whenever running a 3D application and it is NOT hogging at least one core completely, something is foul. ... I really wish people would stop seeing 100% CPU and go all :tinfoil:.
Consider that dwarf fortress never gets above 50 since it's a dual-core.
Lastly, I answered your question to the degree I was able to. If the program was so badly lagged that I couldn't move to hide the items, exactly what do you expect me to say? 'least I'm trying to be helpful.Thing is, you never even mentioned that. I can't read thoughts and if you look back at your post, you might see how it looks like you completely ignored the second question. ;)
Lastly, about the X- if the program is lagging so badly as to be updating stupidly slow, do you honestly expect me to expect the program's close button to work?Yes, simple reason: The window chrome is constrolled by Windows itself, so even if the task freezes, it will recognize that and ask you whether it should nuke the task. And heck, if the program is not even frozen, then there is NO reason whatsoever to assume the X won't work, period.
First, it was way faster. As in, more than one FPS. Well, TBH it ran nicely, and was responsive. I had approximately 38,500 item-tasks and 8,400 building-tasks. However, it once about 3/4 of the items (by item-tasks when it was idling) were on-screen it started to slow down, pushing core 1 (last time, it was set to both cores. This time, it was relegated to a single core only) to 100%. Shortly thereafter, when I clicked 'close', it froze and Vista declared it a crash. I also got the save for you- I hope it's complete, I checked out VirtualStore and /dwarf fortress/, so this should be the entire save.That save is pretty damn awesome, thank you! There's so much shit going on there that it'll probably account for the majority of my test cases. :D
http://drop.io/Sukasa_Cavepacks
Why is it always furries who manage to find methods to do shit on their computer that make me want to bash my head into the desk?uhm, what? You may want to check your facts here >_>
This has great potential!
Thanks. :)
As for adventure mode ... I had no idea. Apparently it kinda works. :D But at one point it horribly died for me.
my error.txt file is emptyThanks for the info so far. Sadly pastebin.ca is acting up for me and not loading, but maybe that clears up tomorrow. Aside from that, from what you've told me, i can only guess that your drivers aren't quite up-to-date. Overclocking shouldn't be an issue.
and here is my Dxdiag:
http://pastebin.ca/1255324 (http://pastebin.ca/1255324)
also my Q6600 is overclocked to 3.6GHz and my gfx card is overclocked a tad aswell
Actually I think this might be even more useful for adventure than fortress mode. Exploring in mountaneous terrain is annoying in 2d mode and there is (I guess) less speed issues because it's turn based.I noticed that myself. It seems to be fairly unintensive, compared with the Fortress mode. Also, thanks for the flowers. :)
with that many details on creatures in the next release how about generating the creature Graphics procedural from the raws?
As i told the other dude with that problem before, please install this: http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en
That would be just like Slaves to Armok all around. A true torment.Only for the dorfs. You need to keep in mind that writing an interface for an existing game is different than writing the game and the interface at the same time. ;)
Never could get it to workNext thing i'll do is make this compatible with computers who can't do occlusion queries. :)
would you possibly be accepting admissions for possible models? Also what program do you use when creating the models?All that and more is answered in the readme and in the following thread. :) http://www.bay12games.com/forum/index.php?topic=25521.msg294382#msg294382
I'll be making some models myself in my spare time and post them for anybody to use.Awesome! Please do note the thread linked above though. It has a bunch more info. =)
is there a recommended triangle count for models?My target for now is ~1000 polys.
Sorry to hear. Maybe this helps: [ http://www.microsoft.com/downloads/details.aspx?familyid=9B2DA534-3E03-4391-8A4D-074B9F2BC1BF&displaylang=en ] I think i got the wrong link in the previous post. I really need to add this to a FAQ file.As i told the other dude with that problem before, please install this: http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=enForgot to mention it, but I did install that from reading the previous posts. No help there.
Can't load 'C:/Documents and Settings/Asehujiko/Bureaublad/DF/lifevis/site/lib/auto/Coro/State/State.dll' for module Coro::State: load_file:De toepassing kan niet worden gestart omdat de configuratie van de toepassing onjuist is. Het opnieuw installeren van de toepassing kan dit probleem oplossen at C:/Documents and Settings/Asehujiko/Bureaublad/DF/lifevis/site/lib/XSLoader.pm line 70.
at C:/Documents and Settings/Asehujiko/Bureaublad/DF/lifevis/site/lib/Coro/State.pm line 106
BEGIN failed--compilation aborted at C:/Documents and Settings/Asehujiko/Bureaublad/DF/lifevis/site/lib/Coro/State.pm line 112.
Compilation failed in require at C:/Documents and Settings/Asehujiko/Bureaublad/DF/lifevis/site/lib/Coro.pm line 64.
BEGIN failed--compilation aborted at C:/Documents and Settings/Asehujiko/Bureaublad/DF/lifevis/site/lib/Coro.pm line 64.
Compilation failed in require at Lifevis/Viewer.pm line 87.
BEGIN failed--compilation aborted at Lifevis/Viewer.pm line 87.
Compilation failed in require at Lifevis\Launcher.pm line 19.
XY .5 Cross Section
##\./##
###.### --YZ.3
\##.##/
....... --YZ.5
/##.##\
###.###
##/.\##
YZ .3 Cross section
#######
### ###
### ###
### ### --XY.5
### ###
#######
#######
YZ .5 Cross section
\#####/
... ...
... ...
... ... --XY.5
... ...
/#####\
#######It would probably look more better both in walls and on top of them, and not too hard to make.
Jpeg artifacts hurt my eyes.
I wonder how much resources could be freed up using sprites?..
Just musing, though. ::)Spoiler (click to show/hide)Spoiler (click to show/hide)
This mockup reminds me by the way on Bluebytes "Albion" that had to an mixed 2D/3D world in some parts of the game.
So, is it a right time to start accumulating\pixelarting nice-looking sprites? ;D
Can't load 'C:/Program Files/DF/site/lib/auto/Coro/State/State.dll' for module Coro::State: load_file:This application has failed to start because the application configuration is incorrect. Reinstalling the application may fix this problem at C:/Program Files/DF/site/lib/XSLoader.pm line 70.
at C:/Program Files/DF/site/lib/Coro/State.pm line 106
BEGIN failed--compilation aborted at C:/Program Files/DF/site/lib/Coro/State.pm line 112.
Compilation failed in require at C:/Program Files/DF/site/lib/Coro.pm line 64.
BEGIN failed--compilation aborted at C:/Program Files/DF/site/lib/Coro.pm line 64.
Compilation failed in require at Lifevis/Viewer.pm line 87.
BEGIN failed--compilation aborted at Lifevis/Viewer.pm line 87.
Compilation failed in require at Lifevis\Launcher.pm line 19.
M
MgM
M
M=millstone, g=gearbox
the model for workshops overlaps, severelyJeez, what a round about way of doing things. Isn't DF open source? Why not?
Will you make Dwarf Fortress open-source so the community can speed development and fix bugs?
No. We don't want to associate with other people at a quasi-professional level, since this would make development less enjoyable. This is not a job for us; it is our personal mission.
But will you make Dwarf Fortress open-source for forks and tinkering?
No. Heavily diluting Dwarf Fortress adds a strong element of unpredictability to our support, and your donations are our sole source of income. While donations might not be affected at all, it's not a risk we can take at this point if the project is to continue.
No new screenshots, or anything today, however, big news, Lifevis will now easily work with these Dwarf Fortress versions:
v0.34.07, v0.34.10, v0.34.11
You can download it here: https://github.com/wchristian/lifevis/zipball/v0.258_004
read_file 'adresses/v0.34.07/version.lisp' - sysopen: No such file or directory at Lifevis/ProcessConnection.pm line 114.
For me the biggest problem with Lifevis is speed. And yeah I tried the latest version and it is indeed better but not much (sorry to say that).Thanks for the feedback. One more reason to get started on that.
It is just so painfully slow that it is annoying to use even as static visualizer, and it is supposed to be realtime one...20 seconds for a single Z-Slice? How did you arrive at that measurement? The slowest i have seen was 1 second on my machine. What kind of numbers are you seeing in the "Calls" line of the debug output? What kind of hardware are you running? As for how it is rendered: It generates DisplayLists for each slice, by using glbegin, glDrawArrays, etc. The bug here might be that DisplayLists are deprecated and i assume that they're performing worse as a result of that.
One z-level of one map tile (48x48x1 tiles) takes like 20-30 seconds to render. I have no idea why is it so slow. It doesn't even draw that many polygons actually. I have worked with OpenGL and could draw much more stuff much faster even when using the simplest functions like glBegin, glVertex and glTexCoord.
It seems to me that you are either doing something horribly wrong or have some bug in the code and this why it is so slow, because I do not see any other reason why it could be that bad.
20 seconds for a single Z-Slice? How did you arrive at that measurement? The slowest i have seen was 1 second on my machine.
What kind of numbers are you seeing in the "Calls" line of the debug output?
What kind of hardware are you running?
Modification of non-creatable array value attempted, subscript -16 at Lifevis/Viewer.pm line 1348.
[snip]Ok, wow, thanks a lot for the feedback. I thought i was going insane here!
Many useful :words:.
[snip]
Use of uninitialized value in numeric gt (>) at Lifevis/Viewer.pm line 917.Wow, that's weird and should literally not be able to happen. I've uploaded a bandaid release: https://github.com/downloads/wchristian/lifevis/Lifevis%20v0.258_006.zip
I get this on attempting to run lifevis. It gets so far as rendering a couple of... I guess in minecraft you'd call them chunks. A few large tiles of play area, and then closes and puts that line into error.txt.
Just reporting a bug. Version 34.11
Looks like a failed include or equivalent?Ugh, a debugging aid moved the process one dir up and as such couldn't find the necessary deps anymore. Fixed release: https://github.com/downloads/wchristian/lifevis/Lifevis%20v0.258_007.zip
Well it runs now. I tried it on a new save, and it works fine there.Phew! I was worried there. :)
Keyboard input is a bit wonky, tends to crash out after freaking out on me and flipping the view all over the place.Yeah, that is a known bug i haven't gotten around to debugging yet. It worked perfectly under XP and with Win7 it is borked. I suspect it's not sending the keyup correctly. You need to control things through DF for the time being. :(
Modification of non-creatable array value attempted, subscript -9 at Lifevis/Viewer.pm line 1347.That one was mentioned earlier and i'll be looking at it tomorrow i hope! :)
Still fails on the old save. I figured something stupid about my already fairly stupid above-ground fort. Who knows what exactly.Can you please get a dropbox account and share it from there? That should be the easiest and most convenient way for you. I can look at it tomorrow then.
I don't really know where to put the save. But the current error is something different than before:
ReadProcessMemory failed with code: 299 at Lifevis/Viewer.pm line 112.That is very interesting. It indicates that Lifevis is trying to read from a memory position that is undefined, so somehow i'm trying to read from a cell that is not actually initialized and i have not yet seen any of those in my tests. If that is from your save, then i'd REALLY love to have it! :D
Lifevis::Viewer::_ReadMemory(268, undef, 676) called at Lifevis/Viewer.pm line 919
Lifevis::Viewer::landscape_update_loop called at C:/Documents and Settings/.../Desktop/Lifevis v0.258_007/site/lib/Coro.pm line 691
Coro::_coro_run called at Lifevis\Launcher.pm line 0
Anyway, neat little tool when it works. I always think folks who go out of their way to make things for free for a community deserve thanks for it. So thanks!Thanks for the kind words. :)
I have the worst luck with utilities, so who knows, maybe you won't even see the same bug.Your bad luck is my good luck. :)
Quote from: error.txtModification of non-creatable array value attempted, subscript -16 at Lifevis/Viewer.pm line 1348.
ReadProcessMemory failed with code: 299 at Lifevis/Viewer.pm line 112.
Lifevis::Viewer::_ReadMemory(268, undef, 676) called at Lifevis/Viewer.pm line 919
Lifevis::Viewer::landscape_update_loop called at C:/Documents and Settings/.../Desktop/Lifevis v0.258_007/site/lib/Coro.pm line 691
Coro::_coro_run called at Lifevis\Launcher.pm line 0