Tile view : Tilemap mode

[GoogleCodeExporter]

It would be nice if there were a way to make the canvas repeat itself across 
all of the available 
window space, and actively update as the "master" tile is edited. It would make 
help a lot with 
making non-obvious repeating tile patterns for games and web and such.

Dunno if it helps, but this feature is available in another (unfortunately 
dead) open source project, 
Pixen ( http://opensword.org/Pixen/ ).

Original issue reported on code.google.com by cameron...@comcast.net on 16 Jul 2009 at 3:55

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Not so easy to do, but we'll have a look at it. It may slow the program down 
enough 
to make it unuseable.

Implementation note: maybe the duplication could be done at the level of fake 
hardware zooming or after it, to avoid moving pixel data around too much.

Original comment by pulkoma...@gmail.com on 22 Jul 2009 at 3:23

• Added labels: Component-GUI, OpSys-All

[GoogleCodeExporter]

Performance hit is unavoidable with such function, but anyway when you do a 
16x16
tile, you normally don't use big brushes.
When this function was active in Deluxe paint, you used a large canvas anyway 
and all
drawing was repeated. An alternative would be to have a canvas (image) as small 
as
the tile you want to repeat, and grafx2 displays an "infinite" pattern made of 
this
tile instead of a small tile on top left angle. Drawing should be possible at 
any
position, not only on the top left tile.

Original comment by yrizoud on 24 Aug 2009 at 9:52

• Changed state: Accepted

[GoogleCodeExporter]

While you are pondering this feature, consider the extremely powerful tile 
support
present in Cosmigo Promotion. Entering the tile mode can analyze the existing 
image,
counting the unique tiles used, based on the grid size you input(canvas size 
has to
be a multiple of this grid size). You can then continue to edit the image with 
all
the tiles updating across the screen 'in realtime'(not really, see below). In 
the end
you can even automatically have the program make the tile-set based on the 
image.

To speed things up, repeating tiles are not updated until you let go of the 
mouse
button, instead you just see the stroke in the place you are performing it.
Furthermore, if you draw out of bounds of the tile that you started your stroke 
in,
that part of the stroke will be ignored, effectively limiting the whole stroke 
to a
single tile.

Also, this kind of feature would be much more usable if the grid could be made
visible (not sure if anyone suggested visible grid earlier, sorry)

Original comment by ilija.melentijevic on 24 Aug 2009 at 10:16

[GoogleCodeExporter]

update: Visible grid = issue 171

Original comment by ilija.melentijevic on 24 Aug 2009 at 10:19

[GoogleCodeExporter]

Thanks for the details.
The whole system you describe is rather smart, and it replicates what I've been 
doing
for 8 years now with Grafx2 (where I draw full tiled levels) and a custom "tile
packer" which compresses the levels into a tilesheet and several tilemaps :)

Instead of limiting the mouse drawing area to one tile, it may be better for us 
to
wrap the drawing to the other side of the tile. It would make it easier for the 
user
to draw across the limits of tiles.

I'm still a bit annoyed by the whole "update on click release", but I 
understand the
performances can be a problem, especially with a giant bitmap (whole level).

An easy trick you can already use to work on individual seamless tiles: Make a 
brush
which is made of evenly spaced pixel according to your tile size, for ex: 
(ascii art
follows) 
.  .  .  .
.  .  .  .
.  .  .  .
.  .  .  .
Such brush can be used instead of single pixels, and will draw or alter 4x4 
tiles at
a time. Works with all effects, such as shade, etc.

Original comment by yrizoud on 25 Aug 2009 at 2:41

[GoogleCodeExporter]

If the grid is auto-identified on image load, how do you replace a tile by 
another 
or create a new tile from an existing one by drawing in-place ?

Original comment by pulkoma...@gmail.com on 25 Aug 2009 at 6:03

[GoogleCodeExporter]

I guess you only activate this mode to replicate changes over existing tiles. 
If you
want to differentiate a "detail" tile from a uniform wall, disable this mode, 
then
draw, then reactivate it.

Original comment by yrizoud on 25 Aug 2009 at 9:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 15 Sep 2009 at 7:13

• Added labels: Milestone-2.3

[GoogleCodeExporter]

I am also in favor of a tiled mode. I tried to find one ( see
http://forum.freegamedev.net/viewtopic.php?f=6&t=97 ) in open source pixel art
editors and didn't quite found what I was looking for yet.

If any of you can run Mac apps, perhaps you could try 
http://opensword.org/Pixen/ 's
tiled view/edit mode? Perhaps they have an efficient implementation (I wasn't 
able to
do so as I can't run it).

Original comment by qubodup on 9 Jan 2010 at 5:42

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 5 Apr 2010 at 8:50

• Added labels: Component-Tools

[GoogleCodeExporter]

About tile support similar to Cosmigo Promotion:
One very good side of this system is that it allows patterns made of more than 
one
tile (ex: 2x3 tiles), and then all cases where the pattern has offsets as lines 
or
columns.

One idea of implementation is to make a tile array, whose cells contain the 
index of
"the next cell which contains the same tile". This allows a kind of circular 
list,
which is extremely quick to search/scan all cells that contain the same tile: 
The
search is made in constant time, no matter how large the image is.

The tile data has to be generated from scratch "only" in the following cases:
- You enter tile mode
- Undo, Redo (because you may reach a history step where tiles are different)
- Load
- Canvas Resize, and all picture effects (resize, mirror, rotate)
- Pan image

Fill has to be constrained to one tile.

Original comment by yrizoud on 27 May 2010 at 9:11

[GoogleCodeExporter]

Mh, I'm not sure I understand you.
How do you handle replacing a tile with another ? you have to unset his 
position in 
the previous tile referencing it, so you have to crawlback the list... do you 
have to 
seek from the beginning ? how do you know where is the first tile of this list ?

I think that instead, each tile should store the ID of the tile it's copying. 
But the 
downside is that when altering a tile, you have to browse the whole picture to 
update 
all the identical tiles...

Original comment by pulkoma...@gmail.com on 27 May 2010 at 11:03

[GoogleCodeExporter]

About first tile, indeed this piece of data is necessary. I can find no better 
idea
than a second map. Sounds expensive in terms of memory, but it's just big 
enough when
all tiles are different, and in all cases it avoids dynamic allocation on each 
unique
tile.)

While drawing (in this mode), the tile map stays unchanged. Image modifications 
that
require changing the tile map are the ones I listed; and since they are
"non-interactive", it's not a problem if they last 500ms, which is why I propose
simply recomputing the tile map from scratch.

When you leave this mode, the tile map is junked. It will only be re-created 
when you
need it, ie. when you enter the tilemap mode again.

One big advantage of the "tile support similar to Cosmigo Promotion" is that it 
keeps
the UI very simple:
- Only add a toggleable "Effect", which has no settings screen.
- Tile size is simply the parameters of the Grid

Original comment by yrizoud on 27 May 2010 at 12:07

[GoogleCodeExporter]

Ok, I added a tiles.c file in r1557 with some code to build the tile area. It's 
not plugged to anything yet. Feel free to play with it if you want.

Original comment by pulkoma...@gmail.com on 6 Aug 2010 at 4:45

[GoogleCodeExporter]

Issue 347 has been merged into this issue.

Original comment by pulkoma...@gmail.com on 22 Aug 2010 at 7:08

[GoogleCodeExporter]

A note on a possible way to do tiling in GrafX2 :
There's an apparently little-known 'tile' drawing effect. It can be used as 
follow :

 * Create your tilesheet on one page
 * Enable "tile" and "grid" effects (tile offset uusally 0, grid size = your tile size)
 * Grab a tile with the brush grab tool
 * Switch to spare
 * Use 'discontinuous' drawing mode (else you don't get full tiles painted, but partial ones, if the mouse moves too fast)
 * You can now paint the world with your tile
 * at any time, you can switch to spare and grab again

I think this should be useable with some help from a lua script, for example... 
but it's already quite good on its own.

Original comment by pulkoma...@gmail.com on 14 Feb 2011 at 5:55

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 15 Feb 2011 at 8:12

• Added labels: Milestone-2.4

[GoogleCodeExporter]

vote up from me for the real thing.

Original comment by cont...@leonard-ritter.com on 10 Jul 2011 at 11:44

[GoogleCodeExporter]

I made this script to extract tiles from an existing picture (warning, from 
spare to main page).
http://grafx2.googlecode.com/svn-history/r1823/trunk/share/grafx2/scripts/sample
s_2.4/picture/Tiler.lua

Is it useful ? Comments, ideas, and suggestions welcome.

Note:
for now the tile size is hardcoded in the scipt. I'm not sure wether it should 
ask on each run (I think that would get boring quite fast), so I'm considering 
adding a way to get the grid or tile settings from FX menu and use them in 
factory scripts.

It also lacks support for an initial offset, but I don't find that particularly 
useful either.

The script also generates a usage count for each tile, but I'm not sure what to 
do with it yet, so it's dropped at the end. It may easily be tweaked to also 
build a tilemap, but I don't know how to use that either. 

Original comment by pulkoma...@gmail.com on 24 Sep 2011 at 11:25

[GoogleCodeExporter]

Basic tilemap effect is implemented in r1858, it repeats everything you draw 
according to the Grid settings. Already useful for drawing a seamless tile.

Original comment by yrizoud on 7 Nov 2011 at 12:15

[GoogleCodeExporter]

r1858 isn't starting for me. I'm just replacing the .exe but I can't see that 
any other files has changed.

Original comment by annas...@hotmail.com on 7 Nov 2011 at 12:37

[GoogleCodeExporter]

The skin files have changed recently to incorporate the anim toolbar. (common 
skin format for the "layers" and the "anim" builds)

Original comment by yrizoud on 7 Nov 2011 at 8:50

[GoogleCodeExporter]

Ok, that fixed it thanx. Btw. The Effects menu "All Off" doesn't work for 8-bit 
& Tilemap.

Original comment by annas...@hotmail.com on 7 Nov 2011 at 12:26

[GoogleCodeExporter]

In r1859, started implementing ProMotion-like tilemap, just better:
- realtime update while you're drawing!
- drawing is not clipped inside one tile: you can freely draw on patterns made 
of several tiles, it affects them all as needed.
- image doesn't need to be an exact multiple of tile dimensions.

Optional detection of flipped tiles will be possible; It will slow down the 
analysis when you use it and start tilemap mode (x2 or x4), but the drawing 
should be as fast.

I've tried to imagine ways to synchronize the mockup (in main page) and the 
tile sheet (in spare page) while you draw, but then the Undo button would need 
to revert changes in both documents at the same time, this seems uncontrollable.

Original comment by yrizoud on 9 Nov 2011 at 12:27

[GoogleCodeExporter]

As of r1871, it's near-finished and very usable.
Note that the Tilemap mode will refuse to run (no effect) if the image is 
smaller than a single tile, or if the tilemap would exceed 1 million tiles (for 
example if you set grid 1x1)
The tilemap mode is on/off separately for the main and spare, so you can switch 
back and forth without losing the setting or forcing a tile analysis.
Copying the main page to spare (pixels) disables the spare's tilemap, if it was 
active.
The only known problems so far are:
- the visible grid gets erased by pixels of repeated tiles.
- No safety when a Lua script changes image size. Will be added.
- The "FX" button may not be updated (on/off state) when you swap to spare
- Undo/Redo forces a tile analysis every time. Very often it would be 
unnecessary, but it's not easy to be 100% sure without storing a lot of extra 
info. I think I'll force an analysis only when the image changes size, 
otherwise it's up to the user to determine if he should refresh the tile data 
(by disabling+enabling Tilemap mode)
- actions on layers don't cause a tilemap update. I think I'll use the same 
technique as above: let the user choose when he wants to disable or update the 
tilemap.

Original comment by yrizoud on 14 Nov 2011 at 10:46

[GoogleCodeExporter]

Is maximum Grid/Tile size 80x80? I'm currently working with 128x128 tiles and 
thought I'd try the tilemap-mode...

Original comment by annas...@hotmail.com on 1 Dec 2011 at 8:14

[GoogleCodeExporter]

It's up to 999 since r1869, the last windows build has it.

Original comment by yrizoud on 1 Dec 2011 at 8:46

[GoogleCodeExporter]

Ah, had it downloaded but forgot to install it...thanx!

Original comment by annas...@hotmail.com on 1 Dec 2011 at 9:17

[GoogleCodeExporter]

I just uploaded a windows build, it adds the missing safety in case a Lua 
script resized the image during Tilemap mode, and Undo/Redo should be smoother.

Original comment by yrizoud on 1 Dec 2011 at 11:02

[GoogleCodeExporter]

Still todo for 2.4:
- the visible grid gets erased by pixels of repeated tiles.
- No safety when a Lua script changes image size. Will be added.
- The "FX" button may not be updated (on/off state) when you swap to spare

Original comment by yrizoud on 9 Mar 2012 at 10:19

• Changed state: Started

[GoogleCodeExporter]

All fixed now! (r1929) Tilemap mode is fully operational.

Original comment by yrizoud on 11 Mar 2012 at 5:46

• Changed title: Tile view : Tilemap mode
• Changed state: Fixed