Official Off-Topic Thread 2018

[Crow]

This year's off-topic thread! Not quite as late as last year's

[surt]

Image editor tile-map editing idea:
Boundary-correct multi-tile editing

• Function to duplicate edits across tile boundaries for all connected tiles
• Editing mode, on activation builds list of neighbors for each tile-boundary pair and maintains lists while activated
• When a brush is drawn across a tile boundary (edge or corner) every tile which shares that boundary with the an instance of an involved tile also get drawn to with corresponding offset
• This could be particularly handy for hi-res/soft-brush tiles as per-pixel touch ups are less feasible in those cases

Pseudocode:

Code: [Select]

workList = []
boundaryList = []
foreach tile boundary intersecting brush
  workList.append([tileIndex, boundaryId, brushOffset])
while !workList.isEmpty()
  [tileIndex, boundaryId, brushOffset] = workList.pop()
  boundaryNeighborList = getBoundaryNeighborList(tileIndex, boundaryId)
  neighborBoundary = mirrorBoundary(boundaryId)
  neighborOffset = brushOffset + boundaryOffset(boundaryId)
  foreach neighborIndex in boundaryNeighborList
    neighbor = [neighborIndex, neighborBoundary, neighborOffset]
    if !boundaryList.contains(neighbor)
      workList.append(neighbor)
  boundaryList.append([tileIndex, boundaryId, brushOffset]);
foreach [tileIndex, boundaryId, brushOffset] in boundaryList
  drawBrushToTile(tileIndex, brushOffset)

Oh, and I'm still waiting:

Some non lazy person make the following:
Pico-8-like virtual console, hybrid of NES and SMS specs
Can fairly accurately simulate specs either NES or SMS or be an amalgam of the best bits of both (eg. both tile and sprite flipping)
In-virtual-console editors plus on-desktop editors for less constrained editing
No 128x128 resolution, NES and SMS resolutions as well as integer scaled or aspect corrected fullscreen (no black-bars) approximations (eg. 384x216, 480x270)

[yrizoud]

I think you intend this for "material" tiles which have many combinations, like these :
(from http://www.gamedev.narod.ru/TileBasedMap1_new.htm)
But then I'm not sure it's safe to deduce the edges from a sample map... You can miss some links if your sample map doesn't have all cases, and you can get false positive which makes your drawing deface unrelated tiles.

Personally, in such case, I would re-edit the tileset with a smaller grid size which cuts each tile in 4x4 =16 smaller squares. There will be many common sub-tiles, and thus drawing on them will repeat the drawing on the similar graphic elements which are in an other tile.

[surt]

Oops, messed up indentation in the pseudocode.

I think you intend this for "material" tiles...

Not particularly. For any continuous transition across tile boundaries where a tile can connect to more than one other for a boundary.

But then I'm not sure it's safe to deduce the edges from a sample map... You can miss some links if your sample map doesn't have all cases, and you can get false positive which makes your drawing deface unrelated tiles.

That's why it would be a mode, not an always-on feature. You would use it when your image is in a fit state for it to be used, when your work image is laid out with all desired tile connections.
Alternately one could use manually specified connectivity data but that would require special user interface.

Personally, in such case, I would re-edit the tileset with a smaller grid size which cuts each tile in 4x4 =16 smaller squares. There will be many common sub-tiles, and thus drawing on them will repeat the drawing on the similar graphic elements which are in an other tile.

I don't see how that helps matters. It multiplies the number of transitions in the tilemap, it reduces the number of transitions in the tileset but at the cost of tile variation and doesn't solve the problem of duplicated effort for matching tile transitions.

[eishiya]

I tried writing a shader today to do Photoshop-like "darker color" blending for 2D rendering, and never again. Since I can't sample the existing buffer safely, I have to make a copy between each "layer", which requires restructuring some otherwise perfectly fine code in a way that makes it worse (I have to use textures everywhere to be able to sample from them, instead of using more general render targets), and I got stuck trying to get the correct position into that copy anyway, so I just decided to make do without it.
I might still play around with shaders for other purposes, but multi-layer multipass rendering requires more caring than I can currently muster. I can do single-pass stuff, and I can do post-processing after everything is rendered. That's enough.

[surt]

Don't know what API/version you're using, but OpenGL's Image Load Store is handy for this kind of thing. So long as you are operating on pixels independent of their neighbours no need for for a copy and bypass sampler nonsense, can bypass all the render-to-texture nonsense too if you use compute shaders. D3D has an equivalent too but can't remember the details that'd be RWTexture*.

[eishiya]

Don't know what API/version you're using, but OpenGL's Image Load Store is handy for this kind of thing. So long as you are operating on pixels independent of their neighbours no need for for a copy and bypass sampler nonsense, can bypass all the render-to-texture nonsense too if you use compute shaders. D3D has an equivalent too but can't remember the details that'd be RWTexture*.

Using OpenGL, and that's handy! I decided not to do the darker color shader because even with that it's more hassle than it's worth it to me xP But I'll probably find a use for that in the future when I'm more comfortable with shaders in general. Sticking to really basic stuff for now.

More OpenGL shader ???ing, in case anyone's in the mood to read about a noob struggling with the basics!
I'm playing around with applying color maps and I've just broken my brain. As far as I'm aware, OpenGL texture coordinates have their origin at the bottom left, and that's how it's worked so far. I am using this colormap for testing:

It has its origin at the top left, and the y coordinate corresponds to green (high y = high green). So, this should mean that in my shader where the origin is at the bottom, high green should mean low y, achieved with y = 1.0 - green:

Code: [Select]

vec2(pixel.b/16 + floor(pixel.r*16)/16, 1.0-pixel.g)But that makes a mess, and it seems I should be directly using green as my y coordinate:

Code: [Select]

vec2(pixel.b/16 + floor(pixel.r*16)/16, pixel.g)This gives me the desired results (hardly any visual change to the image). Am I misunderstanding something? Having a brainfart? When the green component is 0, I'd expect that second coordinate to mean the bottom of the color map, so why is it giving me the top?

Edit: Maybe it's something to do with SFML and how it handles textures? Now that I think of it, I think my previous attempts also had y = 0 at the top, it just didn't matter as much on those so I didn't notice.

[surt]

The idea that OpenGL texture coordinates are upside down comes from clip space being positive up, so if you directly map your UV coordinates to clip space position it will draw upsidedown. UV 0,0 still equals texel position 0,0.

[eishiya]

I think I understand! So as long as I'm sampling from textures rather than drawing them, the coordinates start at the top left?

Another question to demonstrate my ignorance of all things GPUs: Can I expect rounding in GLSL to work the same from GPU to GPU or is it a crapshoot/implementation-dependent?
For example if on my computer my math maps the colour #212842 to R=2, G=2, B=4 on that colour map (position 36,2 in the image), can I expect it to map that way for everyone, or might it be a pixel off for some people? With the colours on that test map it doesn't matter, but with another map it might.
The reason I ask is my manual calculations don't match the output, and it seems like rounding issues. In my calculations I floor everything. I suspect it's actually not a rounding issue though, but just it landing on a boundary between pixels and failing to correct for it. Though that said, some of my values are off by significantly more than half a pixel. Will keep pondering it! If I fix my math and it still doesn't work as expected, then I'll complain properly.
(Edit: Making sure I was sampling pixel middles fixed the inconsistencies and everything is beautiful.)

Thanks for your explanations so far! It feels nice to be a total noob at something again.

[surt]

Colour selector idea:
HSL wheel/sliders but lightness interpolates between an arbitrary black-level colour, the HS mid lightness colour and an arbitrary white-level colour.
Facilitate hue shifting to light and shadow colours.