Print

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

[Maldevious]

Don't know the inner workings of tile sets and whatnot, but I was wondering how feasible this is... in my current fort, there are lots of underground trees/shrubs growing, and some of them use the same mushroom tile. That makes it kind of hard to tell apart what is a shrub (i.e. won't clog my irrigating tunnels) and what is a tree (i.e. need to bust my butt and dig relief tunnels to chop them down). Thanks, great work. And to put in a contrary voice keep the water, it's fantastic.

[Ironhand]

Ah, you're getting spooked by baby plump helmets and dimple cups.
Hey, mushrooms is mushrooms. When they's little, you've gotta go by color.

From our point of view, it's not worth making another baby mushroom tile because they're all baby mushrooms.
Although, we might make a cluster of mushrooms later, which I guess you could use for one but not the other.

Animated noise?? Does that mean we could actually get WHITE flecks on our water??

[WormSlayer]

I've actually been playing with the underground plant tiles, but you have to regen a new world to change tree sapling graphics.

In theory full shader support would give us the ability to do animated, rippling, foamy, reflective, refractive, etc. water. Hell we could probably even do that nice shoreline effect where it meets ground tiles

[Foamy]

I had no idea so many amazing graphics features would be coming so soon.i cannot wait to see what you guys come up with.

[WormSlayer]

It's an exciting time for DF graphics

As part of last nights overhaul, I also remade every tree so they look less crappy when marked for felling

[Ironhand]

Yeah, I'm testing it out now! = P

That's why I'm not getting any art done.

That was bothering me before. Now it is lovely.

[Baughn]

The main problem with conditioning on surrounding tiles is the inevitable combinatorial explosion.

This means we have to generate the combinations in realtime, which is impossible in 2D mode and.. hard, in most of the opengl modes. In practice, it'll pretty much have to require shader mode, and probably also involve bundling shader code with the tileset in question. Not really a big deal, but more work than you're used to; I'll help, of course.

It'll also be useful to have textures that aren't associated with individual tiles, in order to blend them with ones that are.

So, ignoring graphics-mode's extra tiles for the moment, I'm envisioning a system something like this:

- Instead of a tileset, you supply a tarball/zipfile containing lots (and lots) of numbered PNGs. 0.png, 1.png, etc. Current tilesets would still be readable (backwards-compatibility is nice), but wouldn't get the extra bonuses.

- You can supply *any number* of those numbered PNGs.

- In the shader, you have four inputs:
* The current time (in milliseconds since DF start)
* The absolute location of the current tile, i.e. relative to the entire map
* The relative location of that tile, i.e. to the window
* The background/foreground color and CP437 index of *all* the visible tiles. You'd access the data for your current tile by using the relative tile-location as an index.

Additionally, you have access to a texture array, where each texture in that texture array matches up with the same numbered texture in the supplied tileset zipfile.

At that point.. well, you can do pretty much whatever you want. There will be a default set of shaders in data/art that act about the way it works today, which are overridden by any shaders in the zipfile; I'll be using both vertex and fragment shaders, as anything that's calculated the same way for every pixel in a tile (like, its foreground/background color and texture index) shouldn't be calculated per-pixel.

Sound good? This way, you won't get a slowdown almost no matter what you do.

[Ironhand]

Whoah, slow down.
You're making it sound like this is already possible... 

Looks like it's time for me to learn how to use shaders!

[Baughn]

Well, of course it's possible. It's just a bunch of coding.

The only thing I can't add without input from Toady is the absolute location, but I imagine that even without that it'll be rather useful.

It's going to be an opengl 3.2-capable and above card only thing, though, because I'm not feeling like supporting half a dozen incomplete drivers anymore.
People with old hardware can use 2D mode. That's what it's there for.

[WormSlayer]

Technical stuff...

That all sounds quite different to how it currently works... Care to drop a couple of examples of what we could do with your proposed system?

The real problem with tile borders right now is the abrupt colour change rather than the actual tile graphics.

[Rose]

The main problem with conditioning on surrounding tiles is the inevitable combinatorial explosion.

there are ways around it.

your welcome to take a look at stonesense for one way to manage tileborders, though it currently only differentiates based on walls, floors, open space, and ramps, but it's something.

[Aklyon]

It's going to be an opengl 3.2-capable and above card only thing, though, because I'm not feeling like supporting half a dozen incomplete drivers anymore.
People with old hardware can use 2D mode. That's what it's there for.

is there a way to check what opengl version your computer is capable of?

[Baughn]

Download GLView, run it, read the report.

[WormSlayer]

If you could implement the Stonesense approach to ramps that would be freaking awesome!

[Tormy]

The main problem with conditioning on surrounding tiles is the inevitable combinatorial explosion.

This means we have to generate the combinations in realtime, which is impossible in 2D mode and.. hard, in most of the opengl modes. In practice, it'll pretty much have to require shader mode, and probably also involve bundling shader code with the tileset in question. Not really a big deal, but more work than you're used to; I'll help, of course.

It'll also be useful to have textures that aren't associated with individual tiles, in order to blend them with ones that are.

So, ignoring graphics-mode's extra tiles for the moment, I'm envisioning a system something like this:

- Instead of a tileset, you supply a tarball/zipfile containing lots (and lots) of numbered PNGs. 0.png, 1.png, etc. Current tilesets would still be readable (backwards-compatibility is nice), but wouldn't get the extra bonuses.

- You can supply *any number* of those numbered PNGs.

- In the shader, you have four inputs:
* The current time (in milliseconds since DF start)
* The absolute location of the current tile, i.e. relative to the entire map
* The relative location of that tile, i.e. to the window
* The background/foreground color and CP437 index of *all* the visible tiles. You'd access the data for your current tile by using the relative tile-location as an index.

Additionally, you have access to a texture array, where each texture in that texture array matches up with the same numbered texture in the supplied tileset zipfile.

At that point.. well, you can do pretty much whatever you want. There will be a default set of shaders in data/art that act about the way it works today, which are overridden by any shaders in the zipfile; I'll be using both vertex and fragment shaders, as anything that's calculated the same way for every pixel in a tile (like, its foreground/background color and texture index) shouldn't be calculated per-pixel.

Sound good? This way, you won't get a slowdown almost no matter what you do.

I am kinda confused, but this sounds awesome. [I don't know too much about shaders etc....]
Also just a question: As we know, text + tiles will be separated in the upcoming versions. Basically this means that we can create custom gfx for each and every tile in the game [1 tile -> 1 image, so for example X won't be used to display 3 different things], or that still won't be possible?