Print

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

[dibujante]

If I understand correctly, DF could quickly render each tile at varying resolutions (8x8, 16x16, 24x24, 32x32, 64x64 and anywhere larger/smaller/inbetween) and then it would basically be displaying things just like it would display .bmp and .png tilesets. The main difference would be that, in the process of rendering multiple resolutions of each tile, DF could refer to the same .svg for all of them, rather than force some poor pixel pusher to design each one separately.

[G-Flex]

The thing about filesize is that it (obviously) depends on how complicated the tiles are.

If you look at something like the mike mayday set, those would require a hell of a lot of lines/curves/other objects to render, especially considering how many distinct tiles there are (they aren't part of a single image, really).

Also, I didn't just mean "the rendering is sort of slow in Firefox". It's more like "I've had SVG images cause my browser to go unresponsive for five minutes and even stay that way after the image was loaded".

If I understand correctly, DF could quickly render each tile at varying resolutions (8x8, 16x16, 24x24, 32x32, 64x64 and anywhere larger/smaller/inbetween) and then it would basically be displaying things just like it would display .bmp and .png tilesets. The main difference would be that, in the process of rendering multiple resolutions of each tile, DF could refer to the same .svg for all of them, rather than force some poor pixel pusher to design each one separately.

Well yeah, that's the whole point.

One issue I'm pointing out is that if you design something as complicated as the mayday creature graphics, then try to render that SVG as an 8x8 or 16x16 tile, the inherent fudge factor in trying to get all those curves and lines and stuff down to that size might end up giving you odd results. I mean hell, we're talking about representing stuff that's literally made out of details only a few (in some cases probably one) pixels large using the current method.

I would definitely suggest testing it out first, and as Corona said, you'd probably have to design them quite differently.

[dibujante]

Mos' def. I am restraining my urge to make these huge, ultra-complicated tiles. I'm aiming at something more symbolic/representational that looks sharp, rather than trying to mimic Mike Mayday's fine pixel-work.

Also, even if it does take ungodly long to open these svgs (5mins) they only need to be rendered into pngs once. It could be part of the first startup and never happen again.

[G-Flex]

That's true. If the program can tell beforehand which resolutions it has to anticipate, it can act accordingly when it loads the game.

Of course, if you're going to go that far, you could leave SVG support out entirely, and simply make SVG tilesets and render them to PNG beforehand. It's just a matter of where you want the conversation to take place.

[Corona688]

I really, really doubt the svg file would be so weighty as to freeze the game for any appreciable amount of time.  The size of the bitmap being rendered would be much smaller than your web browser window for one thing.

[LordZorintrhox]

Yeah, Corona688 is right.  Think about it guys:

Zoom with SVGs:

Load SVG -> Parse SVG -> Render SVG with mipmaps for OpenGL because it only supports bitmaps of some kind and you'd be stupid not to use mipmaps -> check zoom level and pick right mipmap -> render as usual

Zoom with various predefined bitmaps:

Load Bitmaps -> check zoom level and pick right mipmap -> render as usual

Which of these sounds better?  In the end, the hardware rendering is what determines precisely what data is actually rendered, so by the time the information gets to the renderer, you are doing the same thing.  Hell, if you wanted to implement this so there would be as little lag as possible, the program would load the SVG and pre-render all of the mipmaps and cache them anyway.  It is the same thing, only one requires more time to implement.

Furthermore, you will get far more aesthetically pleasing results with separate images defined for each zoom level.  As G-Flex pointed out, if I make a ridiculously large tileset in SVG that details fingers, 1: no one will care as they play and 2: it will just gum-up the works when the set is rendered at 16x16: a muddy mess of brown pixels.

However, there is a problem with all of these problems: DF is, as far as we know, in flux as to its final presentation.  Who knows what Toady will do?  The game is designed out of the box to have a "classic" feel of ASCII based games of yore, and in that context SVG isn't so bad of an idea.  It's like a font with fewer restrictions.

But will that remain the case, and if it does, is that desirable?  What if it remains that way, but the community develops a complete graphics revamp that makes it have more of a sprite based (these days, hand-held) feel, assuming Toady gets to full graphics support?  At that point, SVG support is barely a neutral position, as pixel-based graphics will unquestionably provide a better look, feel, legibility, and modding possibilities (cut to super-simple ASCII style on far zoom-outs, but sprite-like detail on zoom in; with definable zoom-level maps this would be a given).

That means that overall, SVG would be, I am sorry to say, a bit of a waste of time as far as the game is concerned.  As a coding exercise, a useful tromp through vector graphics and OpenGL, and a megaproject worthy of Armok, but like so many dwarvenly exploits, at the end of the day your really just killing elves goblins in creative ways.

[dibujante]

Yeah, Corona688 is right.  Think about it guys:

Zoom with SVGs:

Load SVG -> Parse SVG -> Render SVG with mipmaps for OpenGL because it only supports bitmaps of some kind and you'd be stupid not to use mipmaps -> check zoom level and pick right mipmap -> render as usual

Zoom with various predefined bitmaps:

Load Bitmaps -> check zoom level and pick right mipmap -> render as usual

Which of these sounds better?  In the end, the hardware rendering is what determines precisely what data is actually rendered, so by the time the information gets to the renderer, you are doing the same thing.  Hell, if you wanted to implement this so there would be as little lag as possible, the program would load the SVG and pre-render all of the mipmaps and cache them anyway.  It is the same thing, only one requires more time to implement.

Furthermore, you will get far more aesthetically pleasing results with separate images defined for each zoom level.  As G-Flex pointed out, if I make a ridiculously large tileset in SVG that details fingers, 1: no one will care as they play and 2: it will just gum-up the works when the set is rendered at 16x16: a muddy mess of brown pixels.

However, there is a problem with all of these problems: DF is, as far as we know, in flux as to its final presentation.  Who knows what Toady will do?  The game is designed out of the box to have a "classic" feel of ASCII based games of yore, and in that context SVG isn't so bad of an idea.  It's like a font with fewer restrictions.

But will that remain the case, and if it does, is that desirable?  What if it remains that way, but the community develops a complete graphics revamp that makes it have more of a sprite based (these days, hand-held) feel, assuming Toady gets to full graphics support?  At that point, SVG support is barely a neutral position, as pixel-based graphics will unquestionably provide a better look, feel, legibility, and modding possibilities (cut to super-simple ASCII style on far zoom-outs, but sprite-like detail on zoom in; with definable zoom-level maps this would be a given).

That means that overall, SVG would be, I am sorry to say, a bit of a waste of time as far as the game is concerned.  As a coding exercise, a useful tromp through vector graphics and OpenGL, and a megaproject worthy of Armok, but like so many dwarvenly exploits, at the end of the day your really just killing elves goblins in creative ways.

imma still doin it

[Exponent]

Remember that translucency is available, so that you can blend not just between full brightness and black (by using grayscale), but also partway between the foreground and background colors by using the alpha channel.  This can provide creative alternatives to the half-hatch pattern, for example.  (Apologies if you already had this sort of thing in mind.)

[Corona688]

half hatch != translucent.  That's why SVG tilesets will need a wholly different look.

[Exponent]

half hatch != translucent.  That's why SVG tilesets will need a wholly different look.

True, half hatch is not identical to just solid 50% translucency.  And I will agree that SVG tilesets will have a rather different look.  But by using varying degrees of translucency (avoiding the flat 50% sort of thing), you might still be able to get better results than if you tried to imitate the half hatch pattern directly, since as you pointed out, scaling would completely ruin a direct approach.

So my purpose in mention translucency was simply to make sure that it was considered as an alternative to trying to directly imitate certain pixel-based patterns.

[Baughn]

The main reason I'd like to have SVG instead of, say, a bunch of pngs is because that way it's possible to make any arbitrary resolution the "correct" one.

Also, it isn't actually that much work; all I have to do is link to a preexisting SVG library.

[Corona688]

Instead of!?

Please don't replace .png!

[CobaltKobold]

Dibuj accomplish any such thing?

[Baughn]

Toady asked for a hold on any new features for now, so I won't be doing anything with SVG until after the next proper release.

[Martin]

When you get back to this, a SVG tileset is pretty easy to knock out in illustrator. Just type out a regular font set on the grid using the font of your choice, use the Text->Make Outlines feature to turn those into paths, and save as SVG. If you just want something to test against, that should do the job.