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 1874 times)

Silverionmox

  • Bay Watcher
    • View Profile
Vector-based graphics
« on: December 13, 2009, 05:48:19 am »

Using vector-based graphics, especially for creatures, would have advantages for this game.
- Scaling: No need for a tileset for every resolution

- Indicating wounds, material, states, enchantments of creatures and parts of them: Applying an effect, colour or colour pattern to one vector object is trivial. It would be possible to display a dwarf with an iron helm, a bronze breastplate, pigtail pants and an adamantine hammer without needing to make a different icon for it.

- Indicating procedurally generated differences: Changing a colour, tweaking the lines, enlarging or shrinking certain body parts, or even adding, replacing or removing some would be easy to display. The fat trush with the elephant trunk, for example.

For all these advantages, it would require some things:
- the game must be able to display them and has to read the properties etc. of the displayed object and decide the colour and effects
- there must be vector-based graphics available
- the raws contain the arrangement and attachment points of the various body parts. It might be possible to use the work done in the new raws with regards to relative position of organs etc.
Logged
Dwarf Fortress cured my savescumming.

Nadaka

  • Bay Watcher
    • View Profile
    • http://www.nadaka.us
Re: Vector-based graphics
« Reply #1 on: December 13, 2009, 11:03:15 am »

It would also be a lot harder for people to make tilesets. Most people don't have an svg viewer, much less an svg editor.
Logged
Take me out to the black, tell them I ain't comin' back...
I don't care cause I'm still free, you can't take the sky from me...

I turned myself into a monster, to fight against the monsters of the world.

Draco18s

  • Bay Watcher
    • View Profile
Re: Vector-based graphics
« Reply #2 on: December 13, 2009, 11:27:58 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.
Logged

Silverionmox

  • Bay Watcher
    • View Profile
Re: Vector-based graphics
« Reply #3 on: December 13, 2009, 12:36:58 pm »

It would also be a lot harder for people to make tilesets. Most people don't have an svg viewer, much less an svg editor.
Optional, of course. I reckon it would be more appropriate for creatures and objects rather than the terrain etc. anyway. Svg editors (eg. Inkscape (free)) aren't that difficult, and are more suited for a lot of things people now use the Gimp or other pixel-brushing software for.

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.
I agree, that would be the most likely reason to avoid it. I presume that graphics cards can be used to that end to avoid it sucking up fps, but that would of course require an unknown amount of programming work... Since it's graphics, it has low priority. IMO it would add a unique feature to the game, but it's of course Toady's call whether he wants to invest the time to investigate/implement it.
Logged
Dwarf Fortress cured my savescumming.

Dvergar

  • Bay Watcher
    • View Profile
Re: Vector-based graphics
« Reply #4 on: December 13, 2009, 12:54:32 pm »

Math Class Time!

What were those vector's again?  And I have heard vector-based graphics but don't know what it is....

Sorry for being slow, but I sure there are others who would appriciate the explaination.
Logged

Nadaka

  • Bay Watcher
    • View Profile
    • http://www.nadaka.us
Re: Vector-based graphics
« Reply #5 on: December 13, 2009, 01:13:50 pm »

pixel drawing is to stiple art as vector graphics is to line art.

essentially vector graphics defines an image as a set of polygons filled with color instead of a field of individually colored pixels.

They scale infinitely with perfect smoothness. For large images, they are far more space efficient. For small images they can be less space efficient. In all cases it takes more processing to display as they must be rendered, much like 3d objects instead of bit copied to the screen buffer like pixel images can be.
Logged
Take me out to the black, tell them I ain't comin' back...
I don't care cause I'm still free, you can't take the sky from me...

I turned myself into a monster, to fight against the monsters of the world.

Jay

  • Bay Watcher
  • ☼Not Dead Yet☼
    • View Profile
Re: Vector-based graphics
« Reply #6 on: December 13, 2009, 01:34:50 pm »

Given today's graphics processing units, the difference is pretty much nonexistent anymore.
But yes, raster/bitmap images use fields of pixels with set color bits, whereas vector images use points, lines, and polygons.
Bitmap images scale by spreading the existing pixels out, and adding new pixels in the gaps.  This can cause blurriness.
Vector images scale by modifying the math formula used to draw them in the first place.  While they can't do gradients as well as bitmap images, they scale perfectly.
« Last Edit: December 13, 2009, 01:37:09 pm by jaybud4 »
Logged
Mishimanriz: Histories of Pegasi and Dictionaries

Footkerchief

  • Bay Watcher
  • The Juffo-Wup is strong in this place.
    • View Profile
Re: Vector-based graphics
« Reply #7 on: December 13, 2009, 04:10:42 pm »

Baughn was going to implement SVG support in the 40d# branch, so I doubt there are major feasibility issues.  It would be a nice thing to have.
Logged

Draco18s

  • Bay Watcher
    • View Profile
Re: Vector-based graphics
« Reply #8 on: December 13, 2009, 08:04:34 pm »

Given today's graphics processing units, the difference is pretty much nonexistent anymore.

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.

Quote
Vector images scale by modifying the math formula used to draw them in the first place.  While they can't do gradients as well as bitmap images, they scale perfectly.

They can do mathematically defined gradients, eg. linear, radial, and anything else you can define very very well.  Its the arbitrary gradients that it doesn't do well (eg. not at all).  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!).
Logged

Footkerchief

  • Bay Watcher
  • The Juffo-Wup is strong in this place.
    • View Profile
Re: Vector-based graphics
« Reply #9 on: December 13, 2009, 08:17:31 pm »

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.

Unless the player is constantly zooming in and out as much as possible, this shouldn't be a concern.  It's not like you have to throw away the rasterized image every time you draw it on screen.
Logged

profit

  • Bay Watcher
  • Finely Crafted Engravings... Or it didn't happen.
    • View Profile
Re: Vector-based graphics
« Reply #10 on: December 13, 2009, 08:56:08 pm »

This could be very handy for those with massively high resolutions or for people who want to zoom in on a single square without any loss of fidelity....

Everyone else will probably never notice a difference..

Logged
Mods and the best utilities for dwarf fortress
Community Mods and utilities thread.

CarmineEternity

  • Escaped Lunatic
    • View Profile
Re: Vector-based graphics
« Reply #11 on: December 13, 2009, 09:03:27 pm »

I think the graphics are just fine ATM.
Logged

sproingie

  • Bay Watcher
    • View Profile
Re: Vector-based graphics
« Reply #12 on: December 14, 2009, 01:25:16 pm »

What would be nice would be LoD tilesets.  Right now you get exactly one tileset no matter how far zoomed in or out you are, when it might make more sense to choose different tiles based on the zoom level.  Vector tiles would simply be able to scale linearly.

Anyway, if you want this feature, this one little part of DF is open source: the code to Battle Champs is out there, so get to it!
Logged
Toady is the man who Peter Molyneux wishes he was

Quote from: ToadyOne
dragon pus was like creamy gold. Infect and collect!

aepurniet

  • Bay Watcher
    • View Profile
Re: Vector-based graphics
« Reply #13 on: December 16, 2009, 06:23:50 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.

thats not true.  since the resolution isnt changing all the time, it would be very foolish not to cache the bitmaps once a rendering is done.  after that its the same as teh current system.
Logged

aepurniet

  • Bay Watcher
    • View Profile
Re: Vector-based graphics
« Reply #14 on: December 16, 2009, 06:26:36 am »

Using vector-based graphics, especially for creatures, would have advantages for this game.
- Scaling: No need for a tileset for every resolution

- Indicating wounds, material, states, enchantments of creatures and parts of them: Applying an effect, colour or colour pattern to one vector object is trivial. It would be possible to display a dwarf with an iron helm, a bronze breastplate, pigtail pants and an adamantine hammer without needing to make a different icon for it.

- Indicating procedurally generated differences: Changing a colour, tweaking the lines, enlarging or shrinking certain body parts, or even adding, replacing or removing some would be easy to display. The fat trush with the elephant trunk, for example.

For all these advantages, it would require some things:
- the game must be able to display them and has to read the properties etc. of the displayed object and decide the colour and effects
- there must be vector-based graphics available
- the raws contain the arrangement and attachment points of the various body parts. It might be possible to use the work done in the new raws with regards to relative position of organs etc.

it would be a lot harder to make the tile sets.

also your main idea of overlays and such has nothing to do with vector based graphics.  think of diablo (and diablo II) that had the same system (different attachment points and color filters for the overlays (weapons / armour) and used nothing but rasterized graphics.
Logged
Pages: [1] 2