announcing Cocograph cocos tile map editor

[devon]

This is still very alpha, but I wanted to get a release out for pyweek
for people to use if they're interested. Cocograph is a tile map
editor for cocos2d that using kytten for the gui. Cocograph includes
pencil, eraser, zoom, and move tools and can create new maps and
tilesets without writing any xml. Ctrl clicking on a tile or cell will
allow you to edit, add or delete the properties and these changes will
be saved back to the orginal tileset when you okay them for tiles and
will not be saved until you save the map for cells.

download includes cocos 0.3, and kytten5, also a version with pyglet
so you don't need to install anything else. map examples from cocos
and threads of fate are included (and include your license,
Richard :) )
http://code.google.com/p/devdev-python/downloads/list

screenshots and documentation here:
http://code.google.com/p/devdev-python/wiki/Cocograph

There's still a number of bugs and a few planned features that are not
implemented yet.

-Currently clicking outside of the map when you create a new one will
mess up the event handling for on_drag (I think..) which affects the
tools, but this doesn't happen when opening a map for some reason...

-Saving a map will change all property types to unicode and change any
requires filenames to absolute paths in the xml. I believe these are
both issues with the tiles library and reported a bug about the
property types.

-I tried using the latest revision of cocos tonight but it gave me a
batchnode error about too many arguments for set_child or something so
I just included cocos 0.3

Features planned for the next release:
-flood fill
-layers
-drag selection clone tool to easily clone large tile patterns
-possibly loading maps as brushes, but I think clone might be enough
-possibly creating tilesets out of an imageatlas instead of a
directory of images

If anybody uses this and/or has feedback or suggestions please let me
know! This is my first cocos, pyglet, and kytten project :)

Devon

p.s. Thanks to Richard and Lynx for the cocos tiles and kytten gui
libraries that got me excited to spend way too many late nights
working on this!

[claudio canepa]

From what is seen in the doc page is a neat tool.
But there are some problems, at least in windows.



If running with the included cocos, opened the first dungeon map from the menu and got this:
D:\tmp\cocograph>c:\python26\python.exe run_cocograph.py
dialog_node <cocograph.tile_layers.ToolMenuDialog object at 0x0317BD50>
Traceback (most recent call last):
File "_ctypes/callbacks.c", line 295, in 'calling callback function'
File "D:\tmp\cocograph\pyglet\window\win32\__init__.py", line 849, in _wnd_pro
c
result = event_handler(msg, wParam, lParam)
File "D:\tmp\cocograph\pyglet\window\win32\__init__.py", line 1032, in _event_
lbuttonup
'on_mouse_release', mouse.LEFT, lParam)
File "D:\tmp\cocograph\pyglet\window\win32\__init__.py", line 1021, in _event_
mousebutton
self.dispatch_event(ev, x, y, button, self._get_modifiers())
File "D:\tmp\cocograph\pyglet\window\__init__.py", line 1217, in dispatch_even
t
EventDispatcher.dispatch_event(self, *args)
File "D:\tmp\cocograph\pyglet\event.py", line 340, in dispatch_event
if handler(*args):
File "D:\tmp\cocograph\kytten\dialog.py", line 532, in on_mouse_release
button, modifiers)
File "D:\tmp\cocograph\kytten\dialog.py", line 173, in on_mouse_release
x, y, button, modifiers)
File "D:\tmp\cocograph\pyglet\event.py", line 349, in dispatch_event
getattr(self, event_type)(*args)
File "D:\tmp\cocograph\kytten\menu.py", line 79, in on_mouse_release
self.menu.select(self.text)
File "D:\tmp\cocograph\kytten\menu.py", line 190, in select
self.on_select(text)
File "D:\tmp\cocograph\kytten\file_dialogs.py", line 35, in on_menu_select
self._select_file(self.files_dict[choice])
File "D:\tmp\cocograph\kytten\file_dialogs.py", line 70, in _select_file
self.on_select(filename)
File "D:\tmp\cocograph\cocograph\tile_layers.py", line 468, in on_open_click
self.on_open(filename)
File "D:\tmp\cocograph\cocograph\tile_layers.py", line 709, in open
level_to_edit = tiles.load(edit_level_xml)
File "D:\tmp\cocograph\cocos\tiles.py", line 379, in load
obj = Resource(filename, paths)
File "D:\tmp\cocograph\cocos\tiles.py", line 261, in __init__
self.handle(root)
File "D:\tmp\cocograph\cocos\tiles.py", line 297, in handle
return self.factories[tag.tag](self, tag)
File "D:\tmp\cocograph\cocos\tiles.py", line 276, in resource_factory
self.handle(child)
File "D:\tmp\cocograph\cocos\tiles.py", line 297, in handle
return self.factories[tag.tag](self, tag)
File "D:\tmp\cocograph\cocos\tiles.py", line 280, in requires_factory
resource = load(filename)
File "D:\tmp\cocograph\cocos\tiles.py", line 379, in load
obj = Resource(filename, paths)
File "D:\tmp\cocograph\cocos\tiles.py", line 256, in __init__
tree = ElementTree.parse(filename)
File "c:\python26\lib\xml\etree\ElementTree.py", line 862, in parse
tree.parse(source, parser)
File "c:\python26\lib\xml\etree\ElementTree.py", line 579, in parse
source = open(source, "rb")
IOError: [Errno 2] No such file or directory: 'D:\\Projects\\Python\\cocograph\\
maps\\dungeon\\data/tiles.xml'

Hey, it is a hardcoded path !! Thats a no-no!

--

claxo

[claudio canepa]

On Thu, Aug 27, 2009 at 5:40 AM, devon <devon.sc...@gmail.com> wrote:

[...] 

-I tried using the latest revision of cocos tonight but it gave me a
batchnode error about too many arguments for set_child or something so
I just included cocos 0.3

That is an error in cocos svn trunk, I reported with patch in issue 127 for cocos.

With the patch your app runs (except for the hardcoded paths)

--

claudio

[Devon Scott-Tunkin]

ah sorry about the hard coded path! its in the xml file itself, so
changing the <requires file=> to the relative path maps/dungeons/data/
tiles.xml int the map xml should work. I uploaded a new zip.

This is actually a problem with cocos though, :P as calling
tiles.resource.save_xml gets the absolute path in the
resource.requires list, even if loaded correctly from a relative path
in the xml. save_xml seems to have a few problems, like the property
types. I also had problems getting maps with namespaces to load at
all, so you cant use maps with namespaces in cocograph (or cocos?).
But I didn't investigate namespaces very thoroughly.

I may write a custom save to override the tiles.resource one if
Richard doesn't have an idea for a quick fix.

Devon

On Aug 27, 9:57 am, claudio canepa <ccanep...@gmail.com> wrote:

[claudio canepa]

On 27 ago, 11:57, claudio canepa <ccanep...@gmail.com> wrote:

> On Thu, Aug 27, 2009 at 5:40 AM, devon <devon.scotttun...@gmail.com> wrote:
>
> [...]
>
> > -I tried using the latest revision of cocos tonight but it gave me a
> > batchnode error about too many arguments for set_child or something so
> > I just included cocos 0.3
>
> That is an error in cocos svn trunk, I reported with patch in issue 127 for
> cocos.
> With the patch your app runs (except for the hardcoded paths)
>
> --
> claudio

I was actually wrong with this.
It turns out that cocos.batch has undergone some changes, not totally
compatible with 0.3.0
But changing a few lines in cocograph\dialog_node.py yor code works
well both with cocos 0.3.0 release and cocos svn 864.

The change (sorry for not give a svn diff):

In cocograph.dialog_node.py the class DialogNode now looks as:

class DialogNode(cocos.batch.BatchableNode):
def __init__(self, dialog=None):
super(DialogNode, self).__init__()
self.dialog = dialog

def set_batch(self, batch, group=None, z=0):
super(DialogNode, self).set_batch(batch, group)
if self.dialog is not None:
self.dialog.batch = self.batch
self.dialog.group = self.group

def delete(self, dialog=None):
self.dialog.teardown()
super(DialogNode, self).on_exit()
self.parent.remove(self)

def draw(self):
pass


--
claudio

[Richard Jones]

On 27/08/2009, at 6:40 PM, devon wrote:
> -Saving a map will change all property types to unicode and change any
> requires filenames to absolute paths in the xml. I believe these are
> both issues with the tiles library and reported a bug about the
> property types.

I've just committed a fix to SVN for this. I thought I'd already done
it. Sorry!

I've also committed a fix for the filename mangling from load -> save.
Note that tiles now locates files using pyglet's resource location
mechanism rather than its own.

Richard

[Devon Scott-Tunkin]

Thanks a lot guys! With a few tweaks property and requires work
correctly now.

Two things I notice now:

1) the _as_xml Cell properties still need the fix that RectMapLayer
got, I attached a patch in the files (basically just copy paste the
part from RectMapLayer _as_xml.
http://cocos-discuss.googlegroups.com/web/tiles.patch?gda=PIO-bT0AAAAFeUV7E9TYDtr7KaW9tRK6KhXcgDych9C9BYM6pqSK96xOCajYCl-nUJeX8XcUaYzlNv--OykrTYJH3lVGu2Z5&gsc=w2suLwsAAAAbHZhK1Tlp8BSom1jZYBgi

2) With svn cocos, zooming in and out (scaling the map layer) seems to
have broken the highlight placement, which probably means the
transformation isn't registering for this:
cell = m.get_at_pixel(*self.parent.pixel_from_screen(x, y))
I think this is the problem I noticed before with the trunk tools/
editor.py and svn cocos.

[Richard Jones]

On 28/08/2009, at 12:36 PM, Devon Scott-Tunkin wrote:
> Thanks a lot guys! With a few tweaks property and requires work
> correctly now.
>
> Two things I notice now:
>
> 1) the _as_xml Cell properties still need the fix that RectMapLayer
> got, I attached a patch in the files (basically just copy paste the
> part from RectMapLayer _as_xml.

Whups! Fixed, along with another missed filename mangle :)

> 2) With svn cocos, zooming in and out (scaling the map layer) seems to
> have broken the highlight placement, which probably means the
> transformation isn't registering for this:
> cell = m.get_at_pixel(*self.parent.pixel_from_screen(x, y))
> I think this is the problem I noticed before with the trunk tools/
> editor.py and svn cocos.

Hmm. That requires more debugging. Feel free! :)

Richard

[Devon Scott-Tunkin]

I'll see what I can find out saturday (unless the ludum dare theme is
the height of awesomeness) and then release a bugfix version of
cocograph, with a frankenstein cocos if I have to :).

[Devon Scott-Tunkin]

Okay, I narrowed the scaling bug down in svn tiles to the
ScrollingManager.

specifically this line was removed from both set_view and force_view:
self.view_w, self.view_h = w, h

interestingly though if I re add those lines, that only corrects
zooming out, but zooming in is still screwed up, possibly for a
different reason...
I can't for the life of me see why this is since the logic is
basically the same, but regressing the whole ScrollingManager back to
version 0.3 of the scrolling manager fixes all scaling issues.

Also I highly suggest going back to the 0.3 scrolling manager with
self.viewport because even if the scaling does get fixed, resizing the
director.window when do_not_scale=True will still break
RectMapLayer.get_at_pixel (and does when I drag the window bigger in
cocograph) because the viewport changes but the ScrollingManager has
no way to know this has happened since view_w, and view_h are only in
reference to the original window size. 0.3 ScrollingManager works fine
(once I refresh the window by doing something in cocograph of course)

I hope that made sense :)

Devon

[Devon Scott-Tunkin]

Bugfix release that should fix most issues. No more filename mangling
on map and tileset saves, but make sure tilesets are in the same
directory as the map (easiest) OR that the directories are in the
pyglet.resource.path.

http://devdev-python.googlecode.com/files/cocograph0.1.1.zip
(I changed my mind about the versioning pattern)

On Aug 27, 3:40 am, devon <devon.scotttun...@gmail.com> wrote:
> This is still very alpha, but I wanted to get a release out for pyweek
> for people to use if they're interested. Cocograph is a tile map
> editor for cocos2d that using kytten for the gui. Cocograph includes
> pencil, eraser, zoom, and move tools and can create new maps and
> tilesets without writing any xml. Ctrl clicking on a tile or cell will
> allow you to edit, add or delete the properties and these changes will
> be saved back to the orginal tileset when you okay them for tiles and
> will not be saved until you save the map for cells.
>
> download includes cocos 0.3, and kytten5, also a version with pyglet
> so you don't need to install anything else. map examples from cocos
> and threads of fate are included (and include your license,

> Richard :) )http://code.google.com/p/devdev-python/downloads/list

[Devon Scott-Tunkin]

oh, and it now uses svn cocos with a slightly modified tiles.py

On Aug 27, 3:40 am, devon <devon.scotttun...@gmail.com> wrote:

> This is still very alpha, but I wanted to get a release out for pyweek
> for people to use if they're interested. Cocograph is a tile map
> editor for cocos2d that using kytten for the gui. Cocograph includes
> pencil, eraser, zoom, and move tools and can create new maps and
> tilesets without writing any xml. Ctrl clicking on a tile or cell will
> allow you to edit, add or delete the properties and these changes will
> be saved back to the orginal tileset when you okay them for tiles and
> will not be saved until you save the map for cells.
>
> download includes cocos 0.3, and kytten5, also a version with pyglet
> so you don't need to install anything else. map examples from cocos
> and threads of fate are included (and include your license,

> Richard :) )http://code.google.com/p/devdev-python/downloads/list

[Devon Scott-Tunkin]

argh, looks like there was still a bug for new maps in that map height
and width were reversed (note to self: never test only square maps).

http://devdev-python.googlecode.com/files/cocograph0.1.2.zip

On Aug 30, 11:53 am, Devon Scott-Tunkin <devon.scotttun...@gmail.com>
wrote:

[Devon Scott-Tunkin]

Well I see now why you changed the scrolling manager, if the window is
set to scaled the 0.3 scrolling manager will adjust for the size of
the window but the scale will be messed up because of keeping the
aspect ratio the window size is not neccesarily the same ratio to the
scale it was when the window was created, which messes up the focus. I
made a quick hack for pyweek in my game for the 0.3 scrolling manager
to check if the director is using the scaled or non scaled for
window.on_resize, but since the director doesn't really keep a
variable telling you which it is using I had to compare functions for
equality...not a great idea:

in set_focus:
if cocos.director.director.window.on_resize is
cocos.director.director.unscaled_resize_window:
w = int(self.viewport.width / self.scale)
h = int(self.viewport.height / self.scale)
else:
w, h = cocos.director.director.get_window_size()

so, something to think about. It would be good if the scrolling
manager worked correctly for scaled and unscaled resizes, but I don't
know what the best solution would be. Both 0.3 and SVN scrolling
manager have issues with resizing the window.

On Aug 29, 6:10 pm, Devon Scott-Tunkin <devon.scotttun...@gmail.com>
wrote:

> >      Richard- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -