Print

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

Dwarven Selection

113 (6.3%)

Wildlife

58 (3.2%)

Ambushes

154 (8.6%)

Sieges

207 (11.5%)

Undeads

118 (6.6%)

Forgotten Beasts

110 (6.1%)

Megabeasts

42 (2.3%)

The Circus

84 (4.7%)

FUN Spiral

286 (15.9%)

Dwarven Engineering

131 (7.3%)

FPS Death

396 (22%)

Other? (please specify)

97 (5.4%)

Total Members Voted: 879

[Thundercraft]

Most of the general assumptions people have about resizing may not be applicable to tilesets because pixel art is very different from a photograph or drawing to the interpolators used when resizing.

The thing is, I do have a bit of experience in pixel art. I consider myself something of an amateur artist. I've made various kinds of art both on the computer and on paper. And on occasion I have made some pixel art.

Yes, pixel art is very different from a photograph or drawing, especially in terms of interpolation and resizing. But, if anything, properly resizing pixel art is vastly more important to pixel art than it is for photographs or drawings. Due to the purpose and nature of pixel art, artists generally try to squeeze in as much detail as possible in a small area. Much of that is designed on a pixel by pixel basis, with it being common for single pixels or pixel-wide lines to represent important details. So loosing any of that detail to resizing is often very noticeable.

(For example, squeezing a 20x20 pixel image down to, say, 16x16 is going to either sacrifice or blend together certain pixels. Obviously, you can't fit all the pixels into a smaller space. More likely than not, certain 1-pixel wide lines or 1 pixel dots are going to disappear entirely.)

As such, using a tileset designed specifically to fit your maximum screen resolution will always be preferable to using an oversized tileset... so long as pixel art is used.

In comparison, the details in photos and drawings are usually blending across gradients of colors and shades and so there's a lot more room to blend and interpolate the details using resizing and anti-aliasing techniques. They're much more forgiving in terms of resizing before important details are lost.

Arclance, I did take a look at your resizing example. And I would agree that Cubic looks the best, with Nearest being a close second.
However, IMO, all of your resizing examples have an unacceptable level of blurriness. I would not be satisfied enough even with the Cubic method to switch to, say, a 24x24 size tileset and use that method to resize to fit my 1280x960 resolution monitor.

[arclance]

Most of the general assumptions people have about resizing may not be applicable to tilesets because pixel art is very different from a photograph or drawing to the interpolators used when resizing.

The thing is, I do have a bit of experience in pixel art. I consider myself something of an amateur artist. I've made various kinds of art both on the computer and on paper. And on occasion I have made some pixel art.

...

Arclance, I did take a look at your resizing example. And I would agree that Cubic looks the best, with Nearest being a close second.
However, IMO, all of your resizing examples have an unacceptable level of blurriness. I would not be satisfied enough even with the Cubic method to switch to, say, a 24x24 size tileset and use that method to resize to fit my 1280x960 resolution monitor.

That is what I meant by my statement.
My statement was directed at the general forum who I expect have no knowledge of how interpolation methods work and would not know that the general assumptions made about resizing photographs do not apply well to pixel art.
Losing pixels was what I expected in the downsizing example.
You would want to process the image more after downsizing to increase sharpness if you were going to use it to replace a larger tileset.
The example was intended to show the results of different interpolation methods by themselves on the shrinking of a tileset in a side by side comparison.

[Shandra]

You can use Spline in octave, but I have not been able to get it working for Tileset Resizer to test it yet.
I get this error.

Spoiler (click to show/hide)

octave-3.2.4:2> resize_tileset3_spline('Phoebus_16x16','png',16,16,15,15)
error: interp2: input data must have `meshgrid' format
error: called from:
error:   /usr/share/octave/3.2.4/m/general/interp2.m at line 401, column 9
error:   /home/*/Dwarf_Fortress/Tileset_Resizer/imremap_4layer.m at line 106, column 12
error:   /home/*/Dwarf_Fortress/Tileset_Resizer/imremap_4layer.m at line 86, column 21
error:   /home/*/Dwarf_Fortress/Tileset_Resizer/imresize_4layer.m at line 66, column 7
error:   /home/*/Dwarf_Fortress/Tileset_Resizer/resize_tileset3_spline.m at line 21, column 20

I think it means that spline is doing something it should not be (the imremap errors indicate it is not resizing each layer to the same size, the interp2 error indicates it is breaking the formating of the data structure the image is stored as in octave).
The version of Octave that I installed from a package for my version of linux was almost a year old so I am compiling the newest version now to see if spline works in the new version.

Most of the general assumptions people have about resizing may not be applicable to tilesets because pixel art is very different from a photograph or drawing to the interpolators used when resizing.
Take a look at the resizing example I put in my previous post and tell me which method you think worked the best.

I am not sure, with a quick glance at it, it is either bilinear or cubic - so I guess with just playing in animated state (not paused) there won't be much difference.... (still not sure because there are some tiles where the other ones win...)
Where I can think of problems in resizing (Hey, wasn't octave something alike to gnuplot meshed with a small bit of matlab/scilab? So in primary function to plot data... cool if it could deal with raster backgrounds for graphs....)

Some thing I am not sure about is - what happens with the alpha channel in resizing? The transparency simply cannot be dealt with in the same way as the pixels of the colour channels... neither nearest nor any averaging makes any sense there.....

[Shandra]

As such, using a tileset designed specifically to fit your maximum screen resolution will always be preferable to using an oversized tileset... so long as pixel art is used.

In comparison, the details in photos and drawings are usually blending across gradients of colors and shades and so there's a lot more room to blend and interpolate the details using resizing and anti-aliasing techniques. They're much more forgiving in terms of resizing before important details are lost.

Is that why subsamplig of 4/2/2, 4/1/1,etc. makes sense for lossy compression or video but with pixels we want to have luma and croma en pair with pixel (And why a subsampling besides 1/1/1 would interfere with analysis of RS Data (Edit:aka Where the Bit Value of each pixel in a channel represants an (closest as possible) exact measuring of a value for that pixel sized sample of area) - except for special cases of desired blure/averaging)?

[arclance]

Where I can think of problems in resizing (Hey, wasn't octave something alike to gnuplot meshed with a small bit of matlab/scilab? So in primary function to plot data... cool if it could deal with raster backgrounds for graphs....)

Some thing I am not sure about is - what happens with the alpha channel in resizing? The transparency simply cannot be dealt with in the same way as the pixels of the colour channels... neither nearest nor any averaging makes any sense there.....

Octave is a high-level interpreted language, primarily intended for numerical computations that almost completely recreates all the functionality of Matlab, so well that most Matlab functions run on Octave with no problem. 
Octave uses Gnuplot to draw its graphical output to make plots, figures, and graphs among other things.

The alpha channel can be dealt with in the same way as the color channels because of the way Octave processes image files.
Octave opens an image and maps its pixels to a NxNx4 matrix for rgb+alpha images.  Each cell in the matrix represents a single pixel with a value of 0 to 255 for 8 bit channels.  Each z level of the matrix is for a different channel. 
Images are altered in octave by appyling mathematical operations to this matrix.  Because the alpha channel is represented in the same way as the color channels the same operations can be applied to it as the color channels.

It is possible to resize each channel with a different interpolation method in octave but there should not be any reason to do that.

You can use Spline in octave, but I have not been able to get it working for Tileset Resizer to test it yet.
I get this error.

Spoiler (click to show/hide)

octave-3.2.4:2> resize_tileset3_spline('Phoebus_16x16','png',16,16,15,15)
error: interp2: input data must have `meshgrid' format
error: called from:
error:   /usr/share/octave/3.2.4/m/general/interp2.m at line 401, column 9
error:   /home/*/Dwarf_Fortress/Tileset_Resizer/imremap_4layer.m at line 106, column 12
error:   /home/*/Dwarf_Fortress/Tileset_Resizer/imremap_4layer.m at line 86, column 21
error:   /home/*/Dwarf_Fortress/Tileset_Resizer/imresize_4layer.m at line 66, column 7
error:   /home/*/Dwarf_Fortress/Tileset_Resizer/resize_tileset3_spline.m at line 21, column 20

I think it means that spline is doing something it should not be (the imremap errors indicate it is not resizing each layer to the same size, the interp2 error indicates it is breaking the formating of the data structure the image is stored as in octave).
The version of Octave that I installed from a package for my version of linux was almost a year old so I am compiling the newest version now to see if spline works in the new version.

I complied Octave 3.4.1 twice because I had to fix a change someone made that made it impossible to install octave forge packages.
Resizing with spline works in the new version.  I can put examples up on the Tileset Resizer page tomorrow if someone is intereseted in them. 

[Organon]

Of course Thundercraft is right; the best solution would be for someone to develop a 24x24 tileset. But if people want to keep experimenting with various scaling options, might I point them to this algorithm, which was specifically designed for scaling pixel art. Unfortunately, it supports neither transparency nor a scale factor of 1.5. However, these shortcuts could be overcome: Transparency would have to be extracted, scaled separatedly, and then added back in; also, you would probably scale by 3x and then downscale to 0.5 (with bilinear filtering?). Unfortunately I'm stuck on the transparency problem. As a teaser, here's a version of Phoebus scaled to 3x with lost transparency:

Spoiler (click to show/hide)

[Baleur]

Any chance for a version with all letters with a background (like "n" when enabling the better hills option), to make things easier to read with the other backgrounded characters such as the numbers, periods and that "n" 
I suppose i could just select and copy the tile that represents the period, and paste that semi-transparent tile onto the other letters? Or is it done somewhere else?

Also, is there a way to make the snow a bit more white and a bit less like ash? Brightening the 2 swirly tiles is all i need to do?
Edit: nevermind, did it Selecting the two tiles in photoshop and changing the levels to 0 - 1.25 - 225 had the perfect effect i was looking for, the entire world seems a bit brighter as a side-effect of having water, sand and snow be a tad brighter

[Phoebus]

Any chance for a version with all letters with a background (like "n" when enabling the better hills option), to make things easier to read with the other backgrounded characters such as the numbers, periods and that "n" 
I suppose i could just select and copy the tile that represents the period, and paste that semi-transparent tile onto the other letters? Or is it done somewhere else?

Also, is there a way to make the snow a bit more white and a bit less like ash? Brightening the 2 swirly tiles is all i need to do?
Edit: nevermind, did it Selecting the two tiles in photoshop and changing the levels to 0 - 1.25 - 225 had the perfect effect i was looking for, the entire world seems a bit brighter as a side-effect of having water, sand and snow be a tad brighter

I was working on the Mayday style background (a 50% transparent beige) for letters, I'll add an option for all letters similar to the hills and badlands at the same time.

Edit: The new background behind letters looks good enough that I think I'll use it as default.

Spoiler: 400k screenshot (click to show/hide)

Old without background (Top) VS new with background (Bottom)

[nenjin]

That looks great IMO. Getting away from using abyssal 0/0/0 black is good in most cases.

[Phoebus]

*Updated* 0.31.25v22
Updated the Beefmo units.
Brightened the water tiles. (Also applies to sand, snow, etc.)
Added a background to letters (except capital X and underscore "_".)
Added mods to configure water brightness. ("Water Darkest" is the old setting.)
Move the old water mod to Ground Mods.
Added 3 more Punctuation mods.
Added 3 stone (the mined resource) graphic mods. (DrD_Avel, Mayday & Jackal)
Added 3 text background mods. "NiceMap" replaced the old Hills & Badlands mod. ("Clear" is the old setting.)

[Phoebus]

I've tried a 24x24 rescale of the tileset. (I still have no intention to release a 24x24 tileset anytime soon.)

Spoiler: My current best version of a 24x24 tileset rescale (click to show/hide)

Creatures are still at 16x16, they get scaled by the game, that's why they are more blurry.

I had to split the image in 3 horizontal sections because imgur wouldn't take such a large png without greatly degrading the image quality by converting it to jpg.
If the image is broken up on your side that's the reason why.

Take note that it's not really different from using the 16x16 tileset and zooming in.
Currently the game is seriously limited because it's scaling the hud with the viewing area, so using a large tileset (or zooming in) results in a huge section of the screen being filled with the minimp & command window.

[ripping]

I'll look into Mayday's font style.

I would appreciate that. The font is overwhelming for anything more than simple lists. The rest of the pack is so clear and easy on the eye I'd hate to drop it.

[Aydjile]

Thank you very much for your hard work Phoebus. I really, really appreciate what you doing for the community.
I send you those girls so they could please you in any possible way. 

[lzm]

*Updated* 0.31.25v22

I noticed that the black unrevealed tile was brightened in this version (you can clearly see a gray pattern now where was all black).

Just commenting to let you know that I actually prefer the old version! I find the gray pattern too ugly/distracting.

[Phoebus]

I'll look into Mayday's font style.

I would appreciate that. The font is overwhelming for anything more than simple lists. The rest of the pack is so clear and easy on the eye I'd hate to drop it.

Mayday uses the Guybrush font, which is available in the tileset assembler.

*Updated* 0.31.25v22

I noticed that the black unrevealed tile was brightened in this version (you can clearly see a gray pattern now where was all black).

Just commenting to let you know that I actually prefer the old version! I find the gray pattern too ugly/distracting.

You can revert to the old version by selecting either "Text Clear" options in the Tileset Assembler.

Thank you very much for your hard work Phoebus. I really, really appreciate what you doing for the community.
I send you those girls so they could please you in any possible way. 

Thanks. I would have prefered if you faxed me a pizza, but won't look a gift horse in the mouth.