Print

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

[Putnam]

Here's an inherent quality: A few clicks by just about anyone can make a pixel tileset. You need to understand vector graphics to make vetor tilesets.

You really, really don't need to understand vector graphics.

[Silverionmox]

Here's an inherent quality: A few clicks by just about anyone can make a pixel tileset. You need to understand vector graphics to make vetor tilesets.

You need to understand how to tie your shoes before you can wear them effectively. That does not mean shoes are inherently less useful than slippers.

[GreatWyrmGold]

Here's an inherent quality: A few clicks by just about anyone can make a pixel tileset. You need to understand vector graphics to make vetor tilesets.

You really, really don't need to understand vector graphics.

Oh? How does one manage to design something they don't understand? Use, sure, but design requires some level of understanding. In this case, more than the average Bay12er likely has.

Here's an inherent quality: A few clicks by just about anyone can make a pixel tileset. You need to understand vector graphics to make vetor tilesets.

You need to understand how to tie your shoes before you can wear them effectively. That does not mean shoes are inherently less useful than slippers.

On the other hand, if there are no big advantages to shoes and most people don't know how to tie them, then we oughta stick with slippers.

[Silverionmox]

On the other hand, if there are no big advantages to shoes and most people don't know how to tie them, then we oughta stick with slippers.

By your own admission you don't understand vector graphics, so who are you to judge whether there are big advantages to them or not?

[Bloax]

It'd be very useful because you could make a tileset for say, 12x12 - but then you could easily change it to be 16x16 or greater.

..Instead of having to redraw every single godforsaken thing.

[Putnam]

Here's an inherent quality: A few clicks by just about anyone can make a pixel tileset. You need to understand vector graphics to make vetor tilesets.

You really, really don't need to understand vector graphics.

Oh? How does one manage to design something they don't understand? Use, sure, but design requires some level of understanding. In this case, more than the average Bay12er likely has.

I could say the exact same for pixel graphics.

[Starver]

Depending on the complexity of the vectors involved[1], I don't think vector graphics is inherently more complex.

It's a point-and-click(-and-drag) operation, really.  Much as how in Paint (being representative of an uncomplicated graphics package) you can draw a straight line so easily.  Except that it's stored as "Draw from X1,Y1 to X2,Y2 in a certain colour", not "make [set of pixels] a certain colour".  To the eye, the unzoomed versions of both operations are the same.  The difference is that the former scales better (including scaled anti-aliasing).

Of course if you manually stipple your raster graphics, painting pixels one at a time for a given final resolution of image, then that's quicker than the vector equivalent of defining squares of "one pixel" size and filling them with the colour necessary, but that'd be a uniquely time-consuming way of drawing anything other than a "snow noise"-type pattern.  Mostly you're drawing lines (straight or curved), filling enclosed areas with solid colours, gradients, other patterns, etc...  Which can be done in a raster fashion or a vector one, where sometimes it's a bit more effort to do it one way than another...

But moving onto GIMP (my "advanced" paint-package of choice, being at least as good as various premium packages and free too!), straight lines (or straight-line operations of various of the brushes and other effects) are easy enough to apply in a 'raster' way, click the start position and shift-click the end position (hold shift before clicking to see the path), and you end up with a line as if you'd clicked and dragged in MS's Paint.

Ovals and Rectangles are a little harder to draw.  Suitably drawn Oval and Rectangle selection areas can be placed and then filled (flood-filled, or manually painted in with a brush of some kind and size or other), but getting an outline is harder.  For that you need the "convert selection to path" option and then "paint along path" (specifying the 'brush' to apply to the line, and/or the dotted style/width of the application).  For some things you just want to do that for an oval line and it takes six or seven clicks to do the same for an MSPaint oval that takes three (not counting the actual selecting of line thickness or colour in either case, assuming you're going with the current default in both cases).

You might, however, want to just after the "convert selection to path" stage do something with the path.  E.g. slightly bend a defining bit of splined-line a off of the original oval.  Or once you've drawn the line, you can re-use the same path (with no extra cost in defining it) to make a "thin line on a thick line" effect (adding blurring effects on the lower one, useful for giving a "neon glow" to something, I find).  With Paint that'd be the "pencil" tool, and using your own judgement, for the former (ignoring anti-aliasing effects completely, as well, should you have wanted them)  For the latter you'd have to draw your "underlying" line first (couldn't start with the top one, either because of layers or because you could redo the top one later) then repeat the process from one exact pixel-location to another exact-pixel location for the thinner line.  (Something I've done many a time, for one reason or another...)

Working with the "paths" (essentially vector definitions) available in GIMP is actually a pleasure, compared to this.  Especially when you want to rejig the path position/size.

This is still ultimately in raster format, of course.  But if you've been working exclusively with any number of paths (up until the point of painting the lines from the paths, then you can resize the canvas upwards or downwards and re-draw (at the low-scale versions perhaps modifying the line thicknesses, to taste, but a simple matter to do when re-drawing) at any image size you might care for...  If this was intelligently left to any given display engine to do then it'd be zero effort for the end/mid-user, or developer, to cater for (except for scales where it's significantly scrunched up, perhaps, if you don't also set a hard limit on some things) whereas supplying multiple scales of raster tiles needs reauthoring (with opportunity for checking and modifying, of course), taking time out from the creative process and refinement.



There's one downside I'd put to considering vectors for DF (as it currently stands)...  An 8x12 (or whatever it is, exactly, by default) pixel raster graphic's design (even the simple "dwarf-face", circle (filled our outline) with dots for eyes and small curve for mouth (and option "beard" segment, depending on which of the default tilesets you're actually considering!) being defined in vector graphics would probably look no better (to my mind) than the tileset as it currently is.  But it would look a whole lot better if you did zoom up the effective pixel-count of the tile.


And I've actually converted (for my own 'nefarious' purposes, which I still hope to show the fruits of in the not too distant future) the default tileset to a vector-based notation equivalent.  That's hard.  The conversion.  No, not hard... Tedious.  At least while trying to 'perfect' the conversion of vastly different entities[2] to my own particular standards and aesthetics.  (YMMV.)


Anyway, vector graphics is easier to do than (say) GWG seems to think they are.  I run my DF with the default (non-squared, even!) tileset, and the default size of that as well, and I'm not sure directly vectorising the current grid-bound game will make my experience better at all.  But something tells me there's a comparison of apples and oranges going on here, from all around.  Which is why I can't make up my mind what's actually (now) being suggested.


Sorry, another long post, and probably missing a mark, again, in my attempts to encompass and explain and bridge between the various ideas floating round here.  (As I interpret them.  With a heavy dose of "YMMV" to be taken three times before mealtimes.)




[1] Simple MoveTo(x1,y1);DrawTo(x2,y2) equivalent lines and polylines to start with, radial curves and spline curves for more complex continuous vector pathing, and whether there's a "fill", "shade"  or whatever, to be applied within vector-defined areas, for which there may be a separately configured presence/absence of border-tracing of one kind or another...

[2] The more alphabetic characters need to be assessed as if made of "strokes", backforming the original font creation process.  Border/tramline characters are straight-forward, of course.  the 25%/50%/75% pixel-full "haze" characters I'm dealing with 'in spirit', rather than "as a set of diagonal lines", or whatever it might otherwise be interpretable as.  Some characters are simple primitives (the dwarvish "smiley face"), but not all isolated dots are so obviously circles (a 1x1 pixel "splodge") or squares (a 1x1 pixel total fill), until you examine them in context.  And not all lines, at that small scale, are necessarily so straight/curved/angled as they might appear to be, when you look at what the effect of other nearby pixels (also being converted to one primitive or another) mean in the overall image.  I could take the raw vector data behind (say) the Courier New definition of the various characters, but that's not the only font with the correct CP<whatever>/ASCII/ANSI-like character set defined, and none of them quite seem to "back-convert" to the rasterised default graphics sets involved (anomalous dwarven beard being ignored for this test).

[GreatWyrmGold]

On the other hand, if there are no big advantages to shoes and most people don't know how to tie them, then we oughta stick with slippers.

By your own admission you don't understand vector graphics, so who are you to judge whether there are big advantages to them or not?

The only one people have brought up is zooming in or out. Guess what? I have only seen one thread in this entire forum which even brings up zooming for any length of time. On the other hand, they're also evidently much harder to work with. If there was some way to easily convert convenient little pixel tilesets into vector-based ones, sure, but otherwise...not really worth it.

Here's an inherent quality: A few clicks by just about anyone can make a pixel tileset. You need to understand vector graphics to make vetor tilesets.

You really, really don't need to understand vector graphics.

Oh? How does one manage to design something they don't understand? Use, sure, but design requires some level of understanding. In this case, more than the average Bay12er likely has.

I could say the exact same for pixel graphics.

Difference: Pixel graphics are more intuitive and simpler. I want to change the dwarven smiley face with pixels? Simple, I just open the image file and click a few times in the right areas. I want to do the same thing with vectors? I need to learn how vectors work and probably use some kind of vector-using program like the one you showed a few pages back. I still can't figure out how to make a good-looking image with that thing.

But, of course, I seem to be the only one paying attention to this thread who doesn't see vector graphics for the unwieldy things they are to most people, including most DF players, and who only sees the minor benefits. Therefore, I will not be paying any more attention to this thread. It's becoming a headache.

[Starver]

(GWG: Dampening field overwhelmed due to relevance.)

Difference: Pixel graphics are more intuitive and simpler. I want to change the dwarven smiley face with pixels? Simple, I just open the image file and click a few times in the right areas. I want to do the same thing with vectors? I need to learn how vectors work and probably use some kind of vector-using program like the one you showed a few pages back. I still can't figure out how to make a good-looking image with that thing.

Comparing like with like, not everyone could make a pixelated "smiley face" from scratch (with no reference to a standard), much as not everyone could make a vectorised one from scratch with the same intent in mind.  Beyond that, it's familiarity with the method of drawing.  Not feeling affected I didn't pursue the link for that VG program myself, so I've no idea how that would work.  If it's more complex than basic primitives and spline-lines then it's probably a bad one.  Personally I'm no expert in (pure) vector graphics creation, though.  Mostly to the extent described regarding GIMP's features, which is by no means pure vectors and really only gives only rasterised results.

Starting with a vectorised smiley face, I cannot imagine it being so obtuse as to not be able to convert it into a frowny face.  Either by flipping the curve construct over or dragging its constructor nodes into the opposing configuration.  As easy (or hard) as re-pixelling a smile into a frown, surely.  "Clicking a few times in the right areas" (perhaps with a bit of "-and-dragging" included) should apply just as well.

But, of course, I seem to be the only one paying attention to this thread who doesn't see vector graphics for the unwieldy things they are to most people, including most DF players, and who only sees the minor benefits. Therefore, I will not be paying any more attention to this thread. It's becoming a headache.

If you're paying attention to me (and I wouldn't blame you if you weren't), can I try to say something that I think you missed from at least the previous post of mine...

I actually don't see vector graphics in the tileset-scaled game that I currently play.  It'd be useful for zooming in, perhaps adding more (currently nominally sub-pixel) details that don't work well in tilesets but might be made visible when extra (and 'closer') attention is being paid to a graphic, like water droplets actually clinging to a wet characters... erm... 'character'. Also if multi-tiledness were to be formed of an expanded character (or total grid-divorcement meant that graphics are truly sized according to true relative relationships).

For benefits, I see benefits where a vector-definition file can compress "A circle, so big; a small splodge here and here; an arc, centred here from this angle to this angle; all of this in the supplied colour; <optionally: a jagged triangle of grey, so-positioned" better than "background; background; background; background; background; background; background; background; <next row>; background; background; foreground; foreground; foreground; foreground; background; background; <next row>;....etc" can be.

Which depends on the format.  Even basic RLE does decently with what we have (LZW doubtless does better, but I haven't worked it out like I might, and I don't have the same in-depth knowledge of zlib/PNG compression).  It would be well within the design philosophy to have a RAW-like (or perhaps XLMish variant, thereof) storage of vector information (imagine the caste modifications one could embed within the vector graphics!), but that's nothing like the best solution, which could be a nibble's-worth of a bits to define the "primitive type", variable length operands according to which there were and what context, and some arbitrary 'grid resolution' for the vector delimiters and guides involved.  A BackOfTheEnvelope calculation reveals that a decent (unbearded) smiley face could be 76 bits of definition (and probably easily less) prior to any additional compression, then add paging overheads, header overheads etc...  Assuming it's a whole lot of (separately defined, and not likeness-for-likeness compared in any compression scheme) smiley faces being stored (instead of some more complex tiles and some less complex ones), that would come out to a favourable file size and compression ratio compared to the raster image.

But I don't see that as a big factor in any decision (also it'd be a more generic format, I'm sure, less specialised and more capable, thus not as tiny).

Nor do I think there's any need to talk of "easy" conversion of pixel tilesets into vector ones.  Not if you mean "on the fly".  It'd be the artist (or some designated other) who would at least guide (if not correct) any automation that's employed, but even more likely is that it'd be someone using the existing tilesets as a template would use pretty much the same effort as they might do to re-pixelise a tileset to a different size in making drawing a vector version in its stead.  Once.  Per tileset.  (With reference to all scales that existed of that pixel tileset, but aside from testing against basic zooming, needs no actual re-re-doing for any different size.


If it did that.  But I'm probably more pixel-aligned than you think.  Or have noticed.  Have I been taking the middle ground again?  You know, arguing against +opinion for being too +ve and arguing against -opinion for being too -ve?  If so, no wonder everyone's confused as to what I've said, if I always seem to be in opposition to what they think, thanks to understandable blindness to anything I've said which would actually be somewhat agreeable to them.

[King Mir]

Regardless of how easy vector graphics are to use, they are useless for DF, because they don't scale well for images around the size of a typical DF tile (16x16). At that scale, automatic interpolation just looks bad.

There are ways around this, to make vector shapes have some additional guidance on how to interpolate and average vector points, and they are in fact use in text font; true type fonts allow this. However, speaking from experience pixel tilesets are a lot easier to work with than true type fonts.

Speaking of witch, in legacy DF the output font is specified by the console/terminal. It is possible to tell the console to use a fixed width vector font. In this way DF does technically support vector based fonts.

[King Mir]

It'd be very useful because you could make a tileset for say, 12x12 - but then you could easily change it to be 16x16 or greater.

..Instead of having to redraw every single godforsaken thing.

It's not as easy as you might think. This page illustrates the problems, and explains how they are overcome. This page describes the non-trivial UI to do it.

And that's for fonts, which are black and white. Tilesets can have any color, an multiple colors can intersect a pixel. Also, unlike fonts, for realistic tiles, it can make sense to blur overlapping colors, whereas for symbols, you want to maintain contrast.

In the end it can be easier to create two separate tilesets, than to ensure that a single vector tileset looks good at different scales.

[SuicideJunkie]

I tried making some vector graphics, and it really is not hard to do... if you keep the rendering to a reasonable size.

The main issue as I see it, is that when you're rendering at the 15 pixel tile scale, you're not going to get the clarity you can get with manual pixel art.

When drawing small, you've got to drop out the lesser details, retain the important details, and start making each pixel do a lot of jobs. 
Vectors retain the idea of shape at all scales, but when you're working with only a handful of pixels, you have to start sacrificing shape to get the essence across to the viewer.

IMO, you're putting a lot more work into getting the pixel art right, but your efforts are focused right where it counts.

[Starver]

LoD qualifiers would certainly add something (both value and expense) to a vector description.  I'd be surprised if there weren't something like that already in some related format or other (though not all, because I've seen too many that don't).

[Silverionmox]

It'd be very useful because you could make a tileset for say, 12x12 - but then you could easily change it to be 16x16 or greater.

..Instead of having to redraw every single godforsaken thing.

It's not as easy as you might think. This page illustrates the problems, and explains how they are overcome. This page describes the non-trivial UI to do it.

And that's for fonts, which are black and white. Tilesets can have any color, an multiple colors can intersect a pixel. Also, unlike fonts, for realistic tiles, it can make sense to blur overlapping colors, whereas for symbols, you want to maintain contrast.

In the end it can be easier to create two separate tilesets, than to ensure that a single vector tileset looks good at different scales.

That's very interesting. I don't think we're going to need that kind of sophistication, because fonts need to give good results when bolded, cursive, and subjected to a host of other processes, in particular kerning and most important of all, printing. We won't need much of those.

In addition, this just illustrates that the problem of displaying abstract shapes on a rasterized grid is known, and solutions are available. Given that DF doesn't need to be printed, the solutions found to display vector images rather than fonts would be more appropriate, and probably simpler.

[King Mir]

For fonts, the industry is mature and knows the details of the problem, but I'm not sure vector graphics are. Even if vector graphic formats do include the tools to specify proper scaling behavior at low resolutions, these tools may not be easy to use. And this is not just a matter of interface; I think it can be technically easier to provide a series of low resolution images than to specify scaling rules like for fonts.

Ideally DF would accept an image formats for both vector graphics with scaling information, and multi-scaled raster graphics both in widely used formats. But I think multi-scaled raster images are a better solution to the scaling problem. However I'm not aware of good image formats for this. I once wanted to make an program icon that scaled at different resolutions. I was unable to find a tool to do this, even though icons are a multi-scale raster format.