Print

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

[lxnt]

Recently I noticed that there would be another release of the DF after all.

Also, it so happened, FDw Taffer contacted me some time ago about work that have been done on DF graphics.

All of the above makes me to post a reedited take on the the problem (it's in ReST format):

The Tile Reuse Problem And Proposed Solution.
=============================================


The problem:
------------

    - Dwarf Fortress interface is by design limited to 256 characters of 16 colors (cp437 / "ascii" + "ansi" colors).
   
    - Dwarf Fortress has orders of magnitude more information than can be unambigously expressed by that.
   
    - Relaxing this limitation is a lot of work, while there isn't even an understanding what that is to achieve.
   
    - Graphics code is old, rotten and Toady undestandably has no desire to touch it. Even if the code was in perfect
      condition, it is not his area of interest or expertise.
   
    - Graphics code can not be updated for Windows releases without making yet another full release of the game.
      Coupled with above this means that the graphics code just continues to rot.

Thus the problem is split in two parts:
---------------------------------------

    - Graphics code is old, unmaintainable and too tightly coupled with the rest of the game code.
   
    - Graphics code can not express most of the information available (since it gets the tiles, items, parts of interface
      already mapped to cp437 and baked into a single layer).

The solution also cames in two parts:
-------------------------------------

    - An easy to understand and work with, maintainable graphics subsystem, where Toady isn't required to understand
      or mess with its internals, while third parties can maintain it without any access to the core game code.
     
    - An extensible, easy modded graphics subsystem that can express most, if not all, of the information
      available without Toady having to put any work into besides a modest initial investment.
      Which also fully supports anything up from and including the original cp437 interface.
     


The first part
--------------

of the solution is pluggable renderer bound to the core game only by a strict and stable API+ABI.
Feasibility of that was demostrated in the `rendumper project <https://github.com/lxnt/rendumper>`__

The second part
---------------

of the solution was prototyped in the `fgtestbed project <https://github.com/lxnt/fgtestbed>`__

As the latter attempt has shown, graphics mods require quite a lot of information from the core game.

Designing a stable interface that is still capable of exposing enough in-game information is the current focus.

Such interface has not been prototyped because initial fgtestbed work focused on using df-structures/dfhack code,
which provides direct access to the internal game structures. Alas, this is quite complicated and unusable for
extended periods of time after each major release because changes in the data structures have to be reverse-engineered.

The existing interface
----------------------

as implemented in the rendumper prototype receives three layers of information for the entire game
screen each frame. Those are:

    - Basic cp437 rendering of the interface,
    - Creature overlay, which holds creature "texture" indices,
    - If enabled, a truetype overlay, which is a list of text strings and their screen coordinates, to be TTF-rendered on top of everything else.

The renderer knows which creature texture indices correspond to what graphics because creature graphics loading is also done
via renderer-side code (as opposed to game-side).

As you can see, core game code converts tile types and materials, as set in the raw files, into cp437 characters and ANSI color codes
before submitting all that to the renderer. This is where the tile reuse problem originates.

To get rid of it, the renderer is instead to be supplied with:

    - Original tile type and material ids.
    - A mapping from tile type and material ids into actual graphics to render

To this end, the fgtestbed prototype renderer first parses all the raw files the game has. Then it parses another set of raw files,
that describe the hardcoded mappings for stuff like constructed walls/floors ("constructions"), raw tiles (undigged walls), items and buildings.
Those files also include overrides, so that the hardcoded mappings become moddable.

This information lets it know how to render raw map data, which, generally speaking, consists of triplets of "tile_type, material_type, material_index",
plus information about water/magma levels, any construction, zone or building present in the tile (and their material),
dust/steam/cloud in the tile (and their material), any contaminants (and their material).

On top of that go items (and their material, hehe), and, finally, creatures. Oh, I forgot about projectiles. And game interface (selections,
burrows, cart routes I haven't even thought about.

Long story short,
-----------------

the solution of the tile reuse problem is to move the hardcoded mapping of all the stuff in the game from the core game code
to some kind of "raw" or resource files. And let the pluggable renderer parse and map them.

As any big project, this has to be done in many small steps.
============================================================

The first step
--------------

is to adopt the pluggable renderer architecture, as in the rendumper. This does not require any changes in the core game code.

The second step
---------------

would be to enable basic map modding. To this end:

    - Another layer is to be added to the information already supplied to the renderer, that is - (tile_type, mat_type, mat_index).
      Here tile_type is a "derived" tile type, that is, if a wall is constructed somewhere, then the tile_type is one of the wall,
      not the underlying floor or ramp.
    - Raw material information is to be exported from the game to the renderer in such a way that (mat_type, mat_index) tuple is
      easily mapped to the information from the parsed raws. Keeping raws parsing for the graphics data in the renderer allows more
      modding. If that's not acceptable (eg, worldgen-time generated materials begin to matter much), some interface to the core game
      raws database becomes necessary.
     
      Ideally, rendering info (cp437 codepoint, color) will be purged from the
      item definition raws to some kind of rendering definition raws (as is done in the fgtestbed yaml raws) (which, ostensibly, can be inlined into the item raws, but clearly
      separated and overridable)

The third step
--------------

    - Yet another layer with item representations. It would suffice to do one item per tile, but again with item_type and material.
    - The designation bitfield, whose definition would have to be fixed eternally. That would allow for nice presentation of liquid levels,
      designations, etc.


The fourth step
---------------

tbd

[Meph]

I assume you have seen this? Text will be Text

[lxnt]

I assume you have seen this? Text will be Text

Yes, I've seen it. Great work, but ultimately a dead end in my opinion for the reasons listed above.

I also don't understand how Toady's unwilingness to open code has any negative bearing on this proposal, which explicitly goes to great lengths to avoid depending on game code.

There's a fair point about having to maintain the game-side part of the interface, and it being new, to learn it first.

But I feel this time investment is at worst no different from, and is expected to be less than maintaining the old graphics code, and is required if there is to be any progress.

Now if official position is "no time will be allocated to graphics/platform-dependent code, ever", that I can understand and accept.
But all I hear is "No more source code will be released", which is quite different.

[Warmist]

Now if official position is "no time will be allocated to graphics/platform-dependent code, ever", that I can understand and accept.
But all I hear is "No more source code will be released", which is quite different.

Official stance afaik is "no time will be allocated to graphics/platform-dependent code now". It will happen later. Main reason cited was that a lot of stuff will change and Toady One does not want to rewrite (i.e. waste time).
Also i agree with: "IMAGE_FILE_LARGE_ADDRESS_AWARE on windows? why isn't it set?". I think if you know how to do that in msvc, Toady should be informed. Main reason is that he does not (usually?) encounter crashes due to memory exhaustion. Also it might be that he does not have a lot of ram to begin with.

But I feel this time investment is at worst no different from, and is expected to be less than maintaining the old graphics code, and is required if there is to be any progress.

I think current view is: graphics is broken, but features are more important. Same reason why releases take such long time - features are creeping in.

[Taffer]

Now if official position is "no time will be allocated to graphics/platform-dependent code, ever", that I can understand and accept.
But all I hear is "No more source code will be released", which is quite different.

Official stance afaik is "no time will be allocated to graphics/platform-dependent code now". It will happen later. Main reason cited was that a lot of stuff will change and Toady One does not want to rewrite (i.e. waste time).
Also i agree with: "IMAGE_FILE_LARGE_ADDRESS_AWARE on windows? why isn't it set?". I think if you know how to do that in msvc, Toady should be informed. Main reason is that he does not (usually?) encounter crashes due to memory exhaustion. Also it might be that he does not have a lot of ram to begin with.

But I feel this time investment is at worst no different from, and is expected to be less than maintaining the old graphics code, and is required if there is to be any progress.

I think current view is: graphics is broken, but features are more important. Same reason why releases take such long time - features are creeping in.

I spoke to Toady and others a few months ago about this when I tried to organize a fundraising proposal for better graphics. The reason the graphics won't be touched soon AFAIK is a general lack of detailed knowledge about how the graphics code works. Aside from the source code issue, I think he wants to fix his lack of knowledge about his SDL code, not give up control over the graphics. That could take a while though, and is comparatively low on his roadmap. He has some ideas on how to fix things, but is worried about performance if it's not done properly. He's free to step in here and contradict me of course, I'm working from his e-mail.

As far as I can tell, he might accept graphics patches if they make the code simpler and faster. I don't blame him for being cautious, however. I'd be annoyed at not grokking parts of my game as well, and giving up control over the graphics portion of the code isn't a solution to that problem. He seemed amiable to Baughn contributing further, but Baughn is (understandably) unwilling to contribute further without source access and a version control system in place.

Toady's reasonable. I hope something can be worked out, as I'm very excited at seeing what pixel artists better than I am can do with an improved graphics engine. It's a well thought out proposal.

[mifki]

Such a big changes like abandoning cp437 charset completely don't look realistic to me.

[GavJ]

So this thread can basically be summarized as "Have the game supply a complete cache of externally readable information every frame with coordinates and render-relevant stuff like tiletype and material. Then render from that only with plugins, one of which is the default ASCII graphics"  Yes?

If so, I can get behind that.  However, I don't think you're going to see that dramatic of quality increases unless you provide things like
*multiple or all z levels of info, not just what vanilla would show
*all the items in a tile, not just, for example, the one creature "on top" at the moment that vanilla would show
etc.

And doing that seems likely to cause game slowing.

[lxnt]

Such a big changes like abandoning cp437 charset completely don't look realistic to me.

It is not about abandoning anything. It is about gradually extracting the world->cp437 mapping from the core game to where it can be moved forward easier.

In fact, preserving the original look is one of the major goals, PRINT_MODE:TEXT - linux pure text interface - is to stay forever.

So this thread can basically be summarized as "Have the game supply a complete cache of externally readable information every frame with coordinates and render-relevant stuff like tiletype and material. Then render from that only with plugins, one of which is the default ASCII graphics"  Yes?

Yes. I call it a buffer, not a cache, and

However, I don't think you're going to see that dramatic of quality increases unless you provide things like
*multiple or all z levels of info, not just what vanilla would show
*all the items in a tile, not just, for example, the one creature "on top" at the moment that vanilla would show
etc.

And doing that seems likely to cause game slowing.

the buffer isn't supposed to be a complete and accurate snapshot of the world. It's just a frame. Two-three z-levels, only the top item out of the heap, etc. The effort is aimed at removing the 256 cel bottleneck and decoupling graphics code updates from releases, on windows, not making a monster of an interface that'll require top hardware to just not drop below 60 FPS on an embark.

[GavJ]

the buffer isn't supposed to be a complete and accurate snapshot of the world. It's just a frame. Two-three z-levels, only the top item out of the heap, etc.

Right, which is WHY you'd be handicapping graphics artists from doing much of anything interesting. An overhauls like this needs to be... an overhaul. Allowing people to do 3D, allowing them to show all z levels in clever ways, allowing them to depict crowds of creatures, allowing possibly even knowing trajectory vectors to show arcs fluidly if they want, etc.

Simply solving tile re-use is absolutely not worth all this effort on its own, IMO. In fact it's something I would sort of actively not want, considering how much of a sticking point this is with Toady, and the likelihood we won't get the chance to bother him twice about it successfully, you might be locking us in to no other improvements for a long time. Also, he likes to overhaul whole systems at once, fully.

However, tile reuse plus lots of other cool potential stuff like this might be worth it, for sure.

You could always just do both and have an init.ini option to choose "engine only displays 2-3 z level snapshots" versus "engine displays all z level snapshot" etc. for 2-3 different options.

[Meph]

GavJ: Wouldnt that in the end result in Stonesense?

[GavJ]

Yes and a dozen variations on stonesense for anybody who doesnt like cartoon browser game chic. And you could add in lighting shaders if you wanted, etc. OR just really snazzy UIs for navigating ASCII graphics, slicing and dicing in different ways, various methods of seeing all z levels above or below, and so on.

Plus even a stonesense clone would be a stonesense clone that doesn't have to go offline for updating for a month or two after every release.

[Meph]

Yes and a dozen variations on stonesense for anybody who doesnt like cartoon browser game chic. And you could add in lighting shaders if you wanted, etc. OR just really snazzy UIs for navigating ASCII graphics, slicing and dicing in different ways, various methods of seeing all z levels above or below, and so on.

Plus even a stonesense clone would be a stonesense clone that doesn't have to go offline for updating for a month or two after every release.

But who would design it? Stonesense has been around forever, and people could make alternate tilesets for it, from grimdark to anime, but no one does... its too much work it seems.

[GavJ]

Stonesense is for taking screenshots to post places. It's not realistically playable AS your graphics for the actual game.

Which is a significant difference from what I'm describing, and also simultaneously probably the reason people don't make other tilesets for it. It's niche enough use that there just isn't the "market" for it.

If the game was supplying native information in a shell that also natively took in commands allowing it to be an actual gameplay system without going down after updates, there would be vastly more usage hours and thus vastly more interest in variants and tilesets and such, because your modding work is going to get used by actual people doing full gameplay, not for like 10 seconds every week when they want to share something.

[Meph]

It's not realistically playable AS your graphics for the actual game.

I think you missed the release of the stonesense overlay, which allows to play the game through stonesense alone.

[GavJ]

at 200 FPS? If so, then okay great. They just need to advertise better I guess. Sounds good.

(Note, however, that if stonesense is a reason not to do the abovementioned things, it's also a reason not to do the OP's changes, since it also inherently solves tile re-use issues.)