Any fix for the Tilemap seams ?

Discussion and feedback on Construct 2

Post » Mon Apr 28, 2014 10:06 pm

@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?
B
97
S
35
G
29
Posts: 3,139
Reputation: 28,361

Post » Mon Apr 28, 2014 10:59 pm

@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.
Scirra Founder
B
387
S
230
G
87
Posts: 24,249
Reputation: 192,240

Post » Mon Apr 28, 2014 11:15 pm

@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.
B
97
S
35
G
29
Posts: 3,139
Reputation: 28,361

Post » Thu May 01, 2014 6:53 pm

(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!
B
15
S
6
G
4
Posts: 277
Reputation: 3,948

Post » Fri May 02, 2014 8:41 pm

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 :mrgreen:

Both methods have advantages and disadvantages compared to a TileMap, but it should get the job done ;)
B
49
S
15
G
6
Posts: 531
Reputation: 7,189

Post » Fri May 02, 2014 9:40 pm

@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
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
52
S
22
G
18
Posts: 2,122
Reputation: 17,093

Post » Sat May 03, 2014 5:31 am

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.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

Post » Sat May 03, 2014 1:36 pm

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.

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
Game design is all about decomposing the core of your game so it becomes simple instructions.
B
52
S
22
G
18
Posts: 2,122
Reputation: 17,093

Post » Sat May 03, 2014 10:14 pm

@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.
B
49
S
15
G
6
Posts: 531
Reputation: 7,189

Post » Sat May 03, 2014 11:56 pm

Aphrodite wrote:
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.

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.
B
28
S
8
G
1
Posts: 226
Reputation: 2,865

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 7 guests