Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  
Pages: 1 [2]

Author Topic: Vector-based graphics  (Read 1871 times)

Silverionmox

  • Bay Watcher
    • View Profile
Re: Vector-based graphics
« Reply #15 on: December 17, 2009, 08:09:55 am »

Making it might be harder for some, easier for others. Tweaking an existing .svg tileset is much easier.

It's possible to do it rasterized, but much easier to change a particular object in a picture that has been designed and saved as a set of objects: just change a property of a single object, and it will automatically be implemented at the time of drawing the picture. With raster images, you have to define and include extra filter and assembly steps to combine the different (tailor-made) parts of the pictures... effectively doing what a .svg renderer would do, but slower and less flexibly.
Logged
Dwarf Fortress cured my savescumming.

SSBR

  • Bay Watcher
    • View Profile
Re: Vector-based graphics
« Reply #16 on: December 20, 2009, 07:23:29 am »

Quote
At the scale we're talking (that is, individual pixels) the vectors would need to have many control points in order to properly render at the small size.  Due to that high count of points plus the overhead of the math figuring out what to draw, it ends up being slower than rendering a bitmap.  Try it in Flash.  Anything under about 100x100 pixels that has high detail should be a bitmap.
Well, no. As has been pointed out, the raster images can be cached. Not only that, they can be pre-rendered. With no zooming at all, there would be zero speed difference, because all you would see would be pre-rendered vector images. What it gives is scalability-- you can actually add zooming for those that can take the hit, and you can support more resolutions with similar proportions, or whatever.

Quote
Its actually a good thing that computers went the route of rasterized images, as if we'd gone vector then the digital art community would never have sprung up the way it did.  Not to mention that our games wouldn't have the graphics we have now (imagine trying to use vectors to define textures on a 3D polygon!).
The irony being that polygons are vector shapes. 3D graphics today was the success of a combination of 3D vector imagery and 2D raster textures, and the failure of the direct 3D analogue to pixels, voxels-- though voxels have their place, and may be making a comeback (they might be handy with real-time ray tracing, but that technology's not going to pan out for a very long time, if ever).

Quote
What were those vector's again?  And I have heard vector-based graphics but don't know what it is....
Math vectors are simply collections of scalar values-- numbers. For example, (3, 5) is a mathematical vector, so is (7, 5, 2). Every vector here can be used to define an equation-- for example, 2x + 5, and 7x2 + 5x + 2 are polynomial vectors that can be represented using simple vectors as explained above. You can in fact draw a line using a polynomial expression as a function.
In vector rendering, you don't quite do this-- a single vector doesn't define a line, but a sequence of vectors does. Each vector contributes to a part of a polynomial expression that determines the shape of a line (the polynomial is actually parametric, meaning that the line can cross over itself, and so on). It's the same idea, though-- each vector contributes to the shape of the line in a similar fashion to how each element of a vector contributes to the shape of a simple polynomial expansion.
This is compared to raster graphics, where you just have a bunch of points with a defined color (can also be defined mathematically using vectors, of course, but hey), and where you just draw each point as a box/pixel with that color. Zooming in can only expand the box, not the thing that box is meant to represent-- a bullet or a hammer or whatever-- whereas a vector line would define the entire outline of the bullet or hammer, and represent it as accurately and efficiently as possible using boxes/pixels at whatever resolution you have set.
Logged

eerr

  • Bay Watcher
    • View Profile
Re: Vector-based graphics
« Reply #17 on: December 21, 2009, 10:29:54 am »

Not to mention being slower to render (even assuming that the multiple component overlays takes no overhead) due to vectors taking up at least as much, if not more, information at the scale we're discussing.

A vector image must be written to a bitmap to display.

If said bitmap is recorded, the vector need only be used when the bitmap needs resizing.
Logged

Baughn

  • Noble Phantasm
  • The Haruhiist
  • Hiss
    • View Profile
Re: Vector-based graphics
« Reply #18 on: December 28, 2009, 11:04:00 am »

There won't be SVG in the 40dN series, as Toady has put a hold on any major new features.

Eventually, though, sure.
Logged
C++ makes baby Cthulhu weep. Why settle for the lesser horror?
Pages: 1 [2]