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

[Akhier the Dragon hearted]

this looks so awesome. the graphics remind me of the game xcom: UFO defense which was another awesome game.

[Hydra]

I thought the data of your whole embark location is stored in your memory. You just read that out and visualize it. Every input from the GUI would have to be forwarded to DF, tough.

Actually no. The whole location is divided in 16x16 blocks for every Z level. If you haven't 'touched' a certain block, it's not loaded into memory yet. You can force this by designating a large zone for mining on the bottom Z level, and then undesignating it. That's why you need to do that for tools like Reveal, the data simply isn't there yet.

[Hydra]

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

[AxelDominatoR]

External hooks to use different rendering engines? That would be less work for Toady than making a new graphical system, and many frontends could be used ( textual, graphical 2d, graphical isometric, etc ).

Let's say a hook for sending input and a few hooks to retrieve location blocks from memory. He should just make a sort of "virtual 3d screen" to be accessible. The current renderer could continue to work as-is right now ( maybe just a parameter to switch rendering entirely off if using an external engine ).

I love isometric art, but it would be cool to be able to play DF over SSH in ncurses, too!

[Solifuge]

For the hypothetical GUI, you could easily select a view mode from the Menu. Mode 1 being 3D Isometric, and  Mode 2 being top-down ala traditional DF, but with full graphics support.

Also, I heard a rumor about the graphics library being made public in the next release, so this may become infinitely more feasible.

[Footkerchief]

Also, I heard a rumor about the graphics library being made public in the next release, so this may become infinitely more feasible.

It was wrong, or didn't think what you meant.  The rendering code is open-source.  But it's still the same old tiles.

[stormbringer951]

this looks so awesome. the graphics remind me of the game xcom: UFO defense which was another awesome game.

Dwarf Fortress + XCOM. Being able to control dwarf squads properly, as well as actually do proper inventory management for your armies in the Army Arc. Mmm....

[sofakng]

This looks absolutely beyond amazing.  Isometric tile games are by far my favorite...

I've been fooling around writing an isometric engine actually and made quite a bit of progress... (mouse-clicking is finished except for stacked objects)

If you don't mind me asking, what pseudo 3d tiling program did you use to create those graphics?

Depending on the language you will be writing this in I might be very interested in helping...

[0x517A5D]

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.

[0x517A5D]

One of the bigger problems in doing a translation is that often the target language's phrases are longer than the English ones.  This is especially common in German, as it is a wordy, agglutinative language.

>>I am working my way around it by abridging which, in some cases, provides garbled stuff, but the goal of the project is not to provide a perfect translation, just an (mostly) understandable one. But, pretty much, I am building that entire project on one of my unproven assumptions, so it may just as well go haywire.

The utility German Menu -- Deutch Menue shows one way around that, by allocating entirely new memory and changing the string pointers in the code.

>>Above my league.

That utility is open source under the MIT license -- feel free to do whatever you like with it. 

The other problem in doing a translation is that the strings in DF are "merged" -- that is, when multiple pieces of code use the same string, they all point to a single copy of that string.  The above utility does not solve that.  (I have some thoughts on a solution, but nothing written.)

>> Nothing I can do about.

The third problem, which I have no ideas on solving, is phrase ordering.  If the target language has different noun/verb ordering, for instance, most of the sentences which are built from multiple pieces (e.g. a piece of text, then a dwarf name, then another piece of text) will be ungrammatical.

>>That is, I most probably won't be able to solve the grammar problems. But if you can make out the meaning, it's okay for me.

So, I just tried my work up to this point out. Turns out, a) doing strings longer than the original english string length seems to mess the system up. A shame.
And b) there seems to be a hardcoded plural somewhere, which is also looking uglier than I'd tolerate. Alas, I didn't figure out how to convert the hex into legible code I'd be able to hack into, so I'm pretty much stuck.

If you can hack C at all, do look at that menu utility.  The actual process editing is fairly well encapsulated.

I really think manual translation by hex-editing the binary on-disk is the wrong way.  It doesn't scale, and it would have to be redone for every new version.

[Solifuge]

This looks absolutely beyond amazing.  Isometric tile games are by far my favorite...

I've been fooling around writing an isometric engine actually and made quite a bit of progress... (mouse-clicking is finished except for stacked objects)

If you don't mind me asking, what pseudo 3d tiling program did you use to create those graphics?

Depending on the language you will be writing this in I might be very interested in helping...

I actually created them all by hand, in a pixel-art oriented program (GraphicsGale). The tiling was done by hand as well.

Also, thus far I don't have a programming language of choice, as I can barely program my way out of a paper bag. A few semi-interested folks on IRC have mentioned C++ (the only language I can use semi-effectively). Did you have any ideas?

Here are the tiles I've completed so far, most of which went into the above images. (The dwarves are not my work, however)


The big blocks are used for Solid Tiles, and the flat surfaces are used for Floors. Darker tiles are used to signify "Inside" or "Subterranean" tiles. Black Tiles are Unexplored Areas, and Half-Blocks are for cutaway walls. C-Blocks signify whether Constructions can be built on the tile. '!'s are for Strange Moods and Signifiers, and the Bracket-Cube would replace the X cursor.

[LegoLord]

Cool.  But won't you need to make to make the background in that transparent? (Never mind, stupid question.)

[Footkerchief]

Cool.  But won't you need to make to make the background in that transparent?

It's fairly obvious from the mockups that he already has transparent backgrounds and only added the cyan for our viewing pleasure.

[Impaler[WrG]]

Also, thus far I don't have a programming language of choice, as I can barely program my way out of a paper bag. A few semi-interested folks on IRC have mentioned C++ (the only language I can use semi-effectively). Did you have any ideas?

I'd recommend an SDL engine with heavy use of SDL_Surface for your block pieces.  You don't really need a functioning Camera of anything fancy like I've done with OpenGL, just bliting down surfaces should be all you need.  If you know a little C++ go with that unless you know something else which has a good SDL wrapper like Python and the PyGames library.  I'd also recommend you learn to use Version Control software if you don't yet know any of them, I recommend Subversion cause I know it and its easy to get free copies of it but their are others that are just as good.

[AxelDominatoR]

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

Hard, but feasible.

Never said it would be easy. 

I have some experience in SDL/OpenGL programming, by the way. Not much free time to start a project on my own but I could help here and there if really needed.