Print

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

A) Angled Square

30 (31.3%)

B) Smoothed Square

21 (21.9%)

C) Angled Circle

39 (40.6%)

D) Smooth Circle

6 (6.3%)

Total Members Voted: 95

[jester]

got my fingers crossed that someone could make something like this work.  Ive been playing DF for about 3 years now and think its the best thing to happen to gaming since the invention of pong.  My biggest issue is trying to get other gamers interested.  Standard response is "Jesus christ look at all the stuff you can do, thats awsome!  when it gets a GUI interface let me know."    I love the fact that DF is the product of one mad bastard (basically) with a vision rather than a team who would end up making the same bland crap but the interface we have is always going to be accepted by a small percentage of nutters rather than the general populus.

  Sorry I cant offer anything but moral support, but you get that in spades from me.

[sofakng]

Actually, I don't know much about this, but can you read the map information somehow while you play Dwarf Fortress or how was this going to be accomplished?

[Footkerchief]

Actually, I don't know much about this, but can you read the map information somehow while you play Dwarf Fortress or how was this going to be accomplished?

Yes, it's already been done with Mithaldu's Lifevis, which should be tried by anyone interested in discussing the feasibility of this project.

[Jifodus]

A method would be to "inject" the graphical isometric engine code into the DF executable, substituting the calls to the "ascii" standard renderer with calls to the Iso renderer. That would require a major understanding of DF rendering engine internals, but is feasible. Hard, but feasible.

Terribly hard.  Trust me on this.  Injected code is hard.

What I think would be feasible is injecting hooks which pass a windows message to the rendering process.  "Hey, I have finished a game frame, so copy my memory now."  Sending a message is easy.

Then stall until they either get a message back (receiving a message is hard, since we would have to hook the game's actual message loop), or wait for a memory location's value to change (easier, but wastes CPU cycles).

Oh, the renderer could put DF to sleep then wake it up again.  No problems there.  And thinking about it, the DF hook should attempt a context change to the renderer immediately after sending its message.  (How?  Sleep(0)?)

The renderer should be multithreaded and "double-buffered" so that it can render from the previous frame while sucking the current frame out of DF.  It should not be a lock-step process.  (Except on a single-core system, which might see minor gains by being lock-step.)

Lots of should's.  I can do a hook as described above, I can't do the other stuff.

I already have been working on a design idea for this. It is possible to hook the SwapBuffer function, in the SwapBuffer function it snapshots memory and pipes changes to whoever is interested.  I was/am planning on stuffing code for that in my opengl32.dll wrapper.

If/when the renderer gets it's own thread, then it gets much more difficult.  Though from when I last looked at the main loop (pre test versions), there were other points where hooking a function can be done.  In addition, with the new versions, it's probably is much easier to do this type of hooking, because we can create a specially modified SDL.dll that can find out exactly when a new frame starts (e.g. hook SDL_GetTicks which is called at the beginning of each main loop).

No code patching required.

Edit: And the whole reason I was going to post in the first places is that, when you manage to get some code to draw a map to the screen I'll see about finding time to do integration with DF.

[AxelDominatoR]

Lifevis seems a good starting point to me.

[worldspawn]

Up down staircase can be a spiral if there's still issues going on with it. I'm halfway decent with C# if people think that may be easier to work with for this. I already have some ideas of how this could go together. My only issue is I don't know how to have it read game data like the other display programs do. If I knew that I could probably meet everyone in the middle and try to create something simple.

I stress maybe, I've been pretty busy at work lately and don't know what kind of free time I'd be able to devote.

[Solifuge]

We've got some good suggestions and ideas thus far, by the sound of it... but the project needs some measure of organization. Anyone else have ideas on how feasible this is, or more info on Map Reading to share? Also, are any of you interested in collaborating on this project?

I'd really like to see this happen, and judging by the responses, so would a lot of players. Additionally, it'd be great for making this game more accessible for those unfamiliar with Roguelikes and ASCII graphics... and more players means more donations, which means Toady can keep cranking away at DF, and we can keep enjoying the fruits of his labors!

Plus, it'd just look friggin' sweet.

[Lap]

There's way too much worrying about CPU usage in this thread. Not only will it not take up much, but even if it did it still wouldn't matter. DF uses at most, one processor and most people have more than one. Just assign the visualizer to an unused processor.

[jaked122]

A method would be to "inject" the graphical isometric engine code into the DF executable, substituting the calls to the "ascii" standard renderer with calls to the Iso renderer. That would require a major understanding of DF rendering engine internals, but is feasible. Hard, but feasible.

I'm sorry, but that's not feasable, it's close to impossible. Instead of dreaming up all kinds of almost-impossible solutions, we need to convince Toady that a graphical overheal should be a higher priority than some of the other stuff he's working on

please don't pester him, I don't want him to commit suicide from the stress you'd impose on him

[LegoLord]

What good would a graphical overhaul do now?  It won't improve gameplay.  What he's doing now will at least set up for gameplay improvements (actually, it has improved gameplay, as we will have proper health care next version).

Since there are people doing stuff like this, Toady doesn't have to waste time on that just yet.

[Volfram]

Terribly hard.  Trust me on this.  Injected code is hard.

Hard, but feasible.

Never said it would be easy. 

What you're talking about isn't hard.  Adding hooks would be hard.  Your suggestion is akin to saying "why don't we transplant a chicken egg inside of a dog so the dog lays eggs instead of giving live birth."

[AxelDominatoR]

Sorry, I think I didn't express myself really well. Wrong terms meaning, mainly.

For "code injection" I actually meant writing code into a DLL that's loaded by DF. Basically what Jifodus said earlier with SDL. Once found the memory location for map tile data in memory we may simply swap rendering routines using a custom-built SDL library.

I meant "hooking" as a separate application attaching to a process and read/write memory, just like most debuggers do nowadays ( under linux using ptrace, for example ).

I know, wrong meaning as I said

[Rose]

I fully intend to make some more tiles for this. I'll post back later.

[LordZorintrhox]

Hmm...interesting idea.  And a big one; coding projects like this are complicated and error prone.  You thought seg-faults were bad?  Trying tracking these kind of seg-faults.  Sounds like a nightmare, but obviously people have done similar.

One thing that helps is Toady appears to be a reasonably accomplished programmer; the kind of changes that pop up on the dev log with regularity imply he has structured his code rather well, which I would assume might make a code injection easier, but by no means simple.

A second process would be much easier to handle, and since much of the research into the structure of DF memory, it may even be pretty straight forward to reverse engineer the map.  But here is the problem:

It is glutted, bloated, inelegant, and hackish.  Granted, the very nature of Modding, especially in the good-ol' days, is cracking the game code.  How easy the developer makes this is up to them, and the mere fact that there is enough nerdom on this forum alone to allow things like Dwarf Manager and 3Dwarf to even exist is a testament to both Toady and the community.

But an exterior program spying on the DF memory so it can render a "nicer" 3D or psuedo 3D GUI in real time I don't think helps the game itself much.  Yes, it is cool.  Yes I use 3Dwarf, yes I speak the graces of an ASCII art GUI while at the same time grinding away at graphics sets and tilesets to make the GUI look "nice," but that is because I am a geek.  At the end of the day, it is just a PSD file, just an image that uses what the game already has and does.  Building a huge thing that augments the GUI by spying on the original is cool, but not necessary.  A better investment of our time would be to develop a document specifying what the 3D interface should be, after much discussion and work, and even some prototyping.  The major hurdle in any GUI design is the design phase and the research that goes into it, something that Toady can not do on his own because he simply doesn't have the man power. 

We get away with an all-keyboard interface because that makes sense to us, and the affordances we make as geeks make it okay that the hot key for a floodgate can be any of three different keys.  I think we can safely assume that a great majority of the DF community is used to command-line OS control and programming, including HTML.  This level of arcanity (hah, that should totally be a word) is okay because we are in the trenches dealing with it anyway.  Furthermore, a single developer for a game as complex as DF is not exactly the best person to design a GUI, because he is in the middle of it.  But he is the best person to implement it, especially since this is Toady's livelihood..

So my opinion is that any work in this area should be at least a thought experiment, at most an organized, concerted effort to figure out how the hell one would actually go about controlling a game that seems to be so well suited to 2d layers and not isometric slices.  That way the Bay12 Team has a good starting place at worst, a detailed design document at best.

[Solifuge]

...So my opinion is that any work in this area should be at least a thought experiment, at most an organized, concerted effort to figure out how the hell one would actually go about controlling a game that seems to be so well suited to 2d layers and not isometric slices.  That way the Bay12 Team has a good starting place at worst, a detailed design document at best.

I disagree that an external GUI wouldn't be useful. Most obviously, a 3D graphical display would provide visual enjoyment, and would help players plan multi-z-level structures without having to piece them together in their mind like a layer-cake. It also would allow players to use a more advanced and intuitive interface, such as point-and-click commands, context-sensitive menus, windowed 2D site maps, workshop ques, and/or information screens, and so on that would improve the control and accessibility of the program.

Aside from the primary benefits, a graphical interface would help make Dwarf Fortress accessible to a wider audience of players, particularly those who don't know what ASCII or a Roguelike is, but who love strategy games like this. In addition, a wider audience would in turn help Toady keep the project well-funded and going strong, and would help make the game more visually attractive and appealing to the public.

I definitely agree that designing an interface is one of the hardest and most important parts, and a DF GUI should definitely be well planned before undertaking such a project... but I don't think it makes much sense to focus purely on dreaming up a design without ever intending to implement it.