Culling offscreen sprites (for tile map)

[Aaron]

I'm trying to draw an RPG tile map. So far I've been able to draw the
whole map by creating a sprite for every tile, all associated with a
batch. The images for the sprites come from an ImageGrid for the map's
spritesheet. The map is created with Tiled (http://www.mapeditor.org/)
you see.

Now I'm thinking about tile culling, since I'll only ever draw a
subset of the map. Positioning the map can be done with a
transformation (available only through the OpenGL interface I assume)
so all that's left to determine is which tiles are visible.

Having to repeatedly cull tile sprites before drawing means I can't
use a single batch created at the start anymore. The solutions I've
heard of are recreating the sprites and batches every time I need to
draw, leaving out the hidden tiles, or ignoring sprites and batches
and just blitting the images for each tile manually. I've also heard
people talk about using textured quads with raw OpenGL instead of
Pyglet's higher level objects and functions, but I have yet to wrap my
head around that.

I suppose it's worth asking if Pyglet has or is going to have any
general abilities to do off-screen culling?

[Richard Jones]

On Sat, Jan 15, 2011 at 12:47 PM, Aaron <vide...@gmail.com> wrote:
> I suppose it's worth asking if Pyglet has or is going to have any
> general abilities to do off-screen culling?

It's not something that pyglet should implement, as it's more of an
engine thing. cocos2d, built on top of pyglet, has a tiled map system
with culling (and scrolling and zooming and picking) built in. It also
has a bunch of other stuff that might be useful.

Richard

[Aaron]

On Jan 15, 3:59 am, Richard Jones <r1chardj0...@gmail.com> wrote:
> It's not something that pyglet should implement, as it's more of an
> engine thing.

So I take it pyglet is meant to be an OpenGL wrapper with event
management more than anything else then.

Are you sure cocos2d uses the same format that Tiled exports? I'm
using the latest (QT-based) release of Tiled, and its .tmx format
(http://sourceforge.net/apps/mediawiki/tiled/index.php?
title=Examining_the_map_format) doesn't match the format described in
cocos2d's API documentation (http://cocos2d.org/doc/api/cocos.tiles-
module.html).

Also, cocos2d's documentation for tile maps is poor. The API document
is the only documentation that describes cocos2d's tile map support at
all. The pages in its programming guide on tile maps are stubs.

[Richard Jones]

On Sun, Jan 16, 2011 at 2:48 AM, Aaron <vide...@gmail.com> wrote:
> On Jan 15, 3:59 am, Richard Jones <r1chardj0...@gmail.com> wrote:
>> It's not something that pyglet should implement, as it's more of an
>> engine thing.
>
> So I take it pyglet is meant to be an OpenGL wrapper with event
> management more than anything else then.
>
> Are you sure cocos2d uses the same format that Tiled exports?

No, and I never asserted it did: "tiled" vs. "Tiled" ... I can see why
I caused confusion :-)

> Also, cocos2d's documentation for tile maps is poor. The API document
> is the only documentation that describes cocos2d's tile map support at
> all. The pages in its programming guide on tile maps are stubs.

Yep, could definitely use improvement. There's some examples using it
in the codebase and out in the wild, and there's a couple of editors
too (one in the codebase, one more feature-full elsewhere).

Richard

[Aaron]

I suppose I could create a Tiled (capital 't') loader for cocos2d
manually if I could just figure out how cocos2d's map features work.

As for tile sprite culling, I've heard cocos2d also uses regular
Sprites and Batches for its tiles, implying it just recreates the
batch whenever a map needs to scroll. Is this true?

[DR0ID]

Hi

Some time ago I wrote a loader for *.tmx files, maybe it is useful:

https://code.google.com/p/pytmxloader/

The included pyglet demo runs very slow (I guess due the huge number of
groups, each line it one), but I don't know how to implement it faster
and getting a correct rendering (the draw order of the tiles and layers
is important). Maybe some one could help out to write a better demo.

~DR0ID

[Richard Jones]

On Mon, Jan 17, 2011 at 2:41 AM, Aaron <vide...@gmail.com> wrote:
> As for tile sprite culling, I've heard cocos2d also uses regular
> Sprites and Batches for its tiles, implying it just recreates the
> batch whenever a map needs to scroll. Is this true?

Whenever the visible set changes, yes.

Richard

[devon]

There's a tmx loader for cocos2d here https://bitbucket.org/maikg/tiled2cocos/src/

also my tile map editor for the python cocos2d map format
http://code.google.com/p/devdev-python/wiki/Cocograph

Devon

[Aaron]

On Jan 16, 4:55 pm, Richard Jones <r1chardj0...@gmail.com> wrote:

> On Mon, Jan 17, 2011 at 2:41 AM, Aaron <videro...@gmail.com> wrote:
> > As for tile sprite culling, I've heard cocos2d also uses regular
> > Sprites and Batches for its tiles, implying it just recreates the
> > batch whenever a map needs to scroll. Is this true?
>
> Whenever the visible set changes, yes.

Well, I guess if it's good enough for cocos2d, it's good enough for
me.

I assume that, since it recreates the Batch, it's discarding the
Sprites for tiles no longer visible and creating new Sprites for the
tiles that became visible. For Sprites that are still on the screen,
would it be faster to change their Batch or just to create new ones?

[Richard Jones]

On Tue, Jan 18, 2011 at 9:42 AM, Aaron <vide...@gmail.com> wrote:
> I assume that, since it recreates the Batch, it's discarding the
> Sprites for tiles no longer visible and creating new Sprites for the
> tiles that became visible. For Sprites that are still on the screen,
> would it be faster to change their Batch or just to create new ones?

It retains sprites that are still on-screen. The batch is the same throughout.

Richard

[Aaron]

On Jan 17, 6:46 pm, Richard Jones <r1chardj0...@gmail.com> wrote:

> On Tue, Jan 18, 2011 at 9:42 AM, Aaron <videro...@gmail.com> wrote:
> > I assume that, since it recreates the Batch, it's discarding the
> > Sprites for tiles no longer visible and creating new Sprites for the
> > tiles that became visible. For Sprites that are still on the screen,
> > would it be faster to change their Batch or just to create new ones?
>
> It retains sprites that are still on-screen. The batch is the same throughout.

So it's only the Sprites that get created, discarded, and retained
based on their visibility then, while the same Batch is used
throughout.

I think I can work with that. :)

[Aaron]

I've found that, instead of deleting and recreating Sprites as their
visibility changes, I can just set their "visible" property. That
means I can create the sprites for all map tiles once and just change
their visibility property as the view rectangle changes.