Print

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

[Digitalghost]

Hey all,

I don't know if this has been mentioned before, but I would like to see a DF Graphics API.

What this means is, some way that people with 3d graphics experience can create a 3d interface for DF.

It could be as simple as this:

A way to get the letter & color at each x,y,z location.

A way to get the letter & color of GUI text at each x,y location

I thought about doing some kind of periodic screen grab and then figuring out the information from there, but it would be pretty difficult.  If there was a way to get at the information either through a .h file or through some kind of message passing (ethernet, filesystem, whatever), then people with graphics experience could help make new DF interfaces.

Of course a less naive approach would be to make available what is at each x,y,z location (tree, elephant, etc. etc.), but in the short-term even if it was just the letter and color at each cell, that would be good enough for a proof-of-concept.

I have written a 3d engine that I think will work with DF if I had some kind of interface.  It was originally for a 3d roguelike game that I worked on for a couple of years, but it's generic enough to work with any 2d/3d ascii-art game

[Derakon]

This would involve Toady making changes to the game since that data isn't available otherwise. Toady has stated that he's leery of making such a change to the game engine, as he doesn't want to get into a dependent relationship with a third-party developer.

[Digitalghost]

quote:Originally posted by Derakon:
<STRONG>This would involve Toady making changes to the game since that data isn't available otherwise. Toady has stated that he's leery of making such a change to the game engine, as he doesn't want to get into a dependent relationship with a third-party developer.</STRONG>

Fair enough.

I guess I could always grab the contents of the window and try to figure out the context from there.

If I come up with anything, I'll definately let you guys know.

[TheSpaceMan]

quote:Originally posted by Digitalghost:
<STRONG>

Fair enough.

I guess I could always grab the contents of the window and try to figure out the context from there.

If I come up with anything, I'll definately let you guys know.</STRONG>

Like mentioned on other threads, amongst them my df bot thread, the "easiest" fastest way would be to "hack" the memory, that is be able to read for each tile what its suposed to be trough direct memory access. The 3D df viewer does this but is to slow to work realtime, I think it would be possible to use that tech to do something, the problem is actualy that there is a risk that the 3d interface would lag behind, since your renderer in this case wouldn't be in sync with the update of df, and there for you might read memory thats in the middle of being altered.

I understand Toadys standing not to want to be involed with other developers and i Agree, even if we love DF the game still is his vision and for those who disagree there is allways the possibility to make your own game.

I plan myself to contact some of the people that have done some work agains the memory of df (assorted tools) to get some hints and tips what to think about and help, if someone will help, thats an entirly diffrent question. Me myself would rather have access "header" to manipulate the world gen, but one can only hope what when Toady feels that his work is complete, He might allow bigger access.

All this said, I am all for his standing of close Source projects.

[ April 28, 2008: Message edited by: TheSpaceMan ]

[Jifodus]

The fastest way is to inject a rendering library into the DF process and hook rendering functions. I think it is the only possible way to make a realtime 3rd party display.

Trying it any other way would be:
(1) Slow (context switching for ReadProcessMemory/WriteProcessMemory)
(2) There is no guarantee of data sanity unless the DF process is paused (even still there can be trouble).
(3) Inefficient, either because of (1) or you have to buffer all the information which doubles the memory requirements.

Probably the most compatible way to inject the custom library (without causing DF to crash) is by editing the executable so it loads the library at the start, then hooks can be created in the DllMain of the library.

The 3D viewer is slow because it's written in a scripting language and I think it's optimized for a static scene.

[Digitalghost]

quote:Originally posted by Jifodus:
<STRONG>The fastest way is to inject a rendering library into the DF process and hook rendering functions. I think it is the only possible way to make a realtime 3rd party display.

Trying it any other way would be:
(1) Slow (context switching for ReadProcessMemory/WriteProcessMemory)
(2) There is no guarantee of data sanity unless the DF process is paused (even still there can be trouble).
(3) Inefficient, either because of (1) or you have to buffer all the information which doubles the memory requirements.

Probably the most compatible way to inject the custom library (without causing DF to crash) is by editing the executable so it loads the library at the start, then hooks can be created in the DllMain of the library.

The 3D viewer is slow because it's written in a scripting language and I think it's optimized for a static scene.</STRONG>

Actually, now that I think about it, I can't use screen-grab techniques because DF uses openGL so it will not render to the actual desktop, but instead go straight to GPU memory.

I would love to port my 3d engine to DF, but I'm not going to waste my time trying to hack the memory, especially since the game updates so frequently.

I understand Toady not wanting to cause version fragmentation or header file freeze by having tools that might only work for a certain version of DF, so I guess I'll move on to other things.