And if you're going to directly read the DF screen from memory and send it over a network, why not have the client have a local tileset to reduce the load over the network, therefor a broadcast wouldn't take up much bandwidth.
I'm pretty sure most devices can at least draw tiles and take input.
I'm thinking about capturing the tiles and their colours before they are rendered. There would probably be problems with using the 'graphics' mode instead of plain ascii because of all the custom graphics for creatures and stuff like that. Second route is to use the same algorithm used for DFMA maps. Only make it capture images off the screen/df window and stream them instead of producing files.
Also, if the server sends the memory over the network, the client could also be one of the 3D rendering clients that could make it that people can watch DF streaming in 3D. (And if the client also can relay input commands to the server, make DF playable 3D without worrying about how slow DF will run while running the 3d client).
This is happening only when the server does memory hacking. Also, the stream has to be aggressively compressed (only send real changes, omit what the clients don't see, etc.). I'm working on a DF memory hacking library and it's progressing quite well. Still needs a lot of work to allow even basic uncompressed streaming tho... It's currently used as the memory extraction component of khazad.
But you also get a question about users with different resolutions and what to draw and such, would the client be forced at a specific resolution or something?
There's a clear distinction between the interactive player (the one getting the 'real' game) and the spectators/secondary players.
The main player has to use the current df interface with all its inherent limitations. So, no 3D - or maybe as a secondary display. You can't control the game all that well using memory hacks.
Spectators/secondaries can get the copy of the main stream or alternatively some custom memory-hacked view. Their ability to control the game is limited and probably won't see some of the details while using memory hacks.
And for multiple users getting control, I think that if there becomes a 3rd party program that does this, the server should have an admin that chooses people, or have the current chosen player be able to choose the next player.
Yes, there should be some considerations about security and stuff like that. It's mainly a problem of designing the networking part well.
Personally I find this a decent idea, although would be a lot better if implemented first party sometime in the future maybe. (Although then it'd probably turn into a DF MMO in which people do not like the idea of, even if it's just multiple fortresses being ran at once) But any discussion about DF that way probably would be better in the suggestions forum
Can't see that MMO thing happening any time soon. You would need clustering/lots of metal to run the whole world at the same time. Also, DF would have to change significantly.
It's a lot of work and I could use some more dedicated people working on stuff. I'm just a single guy - and learning as I go
How well documented is the reverse-engineering of DF's memory model? (I know there are several 3D visualizers.) At a bare minimum, you would want to be able to scrape the necessary details of what the host-player is viewing.
From the raw map data, I have the map blocks with most of their properties, most of the matgloss data, shrubs, trees, and very basic buildings/zones/stockpiles extraction. I'll be expanding on this further and adding creatures, language, items and objects-holding-items/other objects. This will take a lot of time.
got crackin'
results: 0x00664440 start of buffer.
tile size: 4 bytes- tilenum
- color1
- color2
- something
format is first height then width. Buffer is allocated for maximum size so each column is 1024 bytes away from other.
PS will try to make something similar to remote viewer...
Awesome. For which version of DF is this? I'll be more than happy to find offsets for all the current linux/windows versions when I know where and what to look for
PS: I'm really busy with khazad and its memory extractor. I'll probably add screen extraction to the library but it will take some time to finally separate it from khazad.
PPS: It's all in plain old C++.