Tile editing

[GoogleCodeExporter]

Hi, haven't followed development for a while, but I'm happy to see so many
new features put into what's maybe my favorite app ever.

So, I wanted to ask you, you haven't happened to add a tile preview mode,
have you? I can do the same by copy/pasting my tile, but it's too much
effort when you want to see changes immediately, so I'd really like to see
an area of the screen where a chosen region is displayed at an
user-selected zoom level, tiled 2x2 or 3x3, so I can see how well does my
tile, well, tile.

Come to think of it, some advanced tile/sprite editing features would be
nice. A switchable 'tile edit' drawing mode which (invisibly) separates the
image into small sections (tiles, sprites) of user-defined size. The
currently selected (by clicking in it) section would have a nice inverted
border, would be displayed in the aforementioned tile preview
window/box/space/whatever, and, most importantly, things like flood fill,
>1x1 brushes, etc., would be clipped to it. I hope you understand what I
mean, because I believe this would be a blessing for game artists and the like.

And then comes animation... Animated preview, and animated tile preview, too...

I haven't fully explored the new version yet, so I wouldn't know if any of
this has been implemented yet, but I thought I'd share my ideas before I
forgot most of them. Sorry if it's a bit random.

Well, back to making sprites...

Original issue reported on code.google.com by fallenbl...@gmail.com on 25 May 2010 at 3:58

• Merged into: #195

[GoogleCodeExporter]

Yes, that's likely the most important missing features in GrafX2. They'll come. 
I 
have little free time right now (studies, summerjob, and some other personal 
projects 
running around), but Yves is still busy improving GrafX2, so likely they'll get 
in 
someday :)

Original comment by pulkoma...@gmail.com on 25 May 2010 at 6:46

[GoogleCodeExporter]

Hi, just managed to build the source. If I have some time later, I'll try making
myself a bit more familiar with it and then maybe implementing this and that.

Original comment by fallenbl...@gmail.com on 26 May 2010 at 6:19

[GoogleCodeExporter]

Start of discussion on Tiling is in Issue 195. The system described by iLKke 
looks
very tempting, but it puts a lot of constraints. I still haven't found a way to 
code
it that wouldn't make it difficult for future development.

Until we implement something, you can check the trick I describe in comment 6 of
issue 195. One advantage is that you don't need to reserve a whole page for it, 
you
only need a bit of room in a corner of a page. This way you can keep other 
graphics
nearby, to help consistency.

Issue 274 is about symmetry, maybe they are linked... Deluxe Paint had them as a
single tool; I can't think of a case where you'd need both at the same time; 
and if
we can manage to implement them both with a single system, the loss of 
performance
may be less important than if we code them independantly of each other.

There's the issue of clipping: All drawing tools are clipped to the visible 
image,
with the only exception of "Adjust" (scroll) and "Color Replacer" tools.
- If tiling mode has clipping, it will look ugly when you edit a large carpet of
tiles and some parts are left unchanged.
- If tiling mode has no clipping, we need to add a clipping check at the pixel 
level,
in the pixel drawing engine, and this is sometimes called hundreds of thousands 
of
times per second. This will reduce its speed even when you don't use tiling 
mode :/

Original comment by yrizoud on 26 May 2010 at 9:28

[GoogleCodeExporter]

Maybe only a small sidebar/frame/floating window containing a 3x3 preview? It 
could 
also contain a tileset when needed, or the frames of an animation, etc.

Original comment by fallenbl...@gmail.com on 26 May 2010 at 12:00

[GoogleCodeExporter]

We can't implement floating windows at all during drawing. (All GUI is coded 
from
scratch)
The idea of a new frame is interesting, I wouldn't have thought of that. 
However, I
find it doesn't fit well with the current views : Sometimes you need a normal 
size
preview to check that no unwanted "pattern" appears; other times you want to 
study
the "seams" closely, so you need it zoomed. And when you have such view that 
occupies
your work space, you'll want to draw on it directly, just like you can draw on 
normal
and zoomed view, and get immediate feedback. So in the end, you will still need 
a
mode where you can both see the repeating tile, zoom and pan it, and draw on it.

Original comment by yrizoud on 26 May 2010 at 1:12

[GoogleCodeExporter]

I was thinking of something along the lines of this (sorry for the lousiest 
mockup
ever, I'm not quite sure how to take a good screenshot of grafx2)

The "..." buttons would show windows containing respective options - things like
zooming, number of tiles in the preview. Of course, based on user demand and 
common
sense, some of the options would probably get out of the options windows and 
onto the
sidebar itself. I forgot to make room for scrollbars and so on, but I hope you 
get my
idea. The same basis could be used for animation frames, too.

What bothers me the most is the storing of data for tilesets/spritesets. The 
user
could input tile width and height every time, but if we decide to have things 
like
sprites of different sizes in the same file, it would get messy. Metadata?

Original comment by fallenbl...@gmail.com on 26 May 2010 at 3:53

Attachments:

• gfx.png

[GoogleCodeExporter]

I think when you enter tile-drawing mode, tiles should replace the palette so 
you 
can pick them easily from there. If you don't want to touch the palette, it can 
also 
be done as a strip-bar like layers (a 16px tall one), displaying a set of tiles 
on 
the right and some info on the left. Only the 16x16 topleft (or center ?) 
pixels of 
each tile would be displayed (or a scaled version ?)

As for storing, each tile can likely be stored as a frame in a gif file.

I think we have to separate the process of building tiles from the one of 
putting 
them together. Building a scene with tiles is easily done with the grid mode, 
if you 
ease picking tiles (capturing them with the lasso will quickly get boring). 
Unless 
we allow to use the lasso singleclicking any grid area to capture a whole tile 
? 
Then you can load your tileset as sparepage and switch to it to pick tiles and 
put 
them inside the real picture.

When drawing the tiles themselves, it would be nice to have all the tiles in a 
single file; but this may be as frames in an "animation". Then, it's only a 
matter 
of duplicating the picture in the viewport instead of filling it with black for 
a 
start.

Original comment by pulkoma...@gmail.com on 26 May 2010 at 4:58

[GoogleCodeExporter]

Yes, I am talking only of building the tiles - but viewing them as frames in an
animation is a completely different approach from what I was thinking, as I 
prefer
having all the tiles in a single continuous image, quite like in my mockup, and 
I
think this is the general approach. So having tiles stored as frames in an 
animated
gif then putting them back together again while editing would be overkill. I am 
also
against changing the workflow by creating a dedicated tile editor. I believe 
the tile
editing facilities I described would fit right in, as I think that changes 
should be
as unobtrusive as possible. I'm currently working on a small patch concerning 
brush
stretching - when that's done, I'll try and implement a rough sketch of how I 
see
stuff working.

Original comment by fallenbl...@gmail.com on 26 May 2010 at 5:27

[GoogleCodeExporter]

I'm not sure about a vertical sidebar, it would take quite a lot of code, 
create 
problems with the zoom area management, and likely break some other things. 
Also, it 
takes 48px at least, that's 15% of the screen in 320x200 mode, quite a lot. In 
your 
mockup you used 1x1 pixels while the menu is using 2x2, so you think you have a 
lot 
of space available, when in fact you don't.

I think when drawing tiles, you actually WANT to draw on a 3x3 grid filled with 
the 
tile. This make it possible to have it tile perfectly without even noticing. 
And I 
still think it's better to do it in the picture area.

Well, I won't force you if you write the code yourself and apply the patch 
anyway :)

Original comment by pulkoma...@gmail.com on 26 May 2010 at 5:42

[GoogleCodeExporter]

Yeah, there's a lot to be considered (: I do keep in mind that the sidebar 
would have
a lot less space available, it's just that I couldn't be bothered to draw it
accordingly :D I get your point about drawing on a tile grid, and will see if I 
can
come up with something to combine our ideas (:

On a side note, why is the interface always drawn in 2x2 pixels? We could 
implement
pages in the menu, so that in 2x2 mode page 1 would what it contains now, and 
page 2
- more advanced functions which would be generally switched more rarely, e.g. 
tile
management, maybe the FX moving there to free space for some new tool on page 
1; and
in 1x1 mode both would fit in a single page. Still, this would all be quite a 
big
change, if not too big. Just mentioning it as an idea (:

Original comment by fallenbl...@gmail.com on 26 May 2010 at 5:57

[GoogleCodeExporter]

It's not actually always 2x2, there is an autoscaling system. The idea is we 
need to 
be able to run on a 320x240 screen, like on the gp2x.
The windows don't adapt to the screen size for a simple reason : it's painful 
enough 
to layout them and write the event loop for static windows like this...

Original comment by pulkoma...@gmail.com on 26 May 2010 at 6:04

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 9 Aug 2010 at 9:43

• Added labels: Component-Tools

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 22 Aug 2010 at 1:39

• Added labels: Mil

[GoogleCodeExporter]

Original comment by pulkoma...@gmail.com on 22 Aug 2010 at 1:39

• Added labels: Milestone-2.3
• Removed labels: Mil

[GoogleCodeExporter]

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

• Changed state: Duplicate