Bay 12 Games Forum

Please login or register.

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

Author Topic: Multi-level view demo  (Read 16259 times)

Baughn

  • Noble Phantasm
  • The Haruhiist
  • Hiss
    • View Profile
Re: Multi-level view demo
« Reply #60 on: January 24, 2010, 06:24:17 pm »

No, I don't think many people will have issues with improved performance.

Seriously, the current system is extremely inefficient. It would be hard to replace it and not get a speedup.
Logged
C++ makes baby Cthulhu weep. Why settle for the lesser horror?

Footkerchief

  • Bay Watcher
  • The Juffo-Wup is strong in this place.
    • View Profile
Re: Multi-level view demo
« Reply #61 on: January 25, 2010, 02:46:24 am »

Haha, that's reassuring.  Had you been trying to get Toady to make that leap?
Logged

Baughn

  • Noble Phantasm
  • The Haruhiist
  • Hiss
    • View Profile
Re: Multi-level view demo
« Reply #62 on: January 25, 2010, 07:03:47 am »

A bit, but it'll as mentioned be a lot of work, and I'm not quite sure I've managed to communicate the concepts involved.

At any rate, it should be part of the interface arc.
Logged
C++ makes baby Cthulhu weep. Why settle for the lesser horror?

CobaltKobold

  • Bay Watcher
  • ☼HOOD☼ ☼ROBE☼ ☼DAGGER☼ [TAIL]
    • View Profile
Re: Multi-level view demo
« Reply #63 on: January 25, 2010, 07:35:09 am »

If done wrongly, this could produce a dramatic slowdown in DF; doing it right would be a lot of work.

So don't prod too hard. You don't want a half-assed implementation of this.
I...actually, doesn't the skyblock code do about 70% of this?
A: Only if it's done stupidly. The smart way to skyblock is check the "light" flag on the tile X layers down (of the "outside/light/aboveground" set, one will do the trick. I may be picking the wrong one, but one definitely will work)

So, if I wanted to make a similarly quick way to implement this...it'd be to make some sort of "tiles down to nonempty" (below, "drop_z") count in the tile, and update that when things change it, rather than constantly checking what it is, meaning only two tile lookups per tile, a constant. Worse than single-view, but you could do something like
Code: [Select]
#define DEPTH_DISCOUNT 0.1
for each(tile view_tile in view) {
  temp_graphic = get_tile_graphic(view_tile.x, view_tile.y, (view.z - view_tile.drop_z));
//get the tile that we're drawing, however far down it is
  temp_graphic -= (temp_graphic * DEPTH_DISCOUNT) * view_tile.drop_z;
//adjust brightness based on depth down
//...should cap so we don't get funkylicious graphics when it would fully black out or more, not done here
//can be different calculation, this is just linear 10%
  view.draw (view_tile.view_x, view_tile.view_y, temp_graphic);
//and, draw the thing.
}
This need not be in three statements, obviously, but I did it for clarity.

Of note is that it should be doable at roughly the same step as you're applying colors to the tile (not shown)...

Of course, what's expensive is implementing all the things that change drop_z- though, all these should be done wherever the "Light" flags are fiddled with. Which is a lot of places (building completion, buildings changing state due to lever, building deconstruction, building destruction in many ways, digging, caveins, obsidian formation, ice melting/freezing...)

this is still an O(h) solution per tile, in the tile changes, but O(1) in the renderer...actually could be optimised to O(1) in the tile changes by only checking/updating drop_z up to where it stops mattering (drop_z >= 10, in this case, as that's complete blackout of tile...this would also solve the dimming-capping problem without needing to add more logic to the drawing routines)

Thinking more still, the light flags(light/outside/subterrane) could have an optimisation that doesn't go so well with the drop_z sort of thing- simply storing where the light falls down to for each (x,y) rather than storing "is this tile light/outside/subterrane"...this doesn't work for the drop_z since you need to have arbitrarily many drop_z layers (though most forts will not need more than a few, anything structured like a tree/platform/bridge city would inflict a great deal of it)

edit:I forgot a significant one needing to update drop_z: flying/falling creature/vermin/item motion. But only for when they're moving through empty tiles, which is what restricts it to flying/falling. Unfortunately these states are not so rare that they could be ignored...flingify(), crossbows, enemies(or their limbs) being sent flying, flying creatures, melancholy...

...ALL flows...

What's worse is, e'en RAINfall can change midair tile occupancy (it destroys webs, so only for outdoor GCS- the vermin only seem to web on floored tiles?)

Yes, this is a mess to think about.
« Last Edit: January 25, 2010, 07:58:48 am by CobaltKobold »
Logged
Neither whole, nor broken. Interpreting this post is left as an exercise for the reader.
OCEANCLIFF seeding, high z-var(40d)
Tilesets

Quarterblue

  • Bay Watcher
    • View Profile
Re: Multi-level view demo
« Reply #64 on: June 05, 2014, 03:50:49 pm »

Could this be feasible with a dfhack plugin a la rendermax?
Logged

DrKillPatient

  • Bay Watcher
  • The yak falls infinitely
    • View Profile
Re: Multi-level view demo
« Reply #65 on: June 05, 2014, 04:29:43 pm »

I think perhaps it could. I see no reason why we couldn't query z-levels that the view's not centered on, and Rendermax and the recent Stonesense overlay plugins seem to indicate that drawing to/on the DF graphics before they're rendered to the screen is possible. I don't know the internals of the graphics code, though, so there may be additional limitations.
Logged
"Frankly, if you're hanging out with people who tell you to use v.begin() instead of &v[0], you need to rethink your social circle."
    Scott Meyers, Effective STL

I've written bash scripts to make using DF easier under Linux!

MDFification

  • Bay Watcher
  • Hammerer at Law
    • View Profile
Re: Multi-level view demo
« Reply #66 on: June 05, 2014, 08:40:48 pm »

Could this be feasible with a dfhack plugin a la rendermax?
Quarterblue gestures!
The Thread shudders and starts to move!
Logged

smjjames

  • Bay Watcher
    • View Profile
Re: Multi-level view demo
« Reply #67 on: June 05, 2014, 08:42:51 pm »

Ancient thread is ancient, look at the OP, all the way back to 2009.
Logged

Draco18s

  • Bay Watcher
    • View Profile
Re: Multi-level view demo
« Reply #68 on: June 05, 2014, 11:32:06 pm »

Ancient thread is ancient, look at the OP, all the way back to 2009.

I think it contracted Mummy Rot
Logged

thatnewguy

  • Bay Watcher
    • View Profile
Re: Multi-level view demo
« Reply #69 on: June 06, 2014, 08:58:04 pm »

Could this be feasible with a dfhack plugin a la rendermax?
Quarterblue gestures!
The Thread shudders and starts to move!


yes. this is the most dwarf fortressy post on DF forums i've ever seen.
Logged
f5
Pages: 1 ... 3 4 [5]