Any fix for the Tilemap seams ?

Ashley another HTML5 framework called Phaser offers Tilemaps, there an example when use fullscreen and it doesn't show any seams to me.

http://gametest.mobi/mariocombo/

Is there something wrong with your tilemap technology?

Joannesalfa - that example doesn't look like it uses floating point scaling like C2 does with letterbox scale. The seams are a natural consequence of the way rendering works when you use floating point positioning or scaling.

Ashley Why don't you make a special setting for this tilemap as this example? I've seen like more than 20 threads about tilemap seam. Nobody likes to use letterbox integer scale.

(Singing)

Ashley PLEASE FIX THE TILE MAP SEAMS!(figure out a way..figure out a way..figure out a wayyyyy..)

Ashley PLEASE FIX THE TILE MAP SEAMS!(figure out a way..figure out a way..figure out a wayyyyy..)

Ashley PLEASE FIX THE TILE MAP SEAMS!(figure out a way..figure out a way..figure out a wayyyyy..)

(All together now!)

FIX THE TILE MAP SEAMS!

FIX THE TILE MAP SEAMS!

FIX THE TILE MAP SEAMS!

Since there is no solution for TileMaps seams at the moment (except the one with Integer Letterbox Scaling) I see only 2 viable options (the old ones):

Method 1

Use 9-Patchs, TiledBackgrounds and Sprites to build the Room/Level

Method 2

1. Create your TileMap in another program (example: Tiled)

2. Get an image with the whole level

3. Split that image in smaller images

4. Create 1 Sprite that will have these images as frames

5. Create your Room/Level in C2 on 1 Layout using multiple instances of the sprite with different frames

6. Create another Layer (invisible) that will contain collision Sprites

7. ...

8. Profit

Both methods have advantages and disadvantages compared to a TileMap, but it should get the job done

tgeorgemihai : method one is what we were using before the tilemap, method two is not a great idea memory wise, unless I did not understood it well

https://dl.dropboxusercontent.com/u/583 ... index.html

Desired effect?

arrows move, mousewheel zooms.

and there is some touch support. touch feet to drop. two touches jump.

144fps pc

60fps mobile(note this is a device limitation not performance hit)

4 sprites

31 objects

with room for improvement.

and many many ways it could be optimized further.

Pros:

Scales without seams.

Very few sprites.

Meets in-between of tiling background performance and tiling sprites performance. (but at max fps on all my machines I cant honestly verify this simply theory crafting)

Cons:

Large background image. (this could easily be broken up into smaller images)

Multistage level design(you tile everything and build your level and then have to again set solids etc etc)

Performance(both a con and pro depending how you look at it)

And a picture

https://dl.dropboxusercontent.com/u/583 ... apture.JPG

As for memory management. Not all objects need loaded at the same time. store object data in arrays and create those objects as needed and destroy them as needed. Think of this like minecraft "chunks" You only need to load so many "chunks" at a time.

That means a 3000 object project might only have loaded 300 objects at any given time. Just food for thought.

An amazing feature construct should do instead of tiled backgrounds or sprites etc. Is procedurally/dynamically/viewpoint loaded objects. When the viewport is near where objects should be, load them and create them. Otherwise, they dont need to be loaded or known about until later.

[quote:4nl0ykj4]As for memory management. Not all objects need loaded at the same time. store object data in arrays and create those objects as needed and destroy them as needed. Think of this like minecraft "chunks" You only need to load so many "chunks" at a time.

Texture wise, they are still in memory, so it can be a pain.

[quote:4nl0ykj4]An amazing feature construct should do instead of tiled backgrounds or sprites etc. Is procedurally/dynamically/viewpoint loaded objects. When the viewport is near where objects should be, load them and create them. Otherwise, they dont need to be loaded or known about until later.

This looks like more something the user should have to do himself, that could break so many projects otherwise

Aphrodite

Ok, then I will use Method 1

Also thanks for your help here, but i found this nice [Behavior] LiteTween that I will use.

[quote:1az9rqt2]As for memory management. Not all objects need loaded at the same time. store object data in arrays and create those objects as needed and destroy them as needed. Think of this like minecraft "chunks" You only need to load so many "chunks" at a time.

Texture wise, they are still in memory, so it can be a pain.

[quote:1az9rqt2]An amazing feature construct should do instead of tiled backgrounds or sprites etc. Is procedurally/dynamically/viewpoint loaded objects. When the viewport is near where objects should be, load them and create them. Otherwise, they dont need to be loaded or known about until later.

This looks like more something the user should have to do himself, that could break so many projects otherwise

I imagine that last part for object creation to be a behavior. This way objects that need to always exist can. But others could add the behavior which would help with performance a good deal in projects I would think.

As for the memory. Dont the same sprites share the same texture? Or does every object have its own texture. I am not very familiar with how that works.

Regardless though, GPU and CPU would not have to work as hard if this was implemented. Consequently increasing performance. As well as freeing up ram etc because object information isnt needed or being used.

I would strongly recommend you do not use large images as backgrounds. This is a great way to get out of memory errors.

Another workaround: since ordinary 'letterbox scale' introduces floating point scaling which can seam, try using 'low quality' fullscreen mode. Then you should be able to use letterbox scale without that causing seaming, but you may still need pixel rounding.