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]

But you can zoom out! You just can't zoom in (at least not without using STANDARD mode, which only zooms vertically, thereby making the tiles non-square and ugly). So people with huge resolutions and poor eyesight like me are poorly served by 16x16 tilesets, whereas you could still be happy with 24x24 (I think)

Last time I checked, Dwarf Fortress does not work that way. You have it backwards: We'd be able to zoom in, but not zoom out fully.

As I said, the minimum number of horizontal tiles is 80 for the game to zoom right. And even if we could use an 18x18 or 24x24 tileset with proper zoom, the pixelation would make the tiles look bad for the rest of us unless we used close to the optimum screen resolution.

If it were otherwise, I think we would already have 24x24 graphics sets available.
And as I said before, Ironhand is more likely to make a 24x24 set since he already mentioned before that he was considering it.

By the way, according to the Steam Hardware Survey, about thirty percent of the participants now have a horizontal resolution of 1920 pixels. So a potential userbase for 24x24 tilesets definitely exists

Why not repeat that in the Ironhand's Graphics thread? Who knows? It might help convince him.

[Organon]

As I said, the minimum number of horizontal tiles is 80 for the game to zoom right.

If I run the game with a 24x24 tileset and a resolution of 1280x720, it will automatically downscale the tiles to 16x16 (after moving the game window once). With the mouse wheel, I can zoom out but not in. Zooming out works properly in the sense that the tiles remain square. This is using WINDOWED:YES, RESIZABLE:YES, PRINT_MODE:STANDARD, and requesting a resolution of 80x40 tiles.

[Ethicalfive]

I'd really love to see a graphics overhaul sooner rather than later. The 80 tiles minimum width thing alone is rediculous and limits more detailed sets. Zooming should allow you to go in one extra level than it does so you can see detail better(I currently use a magnifyer when I want to look closer).

I feel that once toady decides it's worth doing a graphics/interface overhaul, Phoebus and Ironhand will be long gone(not dead, but life will get in the way as it is with ironhand). It's a horrible waste of such great talent, these two guys should be nurtured and supported rather than having to make do with what little gfx support there is. Don't misunderstand me, I love ASCII games, I just hate Toadys specific ASCII choices.

Keep up the good work Phoebus! I'm looking forward to your updates whenever DF gets it's next release. Your work truely improves with every phoebus release.

[Robsoie]

The ability to zoom in (and so the removal of the 80 minimum tiles) would be really great in DF, would make playing on smaller windows so much better when using all those nice graphic tilesets.

[ruanna]

Okay...  having graphics problems. Screenshots below.

Spoiler (click to show/hide)

[Phoebus]

Okay...  having graphics problems. Screenshots below.

Spoiler (click to show/hide)

In "data/config/init.txt", can you find [GRAPHICS:YES]? (Unit graphics will only work with [GRAPHICS:YES])

Spoiler (click to show/hide)

[GRAPHICS:YES]
[GRAPHICS_WINDOWEDX:0]
[GRAPHICS_WINDOWEDY:0]
[GRAPHICS_FONT:Phoebus_16x16.png]
[GRAPHICS_FULLSCREENX:0]
[GRAPHICS_FULLSCREENY:0]
[GRAPHICS_FULLFONT:Phoebus_16x16.png]
[GRAPHICS_BLACK_SPACE:YES]

Is that a screenshot of your savegame's RAWs?

Did you use the savegame updater? (the .bat file)

If you did the above didn't work:
Try deleting your savegame's "raw/graphics" folder then running the savegame updater again.

If you're not on windows, delete your savegame's "raw/graphics" folder, then copy the main DF "raw/graphics" folder to your savegame.

[ruanna]

graphics : YES

Hurrah! Thanks! Spent ages copying things back and forth trying to figure it out!

[Baleur]

"After updating the game, run DF_savegame_updater.bat to update your savegames, run DF_phoebus_init_updater.bat to update your inits, then play the game."

Should this be done before, or after, installing the graphics pack via the Lazy Newb launcher?
Sometimes i make little changes with the Phoebus assembler, enabling the smoother hills & badlands thing and such. And i'm always wondering if i should run the phoebus .bat's after or just rely on the Lazy Newb launcher ^_^

Also a question, is it possible to run this pack but with the fonts (and calming beige interface background) of the Mayday pack?
I'm torn, i really love how everything looks in this pack, but i adore the font and easy to read text and UI of the Mayday pack.

[Phoebus]

"After updating the game, run DF_savegame_updater.bat to update your savegames, run DF_phoebus_init_updater.bat to update your inits, then play the game."

Should this be done before, or after, installing the graphics pack via the Lazy Newb launcher?
Sometimes i make little changes with the Phoebus assembler, enabling the smoother hills & badlands thing and such. And i'm always wondering if i should run the phoebus .bat's after or just rely on the Lazy Newb launcher ^_^

Also a question, is it possible to run this pack but with the fonts (and calming beige interface background) of the Mayday pack?
I'm torn, i really love how everything looks in this pack, but i adore the font and easy to read text and UI of the Mayday pack.

Changes to the tileset are global. Each savegame doesn't have it's own custom tileset, so no need to run the savegame updater after a tileset modification.

You should run the savegame updater anytime you want to use an old savegame with a new version of DF and/or a new/updated graphic pack.

I'll look into Mayday's font style.

[Shandra]

Just to add my 2ct to the zooming function - yes, that 80 tiles min is a handicap and zooming in would be cool. Though I actually play with mouse off (and hate the fact that even in Fullscreen the mousepointer is appearing from time to time) and just looked at zooming out some aeons ago... and well, the downsampling is (was) IMHO simply not worth to be looked into any further by me... what would be cool, but that is most probably so far in the future of the development that It will stay just a dream (and not even worth any mentioning in the suggestion forum) - but if at that time Toady still relies on raster graphics instead of full vector power something like the configurability of your average Map(/Tile)-Server would be neat; aka that you provide not one but multiple graphic packs and tell the game wich one to use in a certain resolution/scale/zoom-level

[Edit: As I am not sure wich method the zooming uses for the downsampling, I rejected the idea of image pyramids wich would just reduce the processing speed and not actually the quality of the output]

[arclance]

Just to add my 2ct to the zooming function - yes, that 80 tiles min is a handicap and zooming in would be cool. Though I actually play with mouse off (and hate the fact that even in Fullscreen the mousepointer is appearing from time to time) and just looked at zooming out some aeons ago... and well, the downsampling is (was) IMHO simply not worth to be looked into any further by me... what would be cool, but that is most probably so far in the future of the development that It will stay just a dream (and not even worth any mentioning in the suggestion forum) - but if at that time Toady still relies on raster graphics instead of full vector power something like the configurability of your average Map(/Tile)-Server would be neat; aka that you provide not one but multiple graphic packs and tell the game wich one to use in a certain resolution/scale/zoom-level

[Edit: As I am not sure wich method the zooming uses for the downsampling, I rejected the idea of image pyramids wich would just reduce the processing speed and not actually the quality of the output]

You might want to take a look at my Tileset Resizer utility.
It takes advantage of the blocky nature of pixel art to change the tileset resolution without decreasing the image quality.
I found that you get overall better looking graphics if you change the tilesize to match the horizontal resolution of your monitor (tilesize=(horizontal resolution/80)).
I put up some screenshots that demonstarates this but they are from the previous version of Tileset Resizer and the 45x45 tiles were getting off square, this should be corrected in the new version.
New screenshots will be up later today. 

I put a sample of the current Phoebus tileset resized to 24x24 tiles below if you want a quick look at the results.

Spoiler (click to show/hide)

[Phoebus]

That's a preferance in texture filtering.
The standard texture filter is 'linear', which generate the final pixel color based on the color of the (up to 4) nearby pixels weighted by proximity.
This causes a blurry final result.

The texture filter that arclance uses (and that I use for the tileset assembler when zooming in) is nearest, which picks the color of the nearest pixel. Sharper but more jagged.

The problem with Dwarf Fortress right now is we can only pick one texture filter for both zooming in and zooming out.
If we could select two separate texture filters, nearest for zooming in and linear (or better) for zooming out, we would get better results.

[arclance]

That's a preferance in texture filtering.
The standard texture filter is 'linear', which generate the final pixel color based on the color of the (up to 4) nearby pixels weighted by proximity.
This causes a blurry final result.

The texture filter that arclance uses (and that I use for the tileset assembler when zooming in) is nearest, which picks the color of the nearest pixel. Sharper but more jagged.

The problem with Dwarf Fortress right now is we can only pick one texture filter for both zooming in and zooming out.
If we could select two separate texture filters, nearest for zooming in and linear (or better) for zooming out, we would get better results.

How do you change the texture filter for zooming in and out in Dwarf Fortress?
Found it.
Change [TEXTURE_PARAM:LINEAR] to [TEXTURE_PARAM:NEAREST] in init.txt.
If you resize the tileset you are using with Tileset Resizer to match your monitors horizontal resolution you should only need to worry about the zoomout method because the tileset is at the max zoomin size.

I wrote a Tileset Resizer function for each of the interpoation methods that can be used in octave (except spline I can't figure out what is causing the error I am getting).
The results for resizing from 15x15 to 10x10 pixel tiles is below for comparison. Warning it is a large image.

Spoiler (click to show/hide)

I think cubic looks the best.  What does everyone else think.

[Shandra]

The problem with Dwarf Fortress right now is we can only pick one texture filter for both zooming in and zooming out.

Alike to JASC (former manufacturer of PaintShop Pro) suggested - Bilinear for downsampling and Bicubic for upscaling (I am not sure what corel have made of that once great program right now)...
And I am still puzzled why we have so many more algorithms for resizing in VideoApplications (especially MeGUI) compared to pure image apps (puzzled because the scaling takes place in each picture and I am not sure what exactly is different, or why they are not used in classic raster apps), ie.: Lanczos, Point, Spline(, etc.)... And furthermore why the video apps let us choose in bicubic and others for a strength value (weighting parameter) but in pure raster apps its always 1 (not sure if the weighting happens over frames - but as it is named strength I would say just in single frame)....
That is a major conflict in me (with me) whenever I encode/capture my old VHS tapes or not secured DVDs and somehow my used RemoteSensing/Raster knowledge is questioned by Analog2Digital/Interlace/Film/Pulldown/etc. :insane: and thereafter the simply question wich method to use in resizing (well, actually that was the cause for me to go/stay anamorphic in the encodes)... sigh (but that simply is no answer to my questions that occurred in the process)

So far as we can just zoom out my prefered method would be (only using the classic three (nearest/bilinear/bicubic) according to JASC and not counting RemoteSensing Context) bilinear - but as my GFX knowledge is besides nowadays GeoReferenced Images just good old DPaint and Amiga IFF Pixel Art, I really can't comment on the methods of handling resizing but somehow still can on the handling of methods to resize images :yikes::insane:

Oops... overlooked that one:
   arclance: nearest is a default by me since I played the pre 2010 Versions on my laptop as
   that whatsoever certified FireGL Pro on the build in TFT produced ugly results with bilinear
   (not on an external CRT) - besides less colours (yes, our eyes may not be able to differ
   them, but that what is not visible but diplayed makes it smooth and for some spectral
   analysis 1024 is better then 256 per channel) on TFTs that is still one of my arguments to
   stick to CRTs (not that this Laptop GFX Adapter is able of 48bit+, just a general thought
   about the Matrox Cards (CAD/RemoteSensing/GIS Area) I really would like to buy)

[arclance]

Alike to JASC (former manufacturer of PaintShop Pro) suggested - Bilinear for downsampling and Bicubic for upscaling (I am not sure what corel have made of that once great program right now)...
And I am still puzzled why we have so many more algorithms for resizing in VideoApplications (especially MeGUI) compared to pure image apps (puzzled because the scaling takes place in each picture and I am not sure what exactly is different, or why they are not used in classic raster apps), ie.: Lanczos, Point, Spline(, etc.)...

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.