Bay 12 Games Forum

Quote from: mifki on November 23, 2016, 09:22:46 pm

Soon I'll start working on updating TWBT for 0.43.05. It will be 64bit only I think as I'm not keen to find offsets for and support twice more versions.

From my perspective, updates are more exciting than the alternative art systems - TwbT is the last component I need for a 43.05 pack (albeit with alpha DFHack).  Is there an expected timeline, beyond "maybe soonish"?  (I admit that this is my preferred schedule)

Honestly, I haven't looked at the 64bit binary yet. The VM I was using before for my build system was XP, so I just installed Win10 and VS2015 yesterday. I don't expect significant difficulties with finding offsets except for the multilevel rendering-related one - I don't fully remember how I found the function to patch for 32bit long time ago:( Theoretically, TWBT can support multilevel rendering even without that offset, but this haven't been done for a long time, not sure how well it works in this mode.

Meph,

Currently TWBT is limited by tiletypes present in DF. I'm not even sure what there is what is not, there are definitely different types for some floor/wall materials but you'd better look yourself. The same for other stuff - mostly for performance reasons. For example building overrides require to specify tile number, building ID and building type because I naturally have tile number, look up overrides for it, then check all matching buildings from world.buildings.other[id] (that's why I need ID so that I don't check ALL buildings), compare their types and then find the one located on the current tile. Of course I can also check materials, neighbour tiles and whatnot, but that would require accessing more data structures, which can be slow, especially for complex tilesets that require updating all tiles each frame ("twbt redraw_all" option).

However, if you missed it, some time ago I started to work on a new version in which I was going to implement building/item rendering "the native way" (by interposing their rendering vmethods). This is faster and should allow to implement any custom building-specific logic (e.g. different tiles for locked/unlocked doors), and also a support for animated building/item images was planned. However I suspended the development because while being a great idea, it was a difficult for me to implement - one of the problems is that if I replace the default building rendering vmethod, I need to replicate all the existing rendering logic (like different tiles for door materials, animated machines, building construction stages, etc.), and tileset authors will need to provide tiles for all the situations. I'm neither sure I'm aware of all the logic that needs to be re-implemented, nor able to get all the required tiles myself.

If you're willing/able to help with these two problems, I can continue to work on that version again.

(I think the "text-only" things you mentioned are hardcoded, so there's not much I can do.)

Is there any way to fix the adventure mode camp construction screen being black when TWBT is enabled?


It works fine when TWBT is disabled, however I cannot stand vanilla text.


Am I out of luck here?

I'll check it.

@Mifki - I've seen some good reviews for the experimental 5.70 build.  Any plans for when that will go stable and be released on Github, or are there known problems?

Nope, if it doesn't crash or at least less than before, well, consider it stable, I'll upload it to github.

I would appreciate it very much if you (or anyone who has looked at it too) could briefly explain the general format of your map data if graphics are involved.

Both in TWBT and Remote, when rendering, z-level offset (that is, how many levels a tile is below the current z-level) is stored in the brightness byte (bits 1-7). When sending over network, as you noticed, foreground and background colours are packed into one byte, however there can be only 8 background colours, so we have one bit left. When sending tiles, if a tile has different z-level than the previous one, that one bit will be set to 1, and z-level difference will be sent in the next byte. That's how multilevel works.

Now, if graphics is enabled, for creature tiles (and only for them) I need to send two bytes with the texture number instead of one. So, for each 8 tiles I insert a byte indicating which of the following 8 tiles are creature tiles (having 2 byte texture number) and which are normal tiles (having 1 byte tile number).

It may look a bit complicated, but I wanted to optimise the amount of data sent over cellular.

Thank you!

Please don't distribute these two builds until they've been tested for some time.

DAOWAce, if you could update and play for some time with redraw_all and multilevel.

Thanks for the help. I found some instruction for realcolors.

It looks installing the realcolors lua doesn't change anything in existing packs unless they are specifically modified to make use of it.

To make an item use its real color, it just needs to have its foreground color in its object file set to "100", right? And then all the background colors get displayed as normal.

realcolors.lua is just a script (btw it should go to /scripts, not to /lua) that processes all materials and sets tile colours to be real material colours. Of course it doesn't change anything unless you run it.

and what about on a mac? I see most of the instructions for pc.

Well, for Mac it's easier of course In System Preferences->Network select your network connection and you'll see IP address straight away below "Status: Connected".
Firewall is off by default (System Preferences->Security->Firewall) and if it's on, it will ask you to allow connection when you try to connect to your server.