Ankoku / df-webfort

Web Fortress
ISC License
35 stars 10 forks source link

Assist in porting to steam-edition #43

Closed KimNikB closed 6 months ago

KimNikB commented 11 months ago

Hi there! I'm currently trying to update dfplex to the steam edition but for that i'd need to recode webfort for it as well...Can you guide me through the process of how webfort works and maybe give me some pointers about how I might implement a steam-version version of it?

Alloyed commented 11 months ago

sure! It's been a minute and a half, so please take anything I write with a really big grain of salt. If my comment looks confused when you look at the code, then likely the code is correct and I'm not lol.

Conceptually, webfort works by hooking into dwarf fortress's internal "renderer" object, so it can copy out whatever the ascii tilebuffer is intended to look like on the host machine and replicate it on clients. I don't know how the steam version does this nowadays, but it's likely that this piece of the puzzle has changed a lot so I'll go into extra detail there.

plugin

https://github.com/Ankoku/df-webfort/blob/master/server/webfort.cpp architectural piece 1 is the dfhack plugin, that implements the above mentioned hook. we instantiate a "renderer wrapper" which just intercepts renderer commands and builds an internal tilebuffer for us to use later.

this is the core of how things work: https://github.com/Ankoku/df-webfort/blob/master/server/webfort.cpp#L236 (i genuinely apologize for the naming here btw) r->screen is the "Real tilebuffer". We can't access this all the time for thread safety reasons, iirc. sc is the "webfort tilebuffer". This is a read only copy that we can safely access from the server thread. i->second->mod is the "dirty buffer". it tracks which tiles have been modified, since each client last received an updated state. This is per-client: if a person just joins then their entire tilebuffer is dirty, but if only a single tile has changed then for most people you only need to send the single tile and so on.

It looks like each tile in a tilebuffer is 5 bytes. that's a weird and specific number, but I don't actually know how to interpret it off the top of my head. it's likely that this part needs to change in response to steam updates.

The underlying plugin does nothing at all special with respect to UI: it's just "here's a bunch of tiles" to web clients, and "here's a sequence of keypresses" from web clients. I don't know how safe that assumption is with the new steam UI.

server

https://github.com/Ankoku/df-webfort/blob/master/server/server.cpp piece 2 is the websocket server. this tracks connected clients, and sends them updates based on the state of the tilebuffer and so on. https://github.com/Ankoku/df-webfort/blob/master/server/server.cpp#L312 This is the "state update message". it's a handcoded binary serialization format, so have fun~

web client

https://github.com/Ankoku/df-webfort/tree/master/static This is the "web" part of webfort. this connects to the server and actually shows you everything in your browser.

Hope this all helps! I don't know anything about what's been going on recently with the steam version so if you have extra context or just want a little more information feel free to ask again.

Ankoku commented 6 months ago

whoa you nerds are still working on this, Amazing!!