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

[Solifuge]

Just posting to say that this topic brought me to an entirely different task. So, I open the DF.exe with a hexviewer to see whether, by chance, the code is still legible... no chance. I do, however, see the menu strings and stuff.

Now I'm currently translating Dwarf Fortress to German. It will probably be ugly and is most definitely a shitload of hard work. But it's getting done =)

Glad to inspire you, Errol! That sounds great too!

Hmmm, this gets me thinking; I wonder if there are ways to retrieve what lines of text DF is looking for; if so, you can potentially figure out what menus the program is in.

Aren't there programs like Dwarf Foreman that pass both standard and non-standard commands back to Dwarves, and can change the makeup of individual tiles? I thought I'd read about one such program which also retrieved the full combat text as you see in Adventure Mode, and displayed it.

If that is possible, retrieving Text shouldn't be any problem at all, and what menu text is being retrieved may make it possible to reconstruct possible menu choices. Does anyone know what program I'm talking about, and know if it is possible?

[HonkyPunch]

This is very nice.
I had a similar idea, but i cannot match your talent-ed-ness so hell yes!
I think it'd be pretty sweet if the game had Derek Yu's Spelunky style sprites, where everything is kind of cute looking, but can horribly horribly maim you.

[AncientEnemy]

I'm no programmer, but something I've always wondered about; wouldn't one method of doing this be to use a custom tileset in DF (designed to be easily recognizable to the GUI program), and have the GUI program quite literally 'look at' the DF window to get its information? the boxes around the edge of the DF window would provide a reference point, and keeping track of which menu was open/where the cursor is would be simple. Obviously alot of objects would still look like other objects (trees and drawbridges etc) but I don't think there's going to be a way around that without toady providing more graphical support. You'd only be able to view activity on the current z-level, but the GUI could 'remember' the layout of the other z-levels.

Would such a method be technically feasible? I know text recognition can be resource intensive but since the tileset would be pre-defined, and could be simplified down to 'braille' (each tile could essentially just be dots conveying the 'number' of the tile), the system wouldn't have to do any guesswork.

I really do hope there's a decent graphical frontend for DF someday. I certainly mean no disrespect to the people who love ascii, and I do like using my imagination, but for me there's just an irresistible charm about isometric rpg graphics.

[Ampersand]

While technically possible, that would probably require a much more intensive program with image recognition software running inside of it. Would just slow things down, really.

[LegoLord]

I believe the utility was Dwarf Companion, Solifuge.

[0x517A5D]

Now I'm currently translating Dwarf Fortress to German. It will probably be ugly and is most definitely a shitload of hard work. But it's getting done =)

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.

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

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.)

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.

[Hydra]

Just saw the image in another thread, and I just want to point out that this is just totally totally awesome! Pretty and cute!

I certainly hope Toady will consider moving to something like this!

Regarding the programming: it would be a pain to build something like this that interfaces with DF, reads the memory all the time, and then sends it commands. This should just be 'inside' DF.

[Vince]

I'm no programmer, but something I've always wondered about; wouldn't one method of doing this be to use a custom tileset in DF (designed to be easily recognizable to the GUI program), and have the GUI program quite literally 'look at' the DF window to get its information?

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.

[AxelDominatoR]

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.

Mmm, Kobold Quest still uses the same engine as DF? If yes, it's opensource and one could take a look at it to ease the search for the right instructions in the DF executable.

[Andir]

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.

Mmm, Kobold Quest still uses the same engine as DF? If yes, it's opensource and one could take a look at it to ease the search for the right instructions in the DF executable.

The graphics have been completely reworked through the new OpenGL/SDL 40d# versions linked in the News links up top.

[AxelDominatoR]

Battle Champs, then?

[Errol]

Now I'm currently translating Dwarf Fortress to German. It will probably be ugly and is most definitely a shitload of hard work. But it's getting done =)

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.

[Puck]

Sheesh, I wouldnt care if I could NOT send any input from that pseudo 3d output back to DF.

I'd be all happy in the pants already if lifevis looked like the screenshot in the first post.

Seriously gimme that SNES feeling on screen 2 while I play DF. rather yesterday than today, its THAT cool.

[DgnBiscuit]

I seem to remember once seeing something that seemed to indicate the DF wasn't particularly good at using multicore processors, i.e. it put all it's load on one core. If that's still true, I don't think you'd have to worry much about slowing down DF with the 3D graphics if you could figure out which CPU DF is using and load balance on the others. As for menus, etc..., I don't think I'd mind just having them displayed the same way; just do a direct pass-through. Cursor navigation for designations might get hairy though....

-D.B.

[Ampersand]

By that you mean, it doesn't use multiple cores at all. It merely sticks in one processor with one thread.

So, yeah, a third party program would have no problem running secondary to it on another core, but not everyone has that capability.

Secondly, there are other bottlenecks. Dwarf Fortress eats a large amount of RAM, and the SDL versions do depend a bit on the video card as well.