General > General Discussion
Official Off-Topic Thread 2018
Crow:
This year's off-topic thread! Not quite as late as last year's :P
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 casesPseudocode:
--- Code: ---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)
--- End code ---
Oh, and I'm still waiting:
--- Quote ---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)
--- End quote ---
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.
--- Quote from: yrizoud on January 06, 2017, 01:23:37 pm ---I think you intend this for "material" tiles...
--- End quote ---
Not particularly. For any continuous transition across tile boundaries where a tile can connect to more than one other for a boundary.
--- Quote from: yrizoud on January 06, 2017, 01:23:37 pm ---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.
--- End quote ---
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.
--- Quote from: yrizoud on January 06, 2017, 01:23:37 pm ---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.
--- End quote ---
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.
Navigation
[0] Message Index
[#] Next page
Go to full version