Print

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

[bloop_bleep]

Not every time it loads -- every time it's built.

This means the game ships with the pre-generated files, and without the generation script. The script would reside only in Toady's development directory.

[PatrikLundell]

Well, as Meph pointed out, the generation scripts ought to be provided with the game in order to be available to modders, but it's true there's no need to regenerate the commercial version tiles except when they're modified, and so they'd be shipped with the (commercial) game, while the script would be included in the Classic baseline as well.

[mko]

Depends on the floor sprites. Each floor material would need a pre-made set of ramps. There are 40 grasses and 231 inorganics, plus some river/brook/magma/ice/(a few) mushroom-cap ramps. Let's make it 300 possible floor materials. Now those can mostly be rough, smoothed or engraved. Makes around 900.

All of which might have a track-tile on top, of any of the track directions, of which there are 14. Those need the correct shading of course.

Rekovs set has 72 ramps.

So you have 900*14*72 sprites. Just a meager 907.200 sprites.

Obviously I'm exaggerating a tiny bit, but yeah, automated shading by adding a brightness layer is the nicer solution in the end. Especially for modders/tileset authors adding their own content.

Ouch. And that is without transitions between various tile types.

[bloop_bleep]

Ehhh, I just realized a problem here though with shipping pre-generated tiles. If there are 907200 tiles, and each is a 32x32 bitmap of 3 bytes per pixel, then you get a total image size of 907200*32^2*3 = 2786918400 bytes, or about 279 MB 2.8 GB. Even with compression that would be rather really large. Perhaps it's better to dynamically draw tiles in-game.

This might even give better time-performance than pre-generating each of the million tiles, since it increases data locality (because there are fewer tiles, even if you load only the tiles displaying on screen) and so helps with cache efficiency.

And not just cache efficiency, actually, since if you pre-generate all ~1 million tiles you either add some 2.8 GB to RAM usage during runtime or load tiles from disk on-demand. Both are slow.

EDIT: Of course, there could be compromises. You could pre-generate all track-ramp combination tiles and combine them dynamically with the floor tiles.

[MoltenIdol]

Isometric isn't supported by the update we are making. I'm not familiar with CDDA, but I don't think it has multiple Z-levels (?)

It does have it implemented, with basements and tall apartment blocks an such, but it doesnt Really show anything more than a colored dot as representation of the tile 1 z level below, unfortunately, even though some artist already made some tilesets work with isometric, using the tiles already present in the tileset. The whole isometric thing looks super neat.

And im not talking about redoing Everything (if by everything you mean all your sprite work so far?), the only thing that would need some work of course would be terrain, Some sides of wall showing, while keeping the current wallsprite on the topside (with a slight bend of the sprite, like you did on one the ramp mockups). But all the sprites, that are Not top down sprites, and are not part of terrain, are fine as is.

I dont Know the amount of code work that would be needed of course, and it Also ramps up to be a lot of new sprites, and ways they interact with each other + it doesnt really add any functionality other than immersion, imo.

But you could have the isometric view trees back, from the original mockup, they looked pretty
Of course, the base game is more functional as a topdown, so im just wishing.

[Cruxador]

Depends on the floor sprites. Each floor material would need a pre-made set of ramps. There are 40 grasses and 231 inorganics, plus some river/brook/magma/ice/(a few) mushroom-cap ramps. Let's make it 300 possible floor materials. Now those can mostly be rough, smoothed or engraved. Makes around 900.

All of which might have a track-tile on top, of any of the track directions, of which there are 14. Those need the correct shading of course.

Rekovs set has 72 ramps.

So you have 900*14*72 sprites. Just a meager 907.200 sprites.

Obviously I'm exaggerating a tiny bit, but yeah, automated shading by adding a brightness layer is the nicer solution in the end. Especially for modders/tileset authors adding their own content.

Although I don't know where 231 inorganic floors is coming from, surely they can mostly just be grouped as soil, sand, stone, smoothed stone, engraved stone, and like a dozen constructed types (even including blocks)? It's not like you'd have to apply it separately to dynamic stuff like material colors. Although representing different stones accurately is important for a game that spends so much player time underground, how many stone types really need their own texture? After all, their form is mostly determined by what's been done to them and things like grain size are gonna be

Not every time it loads -- every time it's built.

This means the game ships with the pre-generated files, and without the generation script. The script would reside only in Toady's development directory.

Since it's top down, there's no inherent need to use script for this. You can also just make ramps an overlay with either alpha transparency. Even though there's alpha, you only need one color channel so it'll still be smaller than normal images. (polychromatic images could be supported but I can't think why you would want to in this case, even in the context of modding.
You can also screen, which would allow for more vibrant colors in the sunlight, but it becomes more hassle for shadows.
If you wanted both, You could do a channel of screen and another of multiply for maximum freedom in what can be done, but that gets complicated both for the CPU (every pixel takes four operations on every rendered channel since screen requires inversion twice, so 12 total) as opposed to one per color (3) with a basic transparent blend, and also for modders who don't know that much about images. In that case, it might be easier to have a set of single-channel (aka monochrome) images, one for subtract and one for multiply, and then applying them is the only case where I think using a script might make sense. Then, assuming the graphics will still be duplicated per-save, it could make sense for the script to run automatically during worldgen. However, honestly, 907,200 sprites generated seems like a lot no matter what the circumstance, especially if that number goes up by 1008 every time a modder adds a grass or floor type. EDIT: Wrote this before your post where you realized that too.

[Rekov]

I don't think the idea is to have a set of ramp tiles for every conceivable type of terrain. Instead you render terrain as two layers. You have your base layer, which is used to determine the color/pattern of the terrain. Then you overlay a shading layer over it to create the illusion of hills/ramps/etc.

Here is the shading layer I've come up with. I use yellow for the highlights and blue for the shadows:

Spoiler (click to show/hide)

The shading layer is placed over the terrain layer, in my case using the Overlay blend mode:

Spoiler (click to show/hide)

[Meph]

I don't think the idea is to have a set of ramp tiles for every conceivable type of terrain. Instead you render terrain as two layers. You have your base layer, which is used to determine the color/pattern of the terrain. Then you overlay a shading layer over it to create the illusion of hills/ramps/etc.

Correct.

[Cruxador]

I don't think the idea is to have a set of ramp tiles for every conceivable type of terrain. Instead you render terrain as two layers. You have your base layer, which is used to determine the color/pattern of the terrain. Then you overlay a shading layer over it to create the illusion of hills/ramps/etc.

Here is the shading layer I've come up with. I use yellow for the highlights and blue for the shadows:

Spoiler (click to show/hide)

The shading layer is placed over the terrain layer, in my case using the Overlay blend mode:

Spoiler (click to show/hide)

That's significantly more expensive than the way I described. I don't think it's that much harder for people to make two single channel images than one four channel image, is it? Even if it is, it would probably be better to have the game generate those two images from the four channel image rather than use it directly.

[Rekov]

Yeah that's a very good point Crux. Two simple alpha masks. And then you could even do more stuff like change the color/intensity of highlights and shadows depending on the season.

[jecowa]

Maybe for the lighting overlays, there could be separate ones for soil terrain and hard terrain. Then you could have softer slopes for dirt then for stone.

And maybe there could be separate overlays for indoor and outdoor slopes so you can have more contrast in outdoor areas than indoor areas.

[CL3AR]

I saw this on the discord so I thought I would post it here. Would it be possible to make 3d looking walls instead of the straight top-down walls?

Also, how are stairs going to be handled in the premium tileset?

[bloop_bleep]

I have a suggestion to make: smooth(er) material transitions.

I think the main problem with using a tileset that I've seen, is that there is so much visual noise from abrupt material color changes that it breaks immersion and makes it confusing for me what is what and to what I should pay attention. Take the area in the top right corner in the screenshot above. That's pretty noisy. The purple stuff and the yellow stuff stands out a lot, and makes the whole thing feel incohesive. I can't easily tell what is part of the wall, or what is part of the floor, or what is just an item, or whatever, at a glance. It all sort of melds together. I think this is partly because of contrast and partly because of the abrupt color changes that up to now have been mostly out of the tileset makers' hands. So, can I suggest perhaps making walls or floors more cohesive by making the material transitions less abrupt, or otherwise less breaking and distracting? This might have to be a question for Toady.

[Bumber]

I saw this on the discord so I thought I would post it here. Would it be possible to make 3d looking walls instead of the straight top-down walls?

They said it would look weird with multi-level view.

Also, how are stairs going to be handled in the premium tileset?

There's an image here: https://bay12games.com/dwarves/imgs/walls_floors.png

[Rekov]

It 'might' look weird in multilevel view, it might not. The walls on levels below would probably look like floors, so you actually wouldn't necessarily notice any obvious discontinuities.

Anyways, I was wonder if it might not make sense to do the walls as a series of 16x16, 16x32, and 32x16 sprites, so that you can render each 'side' of a double wall separately.



This potentially allows for additional mechanics in terms of smoothing walls from specific sides, as opposed to whole blocks at once. And in fact that is already how engraving walls works.

From the wiki:

Engravings are directional--only the side the engraving dwarf stood on will receive the engraving value bonus. There is no way to engrave more than one side of a single wall tile.

It's a natural time to unify the graphics and the mechanics. Let people smooth/engrave walls from specific sides, and show the status of walls from multiple sides.