Print

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

[Phoebus]

Down ramps don't really exist, they are just the open space tiles above ramps. Down ramps should only be drawn on the lowest visible z-level.
As for being misleading, ramps are not more misleading that any other tiles. The problem is that the current settings are optimized to create more attractive screenshots. There's only a subtle tint difference between z-level. It's pretty, but it's not easy to tell which z-level a tile is on.
When actually playing the game, there should at least be a sharp difference between the active z-level and the other z-levels, to minimize confusion and mistakes.

[mifki]

When actually playing the game, there should at least be a sharp difference between the active z-level and the other z-levels, to minimize confusion and mistakes.

There are commands to adjust fog density, colour, and shadow colour/opacity, so you can adjust as you like. Or you have other ideas how to increase difference between levels?

[Footkerchief]

When actually playing the game, there should at least be a sharp difference between the active z-level and the other z-levels, to minimize confusion and mistakes.

There are commands to adjust fog density, colour, and shadow colour/opacity, so you can adjust as you like. Or you have other ideas how to increase difference between levels?

Fog is currently linear with regard to depth, right?  Could add extra contrast between z = 0 and z = 1.

[PeridexisErrant]

When actually playing the game, there should at least be a sharp difference between the active z-level and the other z-levels, to minimize confusion and mistakes.

There are commands to adjust fog density, colour, and shadow colour/opacity, so you can adjust as you like. Or you have other ideas how to increase difference between levels?

Fog is currently linear with regard to depth, right?  Could add extra contrast between z = 0 and z = 1.

I think double or triple would be about right. 

[PeridexisErrant]

One big improvement for adventurer mode multi-level would be not rendering 10 levels below you, but 5 below and 5 above, or whatever you end up configuring. Don't know if that's feasible but it would make navigating hilly regions a much better experience.

Well, it doesn't support multilevel in adv mode at all currently, when I'll work on it, I'll keep your idea in mind.

Any news or development around adventure mode support?  I've had a couple of questions about that from the 34.11 starter pack, now that TwbT is on by default, and it would be nice. 

In terms of rendering above - which I'm not sure is necessary - how about:
 - take 'multilevel X'.  For adventure mode use 0.5*X=Y levels, rounding down
 - render current level,
 - render Y levels below
 - iff there is only open space above the adventurer, render Y levels above

This works well outside, and deals with buildings and caverns - at worst it simply flips between rendering above and not. Anything else gets very complex with special cases and odd rendering effects; I typed and deleted four half-formed ideas as possible extensions but I think they're a topic best left for later. 

[mifki]

Yep, it's possible to add another parameter for the fog density between z=0 and z=1.

Honestly, I'm not working on adv mode now, but eventually I will. There are some difficulties with it, so the way of rendering above levels will be the least of them.


The most important thing I want to know now is about the branch with non-square text tiles.
Obviously it provides better user experience, has cleaner, better structured and faster code (because map rendering is separated), and I personally want to focus on this branch.
However there are some difficulties. First, special versions of some plugins will be required (at least mouse query, building plan, then rendermax again). I'll make versions that will work both with and without twbt, and will provide a way for plugin authors to know if twbt is running in this mode and get required data from it. But still this may cause some complications for players and package makers.
Another problem is that apart from the maps in fortress mode and adv mode (square tiles) and text (non-square tiles) there are also minimap, maps on embark screen and so on. Should they be in text? It's not a problem to have one more separate font for these areas but it still will be rectangular and sized as all text.

So basically I'd like to know how important non-square text is and whether the community is ready for some inconveniences like incompatibility (likely temporary) with some plugins that this functionality may cause.

[Mike Mayday]

As long as we can have a different tile SIZE for the interface, I don't much care if it's square or non-square.

As for occlusion: I've found that an opacity of 25% for the fog one level below is quite enough, then an additional 15% for each level lower.

[scamtank]

Another problem is that apart from the maps in fortress mode and adv mode (square tiles) and text (non-square tiles) there are also minimap, maps on embark screen and so on. Should they be in text? It's not a problem to have one more separate font for these areas but it still will be rectangular and sized as all text.

So basically I'd like to know how important non-square text is and whether the community is ready for some inconveniences like incompatibility (likely temporary) with some plugins that this functionality may cause.

Maps are maps are maps. Ideally, they'd take specific square tile sheets for map display only, but I'd settle for using the text rendering for those. The map screens have traditionally been horribly mangled by graphics packs due to their non-customizability, making them render right a big plus in favor of basic ASCII. That's what they were intended to look like in the first place, after all.

Text (mini)maps good, square special graphics (mini)maps better, not breaking shit best. I could give up some DFHack goodies for something like that, though.

[mifki]

As long as we can have a different tile SIZE for the interface, I don't much care if it's square or non-square.

No difference, everything said above is true just for different tile sizes.

[CLA]

So basically I'd like to know how important non-square text is and whether the community is ready for some inconveniences like incompatibility (likely temporary) with some plugins that this functionality may cause.

Personally, I don't care much for non-square text, but from what I see, there are quite some people that do.
On a related note, what I do care about a lot is that maps are square.

[Rose]

I guess I really need to get onto making a proper map visualizer then.

Isoworld already kinda half does it.

[Mike Mayday]

As long as we can have a different tile SIZE for the interface, I don't much care if it's square or non-square.

No difference, everything said above is true just for different tile sizes.

In that case, break all you wish I say. Larger map tiles with smaller interface tiles are number two on my wishlist (number one, separate object tilesets, you've already completed, oh glorious one!).

[CLA]

I guess I really need to get onto making a proper map visualizer then.

Isoworld already kinda half does it.

Isoworld is amazing, and I can't wait to see the new trees. Still, I think a map visualizer that runs inside DF would be better as top-down.

[Rose]

It could go either way, really.

Top-down isn't the best at showing elevations.

[Dirst]

Not to take anything away from Mifki's amazing work on separating text from graphics, but I've always wondered why the vanilla game doesn't do this already.  The init files already ask for two different fonts, and the TTF option affects most of the interface text.  It appears that any screen which might have scrollbars is still rendered in tiles for some odd reason (embark announcement, thoughts and preferences, help, etc.) but ones that scroll whole pages use TTF (combat logs, etc.).

Does anyone have a handle on why the core game makes such odd distinctions?  Even if the font issues got resolved in the core game, that would still leave plenty of scope for the multi-level visualization work that mifki has also done an amazing job tackling.