Print

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

[Starver]

From what I read (and I admit I started to skim, part way down page 2) I think everyone's (well, some people are) talking at cross-purposes.

If you have an image (especially a low-res one, like something that's tile-sized, like wot DF uses, guvnor), you can't easily convert that to a vector-description.  A small circle might indeed be a small circle, or a small octagon, when it comes down to that scale, and you don't want your small circle vectorising so that it appears like an octagon at larger scales, and nor do you want you small octagon vectorising so that it looks like a circle at large scales.

Whatever's done, it'll need to be done from scratch.  (Or at least with a lot of manual help to guide the automated edge-detection routine to the (possibly even then, subjectively) right conclusion.)

Ultimately, I could see DF going vectorised, but I don't see it being done within the paradigm of the current interface.  I'm not entirely sure why people zoom in to DF.  Pixel-for-pixel, the standard rendering of the (standard[1], or even the 'squarified' version theoreof) tileset gives enough information to (when you know what they are) identify everything for what it is, and distinct even from all similar-but-not-identical tiles.


Right now, I think the situation with raster graphics (that may or may not have been originally generated through rasterising a 'base' vector graphic, and touched up as necessary in the smaller examples) produce for each size would be the answer.  Perhaps an option in the tileset specifications that mean once a tileset has been magnified so that it's more than 2x2 pixels (displayed) per 1x1 pixels (on the tileset reference) it switches from Tileset1 to Tileset2, and then when it goes beyond the next limit (4x4 original pixels, 2x2 pixels since the previous switch) it adopts Tileset3...  or something.  Inbetweentimes, it'd have to do something like cubic approximation to translate N source pixels over a stretch of M display pixels (where neither N/M or M/N are easy integers).

Note that in the above example I assumed it's making it 1 pixel bigger per pixel (per axis), but I think (from the last time I checked the INITs) that it actually adds 10 pixels per zoom level, or something (regardless of how many it already zoomed, or does it go proportionally larger, thus exponentially?), but the same principle applies.  Anyway, you'd still only be guaranteed a 'nice looking' sprite when it coincides directly with a size given in the set series of icons, and perhaps decent looking ones when it's composed of an integer multiple of the most immediate smaller size (or, if you're lucky, if it's an integer division of the immediate larger and that it's actually reducing), but either aliasing effects (for expanded bitmaps) or blurring together (for contracted ones) could still exist even then, and would definitely cause some artefacts at all other intermediate positions.


Sorry, meant to keep this brief, and seem to have spontaneously come up with my own 'solution'.  Although I'm not particularl championing even this idea, just putting it forward as "best of both worlds", for those that care for such things.  (With apologies if I missed anyone saying anything similar, and less wordily.)


[1] Not wanting to make this a default vs. 3rd-part tileset debate, so sticking to the basics.

[GreatWyrmGold]

I'll continue pointing out that it requires more skill and understanding to make. If the game doesn't vectorize the image tilesets, you need to understand vectors to understand how to make a tileset.

Umm. You do realize, that you also need to know how pixel graphics work to make pixel graphics? And you need to know how a coffee machine works to make coffee, etc.
Vectors are in no essential way more or less complex than pixel art. You just are more used to dealing with pixels.

I can open Paint and fiddle with a few pixels to make, say, dwarves into frown faces or make diagonal walls. I'm betting that vector graphics would require a bit more understanding than pixel graphics...

[therahedwig]

I'll continue pointing out that it requires more skill and understanding to make. If the game doesn't vectorize the image tilesets, you need to understand vectors to understand how to make a tileset.

Umm. You do realize, that you also need to know how pixel graphics work to make pixel graphics? And you need to know how a coffee machine works to make coffee, etc.
Vectors are in no essential way more or less complex than pixel art. You just are more used to dealing with pixels.

I can open Paint and fiddle with a few pixels to make, say, dwarves into frown faces or make diagonal walls. I'm betting that vector graphics would require a bit more understanding than pixel graphics...

You're only reaffirming his argument...
No, not really, vector graphics don't require a little more understanding that pixels. If you'd try the program I showed you, you could see it's fairly easy to edit shapes. (You click/double click on them, you can move the dots, the lines and the straight lines(tangents) that are connected to the dots and the feedback is all very quick. You'll know how to move a curve exactly as you want to within minutes.)
Now, if you wanted to make a master painting in vectors with many gradients, then yes, you'll be learning a new system which is wildly different to what you're used to with painting in painter or painttool sai, but that isn't required for dwarf fortress.

[King Mir]

"A 16 by 16 vector image of a table" is nonsense. Vector images are not defined in terms of pixels. That being said, vector images are displayed rather poorly at those resolutions, especially if you want any sort of detail.

I believe he meant something like "A vector image defined from a 16*16 image."

No I meant a vector image displayed at 16x16 resolution. Presumably it would also be tailored to look good at that resolution.

So, instead of modifying a few pixels in a JPEG or some such, a tileset maker would need to trace their 12x16 or whatever designs, then vectorfy them?

Actually, what I meant was that they are made in vector by hand, as opposed to the solution of using an automatic vectoriser.

Vector lines do remain sharp at any size. Making vectors bigger is never a problem; making them smaller might be (obviously you design them at a small size, that will only enhance their iconic quality); but then again, at the sizes when that becomes a problem you'll need a separate tileset to make any sense at all from it, with vectors or pixels alike. So that's not an argument to claim vectors are worse.

It's an argument for not adding vectors, because that size is easily hit by typical tilesizes. A 16 by 16 vector image of a table will scale about as poorly as a 16 by 16 bitmap of a table.

So again, it depends on the skill of the skill of the artist how a picture will look.
Here, let me show you some tiles I'm making for the HD version of stonesense.

Spoiler (click to show/hide)

Stonesense starts off at the magnification at the right.(The 32x32 tiles)
On the left it the maximum magnification that this will look right at. (They're 128x128)
As you can see, there's certain tiles which look just as right at the magnification on the right as on the left. (Some don't, but hey, that's why I'm testing them). What I'm trying to say here is that a good artist can spread out detail in such a way that the image will still be recognisable at small sizes.

But both of those are still quite large. Typically tiles are displayed at smaller resolutions than 32x32. 16x16 and 18x18 are common. For zooming out, even smaller sizes are needed. Your example does not illustrate this being effective.

Right now, I think the situation with raster graphics (that may or may not have been originally generated through rasterising a 'base' vector graphic, and touched up as necessary in the smaller examples) produce for each size would be the answer.  Perhaps an option in the tileset specifications that mean once a tileset has been magnified so that it's more than 2x2 pixels (displayed) per 1x1 pixels (on the tileset reference) it switches from Tileset1 to Tileset2, and then when it goes beyond the next limit (4x4 original pixels, 2x2 pixels since the previous switch) it adopts Tileset3...  or something.  Inbetweentimes, it'd have to do something like cubic approximation to translate N source pixels over a stretch of M display pixels (where neither N/M or M/N are easy integers).

Note that in the above example I assumed it's making it 1 pixel bigger per pixel (per axis), but I think (from the last time I checked the INITs) that it actually adds 10 pixels per zoom level, or something (regardless of how many it already zoomed, or does it go proportionally larger, thus exponentially?), but the same principle applies.  Anyway, you'd still only be guaranteed a 'nice looking' sprite when it coincides directly with a size given in the set series of icons, and perhaps decent looking ones when it's composed of an integer multiple of the most immediate smaller size (or, if you're lucky, if it's an integer division of the immediate larger and that it's actually reducing), but either aliasing effects (for expanded bitmaps) or blurring together (for contracted ones) could still exist even then, and would definitely cause some artefacts at all other intermediate positions.


Sorry, meant to keep this brief, and seem to have spontaneously come up with my own 'solution'.  Although I'm not particularl championing even this idea, just putting it forward as "best of both worlds", for those that care for such things.  (With apologies if I missed anyone saying anything similar, and less wordily.)

I mentioned this idea briefly and without so much detail earlier in the thread, and I agree that it is a much better solution than vector graphics.

[GreatWyrmGold]

Starver's idea makes sense. I think.

In the meantime, what would happen if we made the default tileset 300×300 or something?

[Silverionmox]

I'll continue pointing out that it requires more skill and understanding to make. If the game doesn't vectorize the image tilesets, you need to understand vectors to understand how to make a tileset.

Umm. You do realize, that you also need to know how pixel graphics work to make pixel graphics? And you need to know how a coffee machine works to make coffee, etc.
Vectors are in no essential way more or less complex than pixel art. You just are more used to dealing with pixels.

I can open Paint and fiddle with a few pixels to make, say, dwarves into frown faces or make diagonal walls. I'm betting that vector graphics would require a bit more understanding than pixel graphics...

Vector images are more like collages with flat pieces of clay: you can shove the shapes around, reform them etc. Diagonal walls would be easy (4-clicks-easy. and rond ones too).

Vectors are also better suited for simple, iconic pictures like we need in DF; more fotorealistic pictures are better served with pixels. And you can still use bitmaps as textures.

[Bot Hack]

http://www.bay12forums.com/smf/index.php?topic=121367.0

I think having a vector image of a creature accompanied by a Dwarf for scale would add much flavor to the game, even if that creature still takes up one space on the overhead.

[GreatWyrmGold]

I'm not sure how useful that would be. A little maybe, but where would you put this image and how would you make the images of the dwarf and the creature? What if the creature's something like a fluffy wambler or a fire snake and not all of the dwarf can fit?

And what does this have to do with vector-based fonts, again? How would vectors help?

[Bot Hack]

From reading the first page, I just thought this could create a 2d image. The image would go great with the flavor text at the creature's description. I really just want to be able to judge how big a creature is compared to my Dwarves from in-game.

We could be real Uristy and just use the smiley face for Dwarves from windowed DF as the Dwarf, a little character in the corner, and use the vectored image of that smiley face next to the Dwarf to show the scale of the creature. Using the in-game cubed size parameters for all creatures, I imagine it would easy to scale these two images correspondingly to each separate creature in-game.

[GreatWyrmGold]

So...if a kobold was half as tall as a dwarf it could be something like:

Code: [Select]

  /\
k \/
But with the crude rhombus replaced with a smiley face?
...Sounds interesting.

[Adrian]

Interesting, yes.
And it would also mean that we wouldn't need multi-tile creatures anymore, since we can just scale dragons to their true size.

But the rewrites...
Dwarf Fortress' entire everything is designed around the idea that everything takes up the same amount of space.

[GreatWyrmGold]

Interesting, yes.
And it would also mean that we wouldn't need multi-tile creatures anymore, since we can just scale dragons to their true size.

I don't follow.

But the rewrites...
Dwarf Fortress' entire everything is designed around the idea that everything takes up the same amount of space.

Wagons, workshops, buildings in general, terrain features, and next update, trees. Oh, and Toady's said he's planning multi-tile creatures.

[Starver]

Interesting, yes.
And it would also mean that we wouldn't need multi-tile creatures anymore, since we can just scale dragons to their true size.

I don't follow.

From my reading (and without re-reviewing the pre-necro parts of the thread in working out the latest thought developments), if a dragon was a D next to a c kitten, no longer constrained to a Curses-esque character grid.

But the rewrites...
Dwarf Fortress' entire everything is designed around the idea that everything takes up the same amount of space.

Wagons, workshops, buildings in general, terrain features, and next update, trees. Oh, and Toady's said he's planning multi-tile creatures.

Wagons as multi-tile creatures are a dead-end idea, from what I understand of what Toady has written (although I don't know if I have the full info on this).  Future multi-tile creatures, if any, would be done differently.  Perhaps Wagons will then be re-written for the 'new style' multi-tiling.

All the rest is based on either fixed templates of unit components (workshops, four templates each for the directionisable siege engines) or pseudorandom permutations of tile-cubed units (vector paths between nodes for roads, varying cuboidal structures or subterranean rooms with procedural feature emplacement within them and their walls, flood-fill and limited-flood-filling pastings, according to what and where it is.  But still the units take up the same space.

Even the multi-tile trees are just procedurally 'grown' using the basic units, from what I have seen.  (I'm not disparaging them for this, in fact I quite like what has been done to do this, it probably has needed quite a bit of tuning to get it looking right, and is probably going to be further perfected before release.)

But DF is designed around a 3D grid.  Ok, so Wagons may require a 3x3x1 space to exist in (and we all know what happens when this space is cut down by one means or another), and workshops have a similar footprint (3x3x1 or 5x5x1 for Depots/Kennels) needed to be placed to start with (I haven't tried to part-destroy any of these, but I suspect I know what would happen if I tried), but that's just a restriction placed on the use or occupancy of the grid.  Nothing 'free-floats'.  Investigate a 'hill town' in Adventure Mode and you can see how landscape has affected the generation of settlement buildings.  Or ruined buildings have whole tiles'-worth of missing bits from them.

I find the observable generation patterns of the urban/suburban roadways and trackways to be an interesting study (as I'm traipsing across the landscape) and have similarly theorised about the castle-wall building routines...  but I fear I'm digressing somewhat from the subject of the thread in this current line of musings, so I'll go no further on that for now.

[GreatWyrmGold]

Interesting, yes.
And it would also mean that we wouldn't need multi-tile creatures anymore, since we can just scale dragons to their true size.

I don't follow.

From my reading (and without re-reviewing the pre-necro parts of the thread in working out the latest thought developments), if a dragon was a D next to a c kitten, no longer constrained to a Curses-esque character grid.

...How would that work AT ALL with no multitile creatures?

But the rewrites...
Dwarf Fortress' entire everything is designed around the idea that everything takes up the same amount of space.

Wagons, workshops, buildings in general, terrain features, and next update, trees. Oh, and Toady's said he's planning multi-tile creatures.

Wagons as multi-tile creatures are a dead-end idea, from what I understand of what Toady has written (although I don't know if I have the full info on this).  Future multi-tile creatures, if any, would be done differently.  Perhaps Wagons will then be re-written for the 'new style' multi-tiling.

Wagons as creatures is dead-end; while future multi-tile creatures will be different, they'll still be, you know, multiple tiles.

All the rest is based on either fixed templates of unit components (workshops, four templates each for the directionisable siege engines) or pseudorandom permutations of tile-cubed units (vector paths between nodes for roads, varying cuboidal structures or subterranean rooms with procedural feature emplacement within them and their walls, flood-fill and limited-flood-filling pastings, according to what and where it is.  But still the units take up the same space.

Okay, but you said that EVERYTHING takes up the same place.
And...siege engines and other buildings still take up multiple tiles. A screw pump is a screw pump, not two divisible halves of a screw pump.

Even the multi-tile trees are just procedurally 'grown' using the basic units, from what I have seen.  (I'm not disparaging them for this, in fact I quite like what has been done to do this, it probably has needed quite a bit of tuning to get it looking right, and is probably going to be further perfected before release.)

They are still multiple tiles.
By this time, I'm certain I have no idea what you're saying.

The rest of what you wrote provided no new epiphanies, so I'll wait for you to explain some more before commenting.

[Starver]

Interesting, yes.
And it would also mean that we wouldn't need multi-tile creatures anymore, since we can just scale dragons to their true size.

I don't follow.

From my reading (and without re-reviewing the pre-necro parts of the thread in working out the latest thought developments), if a dragon was a D next to a c kitten, no longer constrained to a Curses-esque character grid.

...How would that work AT ALL with no multitile creatures?

It's no longer tiles.

I'm probably misremembering the earlier bits of the thread (should go back and read it), but that's the conclusion I come to from (re-interpreting?) the subject "Vector based font".

Wagons as creatures is dead-end; while future multi-tile creatures will be different, they'll still be, you know, multiple tiles.

That's much as I was saying (the dead-end part).  The latter is indeed a valid tautology, but dependent on them happening.

Okay, but you said that EVERYTHING takes up the same place.

That was Adrian.  I was giving my interpretation of what I thought Adrian meant.  (That a tile is a tile and is fixed as a tile.  A multi-tile thing is a set of tiles, each of which is one tile's-worth.  Which was perhaps confusing, given it started off with a novel methodology where this might no longer to be true, but then caveated itself with how this is different from how it currently is.)

I think I don't have an argument with you at all really, save for some semantics that I won't argue about, although I've obviously been inexpertly building the "bridge of understanding" I was attempting due to my own inability to avoid being obtuse.