Yep, sprites again.
While working on cobblestone generators, it occurs to me that there's no way to indicate a bottom slab in a top-view. I had also been thinking we'd need arrows, but then I realized we can use HTML entities/Unicode for that. --Mental Mouse 01:33, 21 April 2013 (UTC)
- I think text arrows are really only good for the cardinal directions, but that should be enough for cobblestone/obsidian generators. But for more complicated water/lava, we'd need 16 direction arrows.
- Any ideas for bottom slabs?
- This topic seems like a good place to start a "wishlist" for more sprites:
- crops (melon/pumpkin stems, melon, sugar cane, wheat, carrots, potatoes, nether wart) -- I think an overhead and a sideview would be enough for each, we don't need to show all the possible growth stages
- water/lava directions
- torches (the regular kind)
- stairs (will necessarily add sprites for planks, bricks, nether brick, and block of quartz)
- glass panes
- Anything else?
- —Munin295 ·
· 04:41, 21 April 2013 (UTC)
- Hmm. For the bottom slab, you could emphasize the edge textures and maybe show a bit of highlighting. For crops, you'll want a common "sprout" texture as well. Directions: 16 arrows? Like, north-north-west? If the game actually tracks fluid direction that closely, then I guess so.... Last night I thought about diagonal minecarts for sloped track, but then I thought it through. ;-) Imagine trying to make those play with the table grid! --Mental Mouse 10:50, 21 April 2013 (UTC)
Well, the origins of the template have just turned around to bite me. When dealing with cobblestone generators, I've discovered a mechanism or two that need "SB" -- an opaque solid block, a transparent block (they're using glass, I'll want to build-test that slabs do work), and a filler block that explicitly can be opaque or transparent. May I request an "any" sprite, perhaps based on the iron block? (That's what they were using.) --Mental Mouse 22:36, 21 April 2013 (UTC)
- "…can be opaque or transparent…" -- not sure what you mean. If you mean it doesn't matter what kind of block is used, then I'd just use dirt or grass, or just keep using SB to keep it consistent. I'm trying using grass in some of my sideview schematics to show how you'd build them on the ground -- I like it so far.
- There's a sprite/id for glass if you want it.
- —Munin295 ·
· 00:04, 22 April 2013 (UTC)
- Yup, doesn't matter if it's opaque or transparent. In screenshots and videos, some people do them in glass for visibility. I'm already using dirt for temporary blocks, needed for building but then removed. I guess I could use grass, but it feels weird. Maybe stone brick. But then, that's the point -- without a standard identifier, everyone picks something different. BTW, the description for SB and perhaps MB should probably indicate that at least in circuits, they mean opaque blocks. --Mental Mouse 02:02, 22 April 2013 (UTC)
- I was probably thinking of this when I added stone bricks to the sprite sheet -- I can't think of any other reason I put it on there (most other blocks on the sprite sheet are there because I thought of a redstone circuit or mechanism that used them). Stone bricks are kind of the go-to block for simple architecture -- easy to make from mining and looks "constructed" -- I see it in a lot of Let's Plays. I guess it's probably a good choice for "there needs to be a block here for structural reasons, but not for redstone reasons".
- Let's see … "structural block"? no, SB is taken. "construction block"? no, CB for command block. "Building block"? BB, not bad. BB for "building block", defaults to stone brick sprite for starters?
- —Munin295 ·
· 07:11, 22 April 2013 (UTC)
- Why not "AB" for "'any' block"? Stone brick sprite is fine.--Mental Mouse 10:41, 22 April 2013 (UTC)
- I've added AB with the stone brick sprite.
- I'm still not sure what to do about bottom slabs. For now, maybe just indicate them in captions or text?
- —Munin295 ·
· 16:02, 22 April 2013 (UTC)
- Thanks for AB. Re; bottom slabs, that's what I've been doing so far. Incidentally, top slabs can be pushed or pulled from below, which looks peculiar. --Mental Mouse 21:35, 22 April 2013 (UTC)
- Yep. You can alternate top and bottom slabs in a piston-pushable stack too. : )
- I like to use slabs instead of glass in circuits where a sticky piston pushes a block up with sand on top of it.
- —Munin295 ·
· 22:41, 22 April 2013 (UTC)
- Thanks for AB. Re; bottom slabs, that's what I've been doing so far. Incidentally, top slabs can be pushed or pulled from below, which looks peculiar. --Mental Mouse 21:35, 22 April 2013 (UTC)
- Why not "AB" for "'any' block"? Stone brick sprite is fine.--Mental Mouse 10:41, 22 April 2013 (UTC)
Hey, I just noticed that your "Note Block" sprite appears to depict a jukebox instead. Also, I'm wondering if we should relax the guidelines on transparent blocks a tad, to this: "If it has to carry redstone, use the top slab, if not, you can use glass". Glass is kinda pretty, it seems a shame to effectively ban it from schematics and screenshots. --Mental Mouse 23:53, 22 April 2013 (UTC)
- Fixed (mostly). The sprite sheet could use an additional sprite to distinguish note blocks from jukebox sides, but it shouldn't be an immediate problem.
- It wasn't my intention that top slabs should be used for all transparent blocks, only when you need the dust feature, so if that's the impression the guidelines are giving, yeah, the guidelines should be changed. I'm not aware of a good category name for the blocks that have that feature (glowstone, upside-down slabs, upside-down stairs, hoppers, and technically blocks of redstone I think) so I may have just used "transparent" too broadly.
- —Munin295 ·
· 00:27, 23 April 2013 (UTC)
- OK, sounds good. I'll probably fix it after dinner (also need to mention ts-u in the appropriate place). A thought: Should there be an AB-u? Pro is utility, con is: squintiness, also do we really want to be encouraging dual-level diagrams for more than redstone? They are much rougher on the page limits, and I'm thinking of mentioning that in the guidelines too. --Mental Mouse 00:44, 23 April 2013 (UTC)
Yup, me again, fresh back from chicken ranching.
- I realized that besides glass panes (noted up top), you don't have fences.
- Also, it might be handy to have end-on images of repeaters and comparators -- I just ran into a case where I needed it. (I used the existing side-view sprite and noted it in the caption.) Admittedly, that was a cross-section rather than a side view, in Tutorials/Egg Farming. You can probably get away with entirely skipping the repeater delay, thus "rr-$n" and "rr-$s". (Frankly, I'd rather have numerals or even dots than have to read the slider position anyhow, but whatever.)
- For the bottom-slab-from above (
bs?), we just need something. How about doubling the border width and perhaps rounding the corners by a pixel? (As if it had rounded edges on top.) Or if that's too fancy, just make it somewhat darker than the top slab.
--Mental Mouse 03:16, 6 May 2013 (UTC)
- Another ID rather than a sprite: I've just discovered that duplex I/O isn't half as exotic as I'd thought, since the basic RS latches display it prominently and usefully. Probably oughta get its own ID. (IIRC, light blue wool was the original prescription for duplex.) Also, did you get anywhere with the material+cutout approach to stairs? --Mental Mouse 10:08, 21 May 2013 (UTC)
- I haven't been working on the sprite sheet. I want to spend what little time I can writing.
- Technically, whether to have a separate sprite for I/O is a style guide issue, but since you've found an additional reason to have it I withdraw my earlier objection. : )
- —Munin295 ·
· 17:50, 21 May 2013 (UTC)
- I see you're simply using
bWfor duplex i/o. If it's going to be a convention, we should probably have a specific identifier for it.inout?duplexio? - —Munin295 ·
· 23:31, 25 May 2013 (UTC)
- I see you're simply using
Suggestions
Schematic size
I've seen quite a few schematics using size=24. I would recommend against doing this, because it results in a distorted image. In fact, you should probably change the size parameter to be a multiplier (of 16), instead of a size in pixels; as anything that isn't a multiple of 16 will cause distortion. Then the schematic would default to size=2, instead of 32.
Spritesheet size
The default size of the schematic is 32, but the spritesheet is only 16. This means that the default size schematic requires the browser to support a way to tell it to use "nearest neighbour" image scaling, otherwise the image will be blurry. We have the styling that does that, however it is just a suggestion as far as the browser is concerned, so it is not a reliable way to force "nearest neighbour" image scaling.
The solution to that would be to scale up the spritesheet to 32. This wouldn't increase the filesize (as long as the image is compressed) and then the scaling suggestion will only be necessary for the lesser used size 16. This also means you can use those extra pixels to smooth out things like the wall torch.
Tooltips
Things like multi-layer schematics can be pretty difficult to understand, even when you've read the schematic guide. To help resolve this, I would suggest adding tooltips to each cell, which explains what it represents. At least for the more confusing parts.
For example:
This may have to wait until lua though, since this template is already slow enough as it is.
Schematic code mistakes
I've seen a couple of common mistakes with schematics that have been written, so I think it'd be best if the template could handle them properly.
- |- on the last line. Causes an empty cell with no height, so it looks like an extra 1px of border on the bottom of the first row. Should be ignored entirely.
- Not enough |'s to make enough cells to go to the end of the row. Causes a blank white space with no borders. Should automatically fill in the necessary cells so there are no gaps.
Again, this will probably need to wait for lua.
–ultradude25 ᐸ Talk
Contribs 06:20, 22 May 2013 (UTC)
- Thanks!
- The only time I've seen distortions at size=24 is when I'm using browser magnification, and that causes distortion with all sizes. But the distortion at size=24 is worse and we can't tell people not to use browser magnification so this is probably a good suggestion.
- I didn't realize increasing the sprite sheet size wouldn't make the file size huge. I'll definitely look into that. Mental Mouse wants me to get back to work on the sprite sheet anyway. : )
- Tooltips would definitely be a useful addition, but I'd rather just fix author mistakes than add more complexity to the template. : )
- I'm not confident that lua is going to be a solution for Schematic. The tests done on wikipedia seems to indicate speed increases of ×3, ×5, or even ×8 for some applications (mostly string handling, I think) -- but the lua timeout is 10 seconds rather than the current 30 seconds, so it might only be a marginal improvement (in terms of how many schematics we can put in an article -- the user experience will definitely be better), not the order(s) of magnitude we really need. But I'll definitely start experimenting with it when it arrives.
- —Munin295 ·
· 16:34, 22 May 2013 (UTC)
- Drat... size=32 makes a lot of the schematics seriously overpower their text, and some of them quite big. --Mental Mouse 12:54, 23 May 2013 (UTC)
- Could the sprites be cropped a bit, while still being recognisable? –ultradude25 ᐸ Talk
Contribs 22:30, 23 May 2013 (UTC)
- Could the sprites be cropped a bit, while still being recognisable? –ultradude25 ᐸ Talk
- I don't like the idea of cropping the sprites. Before that, I think I would consider adding a separate size=24 sprite sheet. That would mean downloading two sprite sheets for most articles (the current one is <70kB), but that shouldn't be a problem for most users and they'll get cached anyway, right?
- How bad are the 24px distortions you're seeing? I only see them with browser magnification and they're barely worse than the rest.
- —Munin295 ·
· 23:31, 23 May 2013 (UTC)
- What would be different with the 24px sheet? It'd still have the sprites cropped?
- The distortions are apparent on anything that isn't a solid colour, which is everything. Looks at the edges of the gold block, and the redstone torch on the repeater for the most obvious ones. –ultradude25 ᐸ Talk
Contribs 00:44, 24 May 2013 (UTC)
- Ah, well personally those distortions don't bother me at all (I had to get up close to the screen and squint to see what you were talking about). As long as you can see what component it is, it's probably fine.
- A separate 24px sprite sheet would mean the browser wouldn't have to do any scaling to display a size=24 schematic (which is turning out to be as convenient a size as 32). Or rather it would move the scaling to the image editor used to produce it (GIMP, in my case). But I've just tested it and it either gives the same distortions with no interpolation, or it just makes it fuzzy, so: not a solution.
- Mental Mouse, for large schematics which are overpowering the text, consider moving them to float=none Loadboxes under the paragraph or section, instead of regular schematics or floated-right LoadBoxes. They're not so bad there, so maybe they could go back up to size=32.
- —Munin295 ·
· 01:29, 24 May 2013 (UTC)
- Maybe my screen just has poor pixel density (it is only 1080p after all), but the distortions are really noticeable to me, without having to go close to the screen.
- I don't think the cropping will really work. For the more simple sprites you can shave off some pixels in the middle or spacing around the sides without affecting the look too much, but for more detailed sprites (like minecart tracks) I really don't see it working. Instead, I'm wondering if we could get rid of the nearest neighbour scaling for 24px (and have the spritesheet scaled up to 32px). It looks slightly blurry, but you don't loose entire rows of pixels, so it looks more readable to me. –ultradude25 ᐸ Talk
Contribs 02:02, 24 May 2013 (UTC)
- Hmm. For size=24, nearest-neighbor looks much better than blurred interpolation on my screen (1920x1200). We may need a tie-breaker. : )
- Interpolation makes everything fuzzy. No more crisp edges at all on any of the sprites. The schematics look like they're underwater or something (to me).
- —Munin295 ·
· 04:02, 24 May 2013 (UTC)
- http://matt-russell.com/images/sharex/2013/SS_05-24_02-56-58PM.png
- To me, it only looks blurry on the transparent edges, mostly noticeable on the wire. Which I still think looks better than the entire image having distorted pixels everywhere.
- Either way, it'd be better to avoid size=24 as much as possible. –ultradude25 ᐸ Talk
Contribs 05:01, 24 May 2013 (UTC)