Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 2 [3] 4 5 ... 184

Author Topic: Text Will Be Text - dfhack plugin  (Read 763369 times)

mifki

  • Bay Watcher
  • works secretly...
    • View Profile
    • mifki
Re: Text Will Be Text - dfhack plugin
« Reply #30 on: May 24, 2014, 11:02:43 am »

Ok, here it is.

Now plugin loads data/init/overrides.txt where you can specify additional tilesets to load and configure tile replacement based on item/building type (and possibly subtype but I don't know any values to try).  See inside the package for some docs and sorry for any bugs, I'll go get some sleep :)

Meph

  • Bay Watcher
    • View Profile
    • worldbicyclist
Re: Text Will Be Text - dfhack plugin
« Reply #31 on: May 24, 2014, 12:46:36 pm »

If this works on specific workshop tiles, you could add an unlimited amount of custom pics for workshops, as detailed as you like... just take a 256x256 png, chop it up into 16x16 tiles and build a large, 16 tile x 16 tile workshop... and voila, it will look like the original png.
Logged
::: ☼Meph Tileset☼☼Map Tileset☼- 32x graphic sets with TWBT :::
::: ☼MASTERWORK DF☼ - A comprehensive mod pack now on Patreon - 250.000+ downloads and counting :::
::: WorldBicyclist.com - Follow my bike tours around the world - 148 countries visited :::

ag

  • Bay Watcher
    • View Profile
Re: Text Will Be Text - dfhack plugin
« Reply #32 on: May 24, 2014, 01:14:35 pm »

I had a discussion with lxnt, baughn and Toady, and later on another with Taffer, Baughn and Toady. Baughn would like to update the graphics significantly, but cant work without source access. Toady understands this, but wont give this access. (which is perfectly within his right to do)

I seem to have read Baughn saying somewhere that adding too much stuff to objects makes the game crash or something, which slows down the possible rate of change. I may have an idea why this happens, and a very easy workaround would be to add some "char padding[256]" to the end of all global objects that baughn wants to grow, so that once Toady recompiles, enough space is reserved.

Regarding the plugin, manually hacking into the vtables is a very bad approach when dfhack has an already available vtable interposing API, which doesn't require any weird inline assembly, and even allows different plugins to define hooks for the same methods without conflicting.

Another thing is that renderers don't have the right to access any game objects, because rendering is run in a different thread and is only synchronized for a buffer swap. Thus, the appropriate way to do such thing is to hook the render vmethod of viewscreen_dwarfmodest (using the interposing API is a must, because other plugins already hook it), and work with the tile arrays via the Pen API. In order to make the game load the necessary tile images, you can assign one of the tiles in your bitmap as a graphical icon for something silly and impossible like "cat miner ghost" via raws, and then use findGraphicsTile to look up the index.
Logged

GavJ

  • Bay Watcher
    • View Profile
Re: Text Will Be Text - dfhack plugin
« Reply #33 on: May 24, 2014, 03:17:29 pm »

This is great. I was working on the exact same concept, but with screen captures, which would be slower.

But since you're using memory access anyway, why base it off of text area versus graphics area???

Why not just go ahead and read the exact item type and allow individual items or letters to all point to separate graphics if desired?  For example, animal traps and small mountain biomes are both in the graphics area. If using memory reading anyway, should be able to fairly simply assign separate graphics to each.

Or even, if somebody wants, using separate graphics for copper minecarts versus wooden (not just colors, separate graphics). Could set up a text file where people can just leave it blank if they want only graphics vs. text area, or they can write in whatever custom level of detail they feel like in whatever syntax is native/most convenient to write code for (they can figure it out, as long as the script makes it physically possible)
« Last Edit: May 24, 2014, 03:19:31 pm by GavJ »
Logged
Cauliflower Labs – Geologically realistic world generator devblog

Dwarf fortress in 50 words: You start with seven alcoholic, manic-depressive dwarves. You build a fortress in the wilderness where EVERYTHING tries to kill you, including your own dwarves. Usually, your chief imports are immigrants, beer, and optimism. Your chief exports are misery, limestone violins, forest fires, elf tallow soap, and carved kitten bone.

mifki

  • Bay Watcher
  • works secretly...
    • View Profile
    • mifki
Re: Text Will Be Text - dfhack plugin
« Reply #34 on: May 24, 2014, 06:09:39 pm »

If this works on specific workshop tiles, you could add an unlimited amount of custom pics for workshops, as detailed as you like... just take a 256x256 png, chop it up into 16x16 tiles and build a large, 16 tile x 16 tile workshop... and voila, it will look like the original png.

I probably will add special handling of workshops, they have empty tiles that can't be overridden this way, but for non-empty it should work now.

Regarding the plugin, manually hacking into the vtables is a very bad approach when dfhack has an already available vtable interposing API, which doesn't require any weird inline assembly, and even allows different plugins to define hooks for the same methods without conflicting.

These renderer classes are not in dfhack (and we even don't know which one is actually used), so "manually" (in quotes because that's what dfhack is doing anyway) changing vtable is the natural way to override couple methods. "Weird" assembly is required because of the special C++ calling convention used on Windows, dfhack is also doing something weird to overcome this, but I'm not sure. Again, as Warmist suggested before, there's another way to do what I'm doing, but I'll think about it later.

Another thing is that renderers don't have the right to access any game objects, because rendering is run in a different thread and is only synchronized for a buffer swap. Thus, the appropriate way to do such thing is to hook the render vmethod of viewscreen_dwarfmodest (using the interposing API is a must, because other plugins already hook it), and work with the tile arrays via the Pen API. In order to make the game load the necessary tile images, you can assign one of the tiles in your bitmap as a graphical icon for something silly and impossible like "cat miner ghost" via raws, and then use findGraphicsTile to look up the index.
Yes, threads issue is a good point, I'll think about this.
However hooking the render method doesn't seem to be the appropriate way. The idea here is to hook the update_tile(x,y) method which is called only for changed tiles, so it is fast. I have no idea what you're suggesting to do in render() instead.

Why not just go ahead and read the exact item type and allow individual items or letters to all point to separate graphics if desired?  For example, animal traps and small mountain biomes are both in the graphics area. If using memory reading anyway, should be able to fairly simply assign separate graphics to each.

That's what I did in the latest version (see my previous post), isn't it?

Vattic

  • Bay Watcher
  • bibo ergo sum
    • View Profile
Re: Text Will Be Text - dfhack plugin
« Reply #35 on: May 24, 2014, 07:41:40 pm »

Is there a way to give grass tiles a specific character and soil floors a different one?
Logged
6 out of 7 dwarves aren't Happy.
How To Generate Small Islands

mifki

  • Bay Watcher
  • works secretly...
    • View Profile
    • mifki
Re: Text Will Be Text - dfhack plugin
« Reply #36 on: May 24, 2014, 07:55:14 pm »

Is there a way to give grass tiles a specific character and soil floors a different one?

Grass characters can be easily changed in raws plant_grasses.txt after setting VARIED_GROUND_TILES to YES. What this plugin allows is to use more tiles (numbers, letters) that are now free. However as far as I know there are some unused tiles even without any plugins if you need only couple.

But that's only for grass, in general no, this plugin looks only for items/buildings on a tile currently, however other tile attributes can be added, I think.

Vattic

  • Bay Watcher
  • bibo ergo sum
    • View Profile
Re: Text Will Be Text - dfhack plugin
« Reply #37 on: May 24, 2014, 09:23:42 pm »

I had forgotten that grass was now in the raws.

Cheers.
Logged
6 out of 7 dwarves aren't Happy.
How To Generate Small Islands

ag

  • Bay Watcher
    • View Profile
Re: Text Will Be Text - dfhack plugin
« Reply #38 on: May 25, 2014, 02:11:05 am »

These renderer classes are not in dfhack (and we even don't know which one is actually used), so "manually" (in quotes because that's what dfhack is doing anyway) changing vtable is the natural way to override couple methods. "Weird" assembly is required because of the special C++ calling convention used on Windows, dfhack is also doing something weird to overcome this, but I'm not sure.

Manually means doing weird things, with hard-coded indexes that would break if stuff changed, or if another plugin did the same thing, and inline assembly, instead of a supported API.

What dfhack does is described here.
« Last Edit: May 25, 2014, 02:35:31 am by ag »
Logged

mifki

  • Bay Watcher
  • works secretly...
    • View Profile
    • mifki
Re: Text Will Be Text - dfhack plugin
« Reply #39 on: May 25, 2014, 02:33:21 am »

Anyway, these classes are not in dfhack, so it's pointless to talk about what would be possible to do if they were there.

ag

  • Bay Watcher
    • View Profile
Re: Text Will Be Text - dfhack plugin
« Reply #40 on: May 25, 2014, 02:35:39 am »

Anyway, these classes are not in dfhack, so it's pointless to talk about what would be possible to do if they were there.

The reason dfhack does not really define renderer classes other than the base one, is that in the linux version they are located in a separate library, so their vtable pointers are hard to specify. Also, messing with renderers is also not something to be undertaken lightly because of the threading limitations; it is also not needed unless you are doing something well beyond the current capabilities, like warmist's lighting plugin. However, when you are going that far, you might as well subclass the base class and implement vmethods normally.
Logged

mifki

  • Bay Watcher
  • works secretly...
    • View Profile
    • mifki
Re: Text Will Be Text - dfhack plugin
« Reply #41 on: May 25, 2014, 02:51:57 am »

Also, messing with renderers is also not something to be undertaken lightly because of the threading limitations; it is also not needed unless you are doing something well beyond the current capabilities, like warmist's lighting plugin.
The first part of my plugin (for separate text font) doesn't have any threading issues as it does not access game objects. And renderer's update_tile() that exists specifically to update texture coords for changed tile is the best place to specify different coords in terms of speed and logic.

However, when you are going that far, you might as well subclass the base class and implement vmethods normally.

Again, I agree that the way it's done in rendermax is possibly better. But I did it how it was easier and required less code, especially I didn't care about Windows and assembly code it would require. It was my right, wasn't it?

Taffer

  • Bay Watcher
    • View Profile
Re: Text Will Be Text - dfhack plugin
« Reply #42 on: May 25, 2014, 03:02:25 pm »

I only just noticed this today, but I'm very excited about this. As Meph mentioned, we tried to get some movement going on the graphics a while ago, but Toady doesn't want to open up the code. To my understanding, however, he might accept patches, so long as he understands the code. Worth seeing if this can go into the main game, as (to me) this is game changing. It always bugged me seeing great artists hindered by Dwarf Fortress limitations. Precisely the sort of patch to the game I was hoping for. I'd love to see a Dwarf Fortress doesn't need "pure ASCII" sets like mine around anymore because the many graphics limitations are fixed. (Probably still a long time coming, unfortunately.)

Hopefully it can get accepted upstream.
« Last Edit: May 25, 2014, 03:23:36 pm by Taffer »
Logged

PeridexisErrant

  • Bay Watcher
  • Dai stihó, Hrasht.
    • View Profile
Re: Text Will Be Text - dfhack plugin
« Reply #43 on: May 30, 2014, 07:25:08 pm »

PTW, this is the coolest display-thing I've seen in a long time.  I'm looking forward to trying out the windows version after my exams!

But since you're using memory access anyway, why base it off of text area versus graphics area???
Why not just go ahead and read the exact item type and allow individual items or letters to all point to separate graphics if desired?
And this would be (for me) even better than Caldfir's stonesense overlay.  So many display upgrades...
Logged
I maintain the DF Starter Pack - over a million downloads and still counting!
 Donations here.

palu

  • Bay Watcher
    • View Profile
Re: Text Will Be Text - dfhack plugin
« Reply #44 on: May 30, 2014, 08:23:29 pm »

...Holy crap.
This is one of the most beautiful things i've ever seen. Maybe even better than rendermax.
Logged
Hmph, palu showing off that reading-the-instructions superpower.
The internet encourages thoughtful, intelligent discussion and if you disagree I hate you.
Pages: 1 2 [3] 4 5 ... 184