Print

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

[jeancallisti]

Hello,

I have a personal project I'd like to kick off on DF and I don't know how to start.
My goal is to have a program written either in C++ or Lua, that would scan very quickly (let's say at least 30 times/second) all the characters displayed in the DF window.
I don't know what's the best approch to that :
1) something external to DF (with the proper charset/skin it shouldn't be too hard to code a fast character recognition thingie)
2) something internal to DF: does DF Hack allow to read memory in order to know what's displayed in DF, almost real-time?

Tell me what you think.

[Godlysockpuppet]

 (let's say at least 30 times/second)
Right there. That's going to be an ENORMOUS hit on your fps.
Also.... what is the point of this?

[Putnam]

Check out the source for DFTerm3

[jeancallisti]

OK I will. And it could be 10 or 5 times per second.
But still: does DFHack expose the characters currently displayed on-screen? I don't know to what extent it allows to manipulate DF's in-memory data.

@putman : I've quickly checked it out and this seems to be a great clue towards my goal. Thanks a lot!

[Quietust]

does DFHack expose the characters currently displayed on-screen?

Yes, it does, provided you check it at the appropriate point in time. The DFTerm3 DFHack plugin seems to just grab the screen state whenever the remote client requests it, so it might be prone to errors (in the form of grabbing the screen contents in a half-updated state).

If you inject your own Renderer object (as the experimental "dfstream" plugin does), then you can capture every frame DF renders and do whatever you want with it (in the case of dfstream, it sends it through a TCP socket so others can look at it, plus it forwards the data back to the currently configured renderer so you can keep playing the game).

[jeancallisti]

The DFTerm3 DFHack plugin seems to just grab the screen state whenever the remote client requests it, so it might be prone to errors

Well that's a relief. It's all in Haskell. Ouch! Crisis averted.

If you inject your own Renderer object (as the experimental "dfstream" plugin does),...

That's exactly what I want!

[jeancallisti]

I'm new to Dwarf Fortress programming (i.e. DFhack plugin programming).
Where is "df/renderer.h"? Is it part of the DFHack project, or is there a DF SDK? I couldn't locate that file in the DFHack github.

[Putnam]

It's generated from this.

[jeancallisti]

Thanks again for answering.
I'm an ok programer but i'm an awful compiler. What do you mean "generated from" ? Is it all taken care of by CMake and/or  XML::LibXML and XML::LibXSLT, or am I missing a step? I'll ask the question again if I fail to follow the instructions in the "Windows" section of the tutorial.

Back on-topic: i'm wondering what would be the smartest thing to do:
- implement my very own renderer class,
OR
- simply connect (locally) to dfstream as a client, using the services it offers. Is it actually functional?

[jeancallisti]

bumping my question about dfstream ^

[Warmist]

Can't answer what would be the best for you (because i don't know WHY you would want to scan the screen) but imho it would be better to make your own renderer. Dfstream was made for a particular reason and you would have to work around your ideas to fit the dfstream. Also if you really need speed the custom renderer would be faster than renderer+tcp/ip to get the buffers

[jeancallisti]

Can't answer what would be the best for you (because i don't know WHY you would want to scan the screen) but imho it would be better to make your own renderer. Dfstream was made for a particular reason and you would have to work around your ideas to fit the dfstream. Also if you really need speed the custom renderer would be faster than renderer+tcp/ip to get the buffers

Makes a lot of sense. Thanks!

[jeancallisti]

Basically, what I want to do is :
- capture the whole Dwarf Fortress screen (map AND gui on the side -- for now I'm not too worried about plugins additional windows, like Dwarf therapist and such) every once in a while (I've reduced my goals again: 5 times/sec ought to be enough)
- it needs to be a consistent state of the game (no half-rendered screen, with the upper part being the new frame, and the lower part the previous one!)
- then I run my own post-processing algorithm on the set of characters -- possibly in a separate thread.
- I have my own gui open alongside, where I ouput the results (by the way that will need to be graphical. I'll need to start looking at the way SDL can be initialized and used correctly in DFHack)

The reason why I'm reading only the final output (instead of trying to use fancy functions to get data directly from the game's core) is because I want my plugin to be as simple as possible, and to have a high maintainability. No matter what changes are made to data structure and stuff, it will still work as long as it can "read the screen", like a human. Maybe I'll reconsider that later. But for now I'm trying to whip together a quick prototype.

I'm bumping into sync problems: I don't know if the renderer class is meant to be used "as-is", and if there is concurrential access to its inner data -- or if I can just read it anytime.

I was told to get inspiration from DFTerm. But DFTerm is gigantic. DFTerm3 is in Haskell, and I'm totally unable to understand anything. DFTerm2 is in C++ -- I'll try to understand the design, but the synchronization methods are not usually what catches the eye when reading through. They're often partly implicit, if you get me.