Bay 12 Games Forum

Please login or register.

Login with username, password and session length
Advanced search  

Author Topic: Planning your fortresses pixel by pixel (AKA-The 1x1 Pixel-Perfect Tileset/Mod)  (Read 10094 times)

Itnetlolor

  • Bay Watcher
    • View Profile
    • Steam ID

Here is the 1x1 pixel tileset (use with the ASCII tileset/init/raw settings for best results) I am using from now on if I find a good site, and want to make my building plans with Paint.Net so I can plan things pixel-by-pixel. I made it because I was getting tired of switching out windows between DF and Paint.NET to render any planning for in the land of the site as well as the construction planning still WIP as I build it as well. This is to simplify the entire process with minimal effort.

Prototype Curses-Based Tileset (direct download, R-Click and Save Image As...) (Instructions below)
(NP) Modified Curses-Based Tileset (No image made yet; same instructions as the above one)
(NP) Ironhand-Based tileset (Compressed-file-link: N/A)
(NP) Phoebus-Based tileset (Compressed-file-link: N/A)

Mod-based tilesets will come along if/when I feel like it, and may be posted in their relevant threads. This tileset is mostly for showcasing locations in Worldgen Cookbooks in greater detail and also fortress/megaproject planning for use as reference material (via programs like Paint.NET or Photoshop or even GIMP). I might research how well this can work alongside Quickfort as well.

Feel free to volunteer your efforts in making 1x1 Pixel Perfect Tilesets of other mods if you want. Just remember, the game is already quite abstract (super-simplified), this is taking it to 11 and beyond. If you can still render it playable, then this is the most abstracted method of play possible. Like above stated, this is primarily to extract maps for reference material if making fortress or megaproject plans; it was not intended to be playable, but I accept the challenge to see if it can be possible. Contingency plans to keep it relatively playable are in the instructions below. To render a pixel-only game playable still, ensure the context is absolutely clear between units, buildings, and otherwise; or simply put, know your game, and tileset it's based on; know your palette and color coding. It renders the game playable, even if all you're looking at are literally just pixels.

If you're producing them, thanks to this thread, ensure that you're making the right kind for the right version. ASCII is as simple as a single image, whereas graphical sets use multiple images. For best clarity, keep it consistent. If you're reducing a 16x16 tileset, then make sure that the reduction is 1/16 the size, and the pixels are in the same exact spots as the sprites that were there previously; and use the original image as reference for clearing up context. Anything within greyscale (0-255 black to white) will change color if a palette-capable unit; keep them a consistent shade, or color them as something else entirely, and independently from others. Oh yeah, and mind your buildings as well; for graphics are still shared between tiles and tilesets. Just a friendly heads-up in case you're volunteering for 1x1 converting tilesets.


Fun Fact: Measuring at 1pixel=1tile; Each image is 240x240 (area=57,600 tiles Per-Z) large, which is a 5x5 region selection as well. A little math later, and it is estimated each region tile on embark is 48x48 (2,304 tile area Per-Z) each. Which also means the largest area you can claim is 16x16 region tiles, tallying a grand total of 1 entire region being 768x768 fortress mode tiles (589,824 tiles per-Z level!!! O_O. One pixel screenshot is nearly a screen big (with old CRT monitor limits)). I'd be wary of making embark region previews this way; but at least you can be thorough about the area you're checking out/showing off/deciding to embark upon. This can really simplify things since there are essentially no graphics being rendered; just area pixels. Doesn't mean the computer won't wince, however, upon loading it. You've been warned, and the red pixels will warn you as well if you go on anyway.


So far, it works like a charm. For example, look at this extraction from TamedEarth, with the overlay of my building plans:
(Topography maps have been added to showcase other things you can use to help out via Paint.Net referencing.)
(it's subtle, but you can see the individual region tiles in the greyscale.)

(Now with the transparent sky filled with +10 (of 255) alpha sky per-layer)
(Actual Size from (E)xporting from game at TamedEarth (initial save with untouched land, besides the starting wagon))
Check out the full (unplanned) map here (same as bottom map): http://mkv25.net/dfma/map-11696-tamedearth1x1tilesetsample
Full-scale reference here: http://mkv25.net/dfma/map-11566-tamedearth

(TIP: for better clarity, I suggest you also turn off ground variations for a more uniformed appearance for the grounds. I didn't do it here. Lazy Newb Pack has the option in the menu.)






Of course, due to the nature of the layering, I can either hide or set transparencies to the relevant layers to simulate the game's layer viewing; or delete all sky-tiles, and do similarly; or like what I did here, delete the sky-tiles, and add a layer of a brighter sky-color, and have that at a set transparency to assist in my aboveground construction planning. Naturally, it's an independent single-color layer that's placed between the layers I'm working on.

For underground, I would suggest using Reveal first if you intend to coordinate the colors, or ensure you don't plan too deep to the point of intersecting the cave systems. However, this should help a great deal for designing underground plans as well.

Since it's a 1x1 tileset, it will naturally be unreadable, unless you have a good memory of the menu, commands, and etc., then it shouldn't be too much of a problem. Really helpful for designating complex mining in-game, but this tileset is more for extracting a map for work on programs like Paint.Net or any other program that supports layers (especially if you can import them in numerical order).

To easily extract your map for pixel-planning, I would suggest that you only set the 1x1 tileset for either windowed view or fullscreen view, but not both. Extract the images from the map, and then optimize if you want (the BMPs aren't even all that big anymore), then import them into your program, and delete the sky of each layer if you want (as simple as the magic wand tool at 0%-tolerance setting, click the sky, and delete), and then add layers relevant to the layers/Z-levels you're planning as to not tamper with the original land (in case you're planning around a color scheme or something underground or something of the sort). This actually made my planning in the future crap-tons easier to do, and it's still a generous space-saver and even resource-saver when working on it, since we're going at it by-the-pixel, instead of full-detail.

I hope this helps everyone as much as it helped me. Happy planning!

EDIT:
I just realized, if you feel like making pixel art in your forts, this should simplify the process really quick. Just as well, since we're down to the pixel, counting the amount of tiles/blocks used for constructions and such, along with measuring things out should be really simplified as well.

EDIT EDIT:
I also just thought of something; if it's possible to simplify the process, using DFhack and maybe an extra window, would it be possible to make a clearer mini-map for use alongside the game? I mean, the images are really tiny, so it shouldn't take long to extract and update at a time.

One other thought, this should assist with scaling things for future projects, along with converting portions of your map or project into arenas for Arena Mode. Just make sure to refine the colors before you input it as a replacement.

EDIT EDIT EDIT:
Oh right, here's the settings I suggest you use with the ASCII/Curses tileset:
And shut off [varied ground] while at it. Enjoy!

EDIT EDIT EDIT EDIT:
Official name now given; and also suggested implementing this into DFHack somehow. So far, it's still an interesting idea/suggestion to work with. Don't get your hopes up. From all I listed, it may take a bit of work to get done, and may take awhile for somebody to get on it. Still, it was fun pumping out ideas for it as a more fully-functional/practical plugin.

In the meantime, check out my latest posts for details of my progress of making this a more functional tileset. OP will be updated accordingly with relevant links and downloadables as I work on it (when I feel like it).

EDIT EDIT EDIT EDIT EDIT:
That little fun fact I put up there inspires me to make a desktop background of a pixel-rendered set of regions, cropped to a screen size. Might require 4 entire regions stitched together to make the most of it for all screen sizes.
« Last Edit: April 25, 2013, 09:32:01 pm by Itnetlolor »
Logged

doublestrafe

  • Bay Watcher
  • [PONY_DEPENDENT]
    • View Profile
Re: Planning your fortresses pixel by pixel
« Reply #1 on: April 24, 2013, 05:42:01 pm »

This looks pretty darn neat. How do you get back from the pixel drawing to the actual construction, though? Is that just manual? If so, is there a good way to check for human error?
Logged

Itnetlolor

  • Bay Watcher
    • View Profile
    • Steam ID
Re: Planning your fortresses pixel by pixel
« Reply #2 on: April 24, 2013, 05:58:25 pm »

Well, from pixel to tile, it's as simple as having a full-scale tileset and this one assigned separately (see (code) box for how I have it setup to do that), but still playing in the same game. Just change viewing modes on the fly.

Alternatively, after optimizing and composing the map images into a PDN file, I build my plans in Paint.NET, and have it open alongside DF. Of course, after I had my fun with exporting a pixel-by-pixel map, I restore the tile settings back to the tileset I was using previously (like Phoebus, for starters).

This is more of a quick-rip solution since I was feeling excessively lazy on the whole planning front. Plus, in the long-run, this should really help out with my other forts and megaprojects (like where to build my scaffolds and airship(s) and such). This also helps out with planning and/or coordinating mechanisims and trap setups and so forth. In case you have lots of traffic to assign, this should also help out with designation highlighting, burrows and so forth (F11 if you need to read).

But yeah, switching out between pixel and full-scale is as easy as hitting F11, if you have the Init setup correctly. Perfect resolution for mapping out complex fortresses without too much adjusting if you're playing DF with it active.

EDIT:
Just got another idea: Would it be possible to get a map extraction (globally or regionally) like what I have made (1x1 pixel tiles) detail viewing on the embark screen? Could work well with DFHack at least (all that's being rendered are single pixels-per-tile). Get a better preview of where you're planning to embark (It'll be just as vague as using Prospect on Embark, so no big whoop)). It's not full-detail, but it's better than nothing, or a super-abstract format; use it alongside Isoworld for better reference-detail (unless you explored it with Isoworld previously, then it's not as much needed). Unfortunately, I'm crap where programming is involved, so somebody with better know-how can see if this is possible or a good idea.

Like I stated with the minimap idea, it might have to be a separate window/non-gui interface. Kinda like how Stonesense can be summoned.

EDIT EDIT:
On the plus side, if you want to show off some epic sites in the Worldgen Cookbook threads, this tileset is perfect for showcasing the most basic details of the sites. And instead of using DFMA, you can always animate the layers from bottom-up or vice-versa as a GIF or animating PNG file. There should be few enough colors to get away with GIF just fine though.

EDIT EDIT EDIT:
If you don't feel like working with pixel-by-pixel, but love the simplistic nature of the tileset, then feel free to expand the image 2x-3x, then feel free to just expand the image that way (or showcase your map in a larger size). Characters won't be so easy to see or make (if making a tileset for reference), so again, this is mostly to make things easier to see or to work with in Paint or similar programs. Adding details to characters would be more for playing with a smaller tileset than usual, even if it makes specifics difficult to read. If you understand the context of what you're seeing with your own game, then no worries.

If you pay close attention to the tileset I made, I make adequate use of the shades to tell certain things apart from each other as best as possible; albeit extremely abstract. Units darker than the surroundings is the best solution I could come up with. Alternatively, working from 50% grey, and differentiating things via greyscale could help (walls are lighter than floors, and dwarves are lighter than letters and kobolds; at least, the pixels of them are; depth and foam-related cells are a gradient so you can tell them apart. Ramps and stair-based tiles can also be different shades (dark=down, light=up, 60% grey=up/down)). But to avoid all that extra work (also because I'm really that lazy), just stick to the instructions to have a full-scale (or at least readable set) in either windowed or fullscreen mode, but not both.
« Last Edit: April 24, 2013, 06:39:24 pm by Itnetlolor »
Logged

Hamiltonz

  • Bay Watcher
    • View Profile
Re: Planning your fortresses pixel by pixel
« Reply #3 on: April 24, 2013, 09:37:30 pm »

I like where you are going with this.  Please keep us informed.

On a related note.  When I started experimenting with quickfort it was difficult for me to visualize what all the symbols where going to turn into, so I started to cut-paste images of the tileset from the screen.  I also placed walls around where I mined out hallways.  From my past work with spreadsheets I knew I could place an image in each cell and that would not effect quickfort.

It was great to have a visual of my intended fort that was also useable to directly create that fort.  The image hides the text symbol so I would copy the entire cell and past in the new location inorder to keep things working.

After reading this I realized that those cells could be 1x1 pixels.  The data in the cell does not need even 0x0 pixels to be functional.  If your tileset conveys enough information that would mean that an entire fort could be viewable within the spreadsheet editor.

Looking forward to a complete tileset with reduced pixels!
Logged

Itnetlolor

  • Bay Watcher
    • View Profile
    • Steam ID
Re: Planning your fortresses pixel by pixel
« Reply #4 on: April 24, 2013, 10:12:44 pm »

If I am to expand on this, I may or may not need to refine the default ASCII color palette to make things clearer overall, seeing as we're now restricted to single pixels. In some cases, I might even have to mod the raws so that everything is a particular color each. But like I mentioned before, as long as you have a full-scale to work alongside with (F11) to keep contexts clear as you work, it's kinda pointless to do so. However, it could still be possible to do so for the sake of a clearer mini-map upload if you're showing a minimap to others (especially animating ones).

What I noticed with my map, however, is that all that really needs to be taken care of to tell things apart clearly enough is just do as I was with the greyscale. By the layer, as long as you can tell the black spots on the map as trees (confirmed with the green dots immediately on top by the next layer), then everything's okay.

I might take on my other prospect of starting from 50%-grey and adjust accordingly to the symbols of most-common use. (up/down = light/dark, and both is a lighter shade of middle ground, to tell it apart from the ambient surroundings; whether it can be told apart or not (most relevant especially with constructions and cave systems/mined out forts).

A minor caveat to the 50%-grey base coat is that everything will be darker overall, but other things will be more visible, up or down, instead of just down. So at least something could come out of it.

EDIT:
Just decided, for the hell of it, to replace the sky I deleted in all the layers with sky again, except at 10/255 alpha transparency per-layer. Gives me a good idea of the depth of the land. An idea, all sky-based tiles in such a program as I mentioned before can be mapped at a subtle greyscale adding +1 or +2 transparent black or deep blue like I did with the image (though mine is +10, not +1 or +2) for a greyscale heightmap to use for the minimap to retain a depth of field if you're viewing from the top-most visible layer (-max-height (usually +10 from highest point; most common worldgen setting)). That inverse-heightmap based on sky-tiles could help out in building plans on hilly/mountainous locations.

I'll have to say, it looks pretty good. I added it to OP.

With transparent sky heightmap.


(And with 3-layers/z-levels chopped in alternating fashion (3z each on and off); geology untouched)

I suggest doing this instead of going through the tedium of animating a GIF. It's absurdly simple. Just paint-bucket the sky area transparent per-layer, and save as a flattened image (PNG, preferably). Gets the message across about the detailed land with topography mapped out more clearly. By-layer, as a minimap, it can help out colossally with Stonesense.

Doing all this makes me appreciate Paint.NET so much more as a planning platform.

Like I mentioned before, it's just a tileset, and all these screenshots are me dicking around with Paint.NET and different ways to use them in tandem (more as a way to keep track of your fort-building progress/foresight). No special programming done; however, I do invite anyone with programming and DFHack know-how to render this concept as a live-minimap you can use in-game in greater detail than what is normally given, or as a previewer of embark locations so you know where to place your embark team before you embark (best for determining the shape of the rivers and waterfalls and such).

EDIT EDIT:
And realizing what you're actually requesting, that sounds like a rather tricky challenge to pull off. It will require my greyscale idea to use shading to differentiate between particular tiles (might need to look into the Phoebus tileset for reference, since I'm using that one the most), and maybe an idea of adjusting the palette (suggestions are welcome), if you're intent on using this tileset to export to quickfort.
« Last Edit: April 24, 2013, 11:21:32 pm by Itnetlolor »
Logged

ChuckWeiss

  • Bay Watcher
    • View Profile
Re: Planning your fortresses pixel by pixel
« Reply #5 on: April 24, 2013, 10:52:05 pm »

This'll go great with the 60x40 screen resolution on my TI-89 calculator. Now if you could only make a gray-scale version... Anyway, that's a really ingenious way to plan a fort; I'm definitely gonna give it a whirl.
Logged
When he dies for the Mountain, the Mountain will weep not tears, but Blood for the Blood God!

Itnetlolor

  • Bay Watcher
    • View Profile
    • Steam ID
Re: Planning your fortresses pixel by pixel
« Reply #6 on: April 24, 2013, 11:04:52 pm »

This'll go great with the 60x40 screen resolution on my TI-89 calculator. Now if you could only make a gray-scale version... Anyway, that's a really ingenious way to plan a fort; I'm definitely gonna give it a whirl.
Considering Quickfort and other LNP included tools that operate pixel-based, this can especially help out if you want to duplicate structures or complex designs you made and want to share, and to add into Arena Mode, even (I suggest you mass-hide everything and do a DFHack cleanup first if you want a clean copy; otherwise, I hope you enjoy tracing over the faulty spots caused by blood, vomit, or poor creature/dorf/garbage/stockpile placement. And Yes, stockpiles will be visible as well, so I suggest you eliminate everything for a quick screen, and then restart from the save beforehand.).

Come and think of it, since the pixel-tile is theoretically possible to use (completely) backwards-compatibly, I can always see what I can do about cutting out the Bloodfist to use as a battle arena. Naturally, due to the limitations of Arena Mode, there won't be any props or anything else included on the ship, but it will still make a pretty kickass arena nonetheless. And extracting it with this tileset would be a cinch.

Go nuts if you can nab any other places/projects/maps to convert for arena mode. Unfortunately, it would require the save to make it work, but the rest of this is dead simple to install (on pretty much any version of DF, if I'm not mistaken). It's just like installing any other tileset. Just remember that if you still want it playable, replace Fullscreen or Windowed mode's tileset, but not both. Since it's 1x1 tilesize (16x16), if you can't figure out the ratio, then I'll beat you over the head with a fluffy wambler.

EDIT:
Considering the topic, should I move this over to the modding board instead?
« Last Edit: April 24, 2013, 11:38:46 pm by Itnetlolor »
Logged

slothen

  • Bay Watcher
    • View Profile
Re: Planning your fortresses pixel by pixel
« Reply #7 on: April 25, 2013, 10:12:33 am »

This looks cool.  Here's my takeaway.

-you can switch graphics packs with F11 and even the size of the tilesets??? so switching to 1x1 tiles is basically like zooming way out in game.  That's cool.
-Are you doing designations in game with the 1x1 tileset at all?  or are you somehow doing it all first in paint.net and just using them as reference?  Or are you actually exporting the alterations in paint.net in some way that makes it designate stuff in game for you?  Or perhaps, all of the above.
-because you're altering 3 and 3 in the previous image, it functions as a topographic map.

It would be cool if you could post some step by step instructions for simple tasks (not delving into a paint.net tutorial) that you use, basically for covering how the graphics pack, the image exporting/importing, and quickfort interact.  But you don't have to.
Logged
While adding magma to anything will make it dwarfy, adding the word "magma" to your post does not necessarily make it funny.
Thoughts on water
MILITARY: squad, uniform, training
"DF doesn't mold players into its image - DF merely selects those who were always ready for DF." -NW_Kohaku

Itnetlolor

  • Bay Watcher
    • View Profile
    • Steam ID
Re: Planning your fortresses pixel by pixel
« Reply #8 on: April 25, 2013, 10:36:25 am »

This looks cool.  Here's my takeaway.

-you can switch graphics packs with F11 and even the size of the tilesets??? so switching to 1x1 tiles is basically like zooming way out in game.  That's cool.
-Are you doing designations in game with the 1x1 tileset at all?  or are you somehow doing it all first in paint.net and just using them as reference?  Or are you actually exporting the alterations in paint.net in some way that makes it designate stuff in game for you?  Or perhaps, all of the above.
-because you're altering 3 and 3 in the previous image, it functions as a topographic map.

It would be cool if you could post some step by step instructions for simple tasks (not delving into a paint.net tutorial) that you use, basically for covering how the graphics pack, the image exporting/importing, and quickfort interact.  But you don't have to.
1. Yep. I figured that if the game can tell the two tilesets apart (640x480 and 800x600), then it shouldn't have any trouble transitioning between any other size tileset and 1x1. Thank god it didn't result in crashing the game.

2. You can designate, and even play the game normally, while in "Pixel Mode", but if you intend to read or understand things in greater detail that requires readable fonts and such, or don't hve all the commands memorized, or just want to watch things move at ultra-low-rez after setting things up, then just toggle between modes with F11. Of course, I only have this tileset optimized to work with the vanilla Curses (ASCII) tileset. Optimizing for other tilesets (seeing as the raws are different between different tilesets) will take much more work, although I can always color-code different creatures and such through that; but like I mentioned before it will take a bit more work to convert them down to single pixels, and making sure their contexts would be clear in-game (units may need to be brighter than the grounds they walk on, and walls and such slightly brighter than the grounds they are next to).

I export the map, and use it like a minimap or a designation reference sheet after/as I edit it in Paint.NET. There's no way to re-import the image back into the game to do such outside of quickfort (but alas, I don't use it, so i have no clue on that front; not saying it's impossible though. I just don't know the process, since I don't use it). It shouldn't be too difficult to do so, however; especially since I think it only interprets single-colors, and special-designates according to them. The simplistic coloring (especially if you're basing off designations which are single-color anyway; making adjustments shouldn't be all that tedious in the long-haul) should make fine-tuning things for import via quickfort simpler, since the minimap makes an excellent frame of reference since it's accurate pixel-by-tile (1-pixel = 1-tile), and coordination is as simple as knowing your map or having a window open with your plans in there for reference.

3. I realized that a 2-by-2 would still get the context across quicker, and I can even animate it if I want as an animating topographical map. I tried 1-by-1, but the treetops and other features keep on obscuring things too much.


I don't use Quickfort, so I can't really delve into that detail; but installing is as simple as downloading the 16x16 image, and replacing the appropriate mode you intend to view it in (windowed mode requires resizing the window after opening, but will show 1x-2x scale in-game; fullscreen will almost always display 2x-5x scale in-game (minimum display visibily?)) with the tileset. As for exporting the images, this is also why I suggested that you have the opposite mode at full-scale, F11 so you can read the options and such, and highlight the layers like you normally would, F11 again back to "Pixel Mode" and then hit the export button.

Importing into Paint.NET is is simple as compressing the BMPs to PNGs first (from 22KB down to 2KB per-layer; at least in the case of my map)), and then highlight all the layers (Top-most to bottom-most) and drag-n-drop the file stack  into Paint.NET and add as layers. The last image you click-drag becomes the bottom-most layer, which is why you should drag-n-drop from top to bottom layer. It's just a pain to drag the bottom-most layer all those levels from the top layer.

Making things topographical in PDN is as simple as either making the sky a transparent shade, to topo-map (2x2 works better than 3x3; come to think of it; removes the layer, and their upper-portions (tops of trees and walls and such)), just alternate the layer visibilities on-off 2 at a time (works best if you already removed or made the sky tiles transparent for better visibility; blending modes don't help much). As for animating, you can always find a plugin for PDN or do all this in Photoshop instead, and do the usual routine with animating gifs. Just remember that GIFs have a 256-color limit, and any shading may be compromised in the process. If you can make animating PNGs, go for that option instead (permits more than 256-color animating images; AKA- APNG files), provided you can view them and/or have the appropriate plugins for the relevant program to do so.

EDIT:
OP now has installation, export, and Paint.NET instructions added. I'll need some practice/experience with Quickfort before I can add instructions relevant to that, unless anyone has already done their part, then feel free to contribute.

Now with a greyscale Topo-map (extracted by the sky):

And a colorful topography map as well (increments of 5 hue per-layer starting from 0 (red)). Like I stated in the DFMA, one of the layers are missing, mind the inconsistency. (globally delete sky (magic wand), reselect area, invert selection, and replace/erase with foreground color (starting from 0 hue, 255 saturation, and 255 transparency, adding +5 hue per layer; good for 51 layers of topography at that setting.). Bottom-most layer highlights all water instead of sky to assign "ground zero" and highlight water/aquifer areas.

Kinda wish there was a way to automate this process a bit more. Similar to the map extraction methods you can use so you can import them into Isoworld or 3d rendering programs. Hell, an enhanced minimap is still a very practical idea that can be based off of this. So, like I said before, if anyone has any programming talent to do such a thing, that would rock. DFHack should be able to help out with doing that.
« Last Edit: April 25, 2013, 12:53:16 pm by Itnetlolor »
Logged

Itnetlolor

  • Bay Watcher
    • View Profile
    • Steam ID
Re: Planning your fortresses pixel by pixel
« Reply #9 on: April 25, 2013, 12:55:33 pm »


I can't program worth crap, but I know the capabilities of DFHack, so far. So these are some possibilities I think can be done through it, provided someone knows how to do this with a bit of tinkering and scripting.

EDIT:
As I posted and am modifying this post, I'm also adding this to the DFHack suggestions thread. This is too good of an idea to pass up. And what I have in mind generates maps based on raw data, rather than what I'm doing with screenshooting, and composing together. This is more for artistic coordination between DF and Paint/pixel planning; with potential for Quickfort import/exporting. And on that note, using raw data to interpret designations, carved out and constructed land/buildings and such, should allow for making Quickfort that much more useful and integrated into the workings of DF, thanks to making use of DFHack.

EDIT EDIT:
In the meantime, as I let my ideas settle, I might see what I can do to improve on these pixel tilesets to make them easier to read as you export, and maybe work on adapting graphical tilesets to use pixel-based tilesets as well. It'll be a bit of interpretation work, but if I can keep it easy enough to tell apart, live and exported, then we'll be golden. As of now, the Curses 1x1 is pretty good, but can use some modification (maybe re-adjusting it to a 50% grey set, and basing other graphical sets off this system), so that exports and even live-playing can yield something rather playable, even if it's completely unreadable. This is what I would call a completely context-based tileset. You have to understand what's going on because it's even more abstract than it already was.

I may need to resort to the DFWiki for character reference for the best shade/saturations to use (walls are always brighter than floors, for example); and graphical sets, the most common color of various shades and color blends (like a good middle-ground between green and purple will signify a zombie goblin, and a green-white can be a skeletal one or something). I will try to isolate as many units as possible according to hue and color similarities. There will be a common color-ground and saturation-ground depending on various factors. Like dwarves will always be among the brightest units visible, since you're keeping track of them the most; and the heirarchy goes according to importance/relevance. At least, that's how I'll go about the graphical tilesets. As for the Curses Tileset, I'll do my best to make it work. There's more variety with the select few characters I have to work with; at least with graphical sets, I have more variety of characters, and the limits can extend.

This actually makes for an interesting project on the side.

Consider the official name of this The 1x1 Pixel-Perfect Tileset/Mod.

It will improve as long as I feel like working on it. In other words, don't count in immediate updates to happen.

EDIT EDIT EDIT:
Added instructions for any volunteers willing to do this with other tilesets and such.

Reminder: Context is everything. We're essentially translating things into static "white noise" (+color), and keeping it potentially still playable. Just so you understand the challenge that lies before you if you're taking on what I am about to do with the Vanilla sets. Color can mean just about anything. Curses and the Vanilla base set for graphic sets makes up just about anything and everything: See here for reference, along with the tileset you're working with (pay close attention to the Graphical ones as well, and peek at their raws even for more detail as to what to best color them as).

Basically, the artistic challenge of still rendering this rather playable all depends on if the color relays the message clearly enough. Because color (and in some cases, shade) along with their behavior on-screen is all we can tell of our subject(s) in mind. The ultimate challenge is still being able to tell them apart by color and shade alone since our detail is rendered as a single pixel (and workshops and wagons 3x3-5x5 (unless modded to be larger)). So yeah, like I stated before, context is absolutely everything, understand it and what you're trying to get across to render something seemingly unplayable as something actually playable, if you know what you're looking at, even if it's just a pixel.

Funny enough, this (when finished) can make certain pixel-art made in-game as visible as the sprites they represent. Albeit, a tad difficult to see or coordinate at first glance. Unbelievably, I will try to make letters and numbers as easy to tell apart as possible, so all you need to do is recognize the menu shades between screens. Can you tell 230/255 apart from 233/255? What about 145/255 and 150/255 (all based on 0-255 greyscale). Alphanumerically gives me 36 separate shades (numbers take up a 10-shade grid of their own, while the alphabet takes their own; accents optional). Other characters will be based closer to their context-usage in-game. We have a total of 256 characters to work with (since there's a blank, make that 255 characters; but some characters in Curses can get away with having the same shade, for visibility reasons; especially if they differ enough between uses that you can still tell them apart, despite being the same shade.).

Now you see what I have to work with, and that's just for the Curses/Base set alone (which I would have to say is more difficult to work with than a graphical set; since symbols are shared across the board, and not independently from each other; and I gotta make sure the shades of grey are in the right contextual sense. On that note, no 50 Shades of Grey (or 256 Shades of Grey) references, please.). At least with graphical ones, I have more colorful flexibility to work with.
« Last Edit: April 26, 2013, 10:54:25 am by Itnetlolor »
Logged

Itnetlolor

  • Bay Watcher
    • View Profile
    • Steam ID

In case you're wondering why working with pixels is taking so long, here's what I'm up against/got done so far.

Spoilering for convenience; but these are my notes I'm using for this whole ordeal, which is so worth the effort once I'm through. I might setup a rough draft. And in case you're wondering why the alphabet and number notes are like they are, the water notes and offsets are divisible by 7 to denote the depth of water/magma, using 4/7 as the middle-ground (127/255 (50% grey)) to balance off of, since that's the most common visual reference. I could step it up higher, like 75% grey; as long as the floors and walls are just as consistent in shades to clearly tell apart. Head's up, since we're working with only white, foreground colors are exclusively referenced, unless it's any of the pink cells, then it'll be the background. Good to know. And any other shade with pink in the background will only make a lighter or darker pink, not a blend of fore and backgrounds.  After all, they're pixels-per-tile/cell.

As for the alphabet, I'm scoring their brightness values according to Scrabble rules (most recent set for Super Scrabble). All additional items will be based on their most common visual reference and how useful they are.

This is the pain in the ass about working with the Curses Set. The Graphical Tile Sets will be a crap-ton easier to work with, since it's more diverse, and has fewer shared symbols overall.

And now, finally, the notes, so far:

And the color chart I overlay/multiply on top to simulate how the greyscale is affected by the default palettes. (16 complete layers to change between for color-compare and visibility safe-zoning)

That's all just to get a bead on what to shade them as in the pixel tilesheet. I still have to go through the tedious process later on to actually individually pluck all the values, and paint them in. And naturally, I still have to field test it.

I wasn't kidding when I said there's alot of work put into this. And applying modded versions alternatives may vary slightly. Once I finish this Curses 1x1 Set, feel free to base off it for any of your mods, or mods you want to apply this to. I did the work so you don't have to do as much.

In essence, theoretically, we should now be able to read once it's applied. Yes, I somehow made pixels readable.

EDIT:
While brainstorming how to go about this, I realized that you can hide bar codes ad QR-codes in your fortresses. They'll especially be visible in pixel mode, or at a particular zoom level. Have fun hiding messages, or applying your signatures in your forts via bar/QR codes.

Designating them is one way, but to build it, would make for an interesting rune for adventurers to pass by. Who'd know that Stonehenge was relaying the message "FIRST POST!" using a circular encoding, for example?

Or the Great Pyramids, from above, when scanned, leads to a Burger King Value Menu? Just an idea of what the adventurers see, and what we, as players (or gods), would see.

EDIT EDIT:
Overall, by the end of all this, I hope parts of the map just pop out and looks awesome, and we can tell everything apart from each other, including the letters and numbers. That's the goal, and I'm feeling optimistic, based on my notes. I've been fine-tuning the most important elements first (especially the alphabet and numbers; the scrabble method seemed wiser than resorting to q QWERTY or DVORAK assignment. Most-used characters are the brightest, least-used are the darkest, based on a well-known board game's rule set we're well familiar with. I speak, of course, of Scrabble. Here's my clearer reference sheet (using Super Scrabble's).). I hope everyone enjoys the final product. It'll definitely look better than the flat palette I used in the prototype.

I know it'll be worth my time, and everyone's curiosity once finished.

I think the most awesome thing to see is the topography of the map due to the variations between up/down hills, and the land, and no longer having to guess what was where. However, if you want to make a smooth gradient like I have on the previous flat maps, the prototype version will still be there for use. Only the walls and dwarves have been darkened. Everything else is 255/255. Like I said, all those variations is what this is all about. Context with a 256-greyscale with color overlay given by the raws is what I'm trying to get across as clearly as possible; to the point you can even read pixels.

Considering the possibility that this is naturally backwards-compatible, if anyone still has the Planepacked save, I want to see what the description looks like with this tileset used; and see if it's passable as readable. Is it indeed possible to read 1px text? That is something I will definitely pat myself on the back for achieving with this.

Furthermore, now that I look back at all this, I have yet to render a world map. I hope those maps look just as badass once finished, and you get a full-depth view of everything top-down; and every bit makes perfect sense still; even by-the-pixel. Overlay the heightmap exports as well, even, to see a full-depth map.

PROGRESS REPORT:
I'm going to at least get the letters and numbers in and see how it reads. Hopefully, it's relatively readable at the lowest possible scale.

UPDATE:
It's relatively readable, but you'll need to have the characters and their associated colors memorized. But all that aside, you can tell each and every one of them apart from each other.

I also patched up a shading bug that made the silhouettes brighter than the current layer. Still a bunch more work to do, but at least the writing is down, and much of the fort is actually more understandable this time around. I can actually tell layers apart as I navigate, I can also tell dwarves apart from items and buildings, for now. Empty trade depots are easily identifiable, as are constructions and carved out fortresses; however, I'd still stick to my advice to shut off varied grounds. Varied grounds makes interiors of mountainhomes rather disorienting, as well as some portions of land.
« Last Edit: April 26, 2013, 09:42:42 pm by Itnetlolor »
Logged

Itnetlolor

  • Bay Watcher
    • View Profile
    • Steam ID

Here are some new screens of my progress so far:
Before and after 1: Layer above river. (Before: Spring of 51, Just arrived at embark)
1:          2:
Before and After 2: +1z above the front gate of the fort. (After: Autumn of 55, post-siege, and successful defense.)

NOTE: Varied Ground is still active in both images; for consistency.

And yes, constructions and smoothed/engraved walls and floors are far easier to tell apart from rough ones and dirt caves and such.

Still got a bunch more work to do, but it's looking nice so far. I can tell things apart far easier now, compared to the Before images.

EDIT:
I tested out no-variations, and things immediately got that much easier to look at with this. However, after doing a reveal to check out cave systems, ugh. It's just a clusterfuck in there.

Looks like I still have a lot more work ahead of me to simplify those; but at least the surface is easier to understand.


A high five for anyone that knows this screen (Modified to fit, and enlarged for readability; actual size nearby)
                   

Maybe instead of separating numbers by 7, I should make it 14 or 21 for higher contrast.

I also noticed that I still have to still make the world maps work with it as well, and make sense. However, they still look pretty awesome, albeit, really flawed still. Like stated, much work still remains before I can call it done.

EDIT EDIT:
Reason the trees are highlighted is due to the seasonal difference. However, you should easily be able to spot the farms and the backbone of my drop-bridge system (since we're above it in that image; It's a better way to showcase the land difference between z-levels). Obviously, darker land is below us, lighter land is current layer. I haven't adjusted the tree-top blocks yet, so they still stick out like sore thumbs.

My next work, since I got the text part knocked out of the way, is going to be making the world map easier to interpret all kinds of extra and some shared characters, and then extra items in the tileset. And then one final adjustment to the main fort/adventure mode portions of the set that may no longer look right post-processing of the prior.
« Last Edit: April 27, 2013, 03:30:42 pm by Itnetlolor »
Logged