C3 Tilemap, visual bug?

0 favourites
  • 12 posts
From the Asset Store
This music pack covers differents situations for visual novels, anime games and many more!
  • I am getting an unexpected effect when I try to use the tilemap. I have a tilemap file, with 32x2 tiles. When I start the layout, the system creates several copies of the tilemap, with a loop, I fill only one line of various tiles. Each tilemap created has its own value in order Z with the intention of creating a depth effect, false 3D. However, this generated a visual problem, a conflict with a sprite object that is printed on the tilemap.

    Download .c3p drive.google.com/file/d/1EtJjkbw-aeCSVKJuH0pefVmCZxw6srB9/view

    if it's not a bug, I'm sorry. I really don't understand why this is happening.


  • I think it's a bug, but a really cool one! :)

  • yes, very interesting. So I created the topic, if it wasn't a bug I would love to know how to take advantage of this effect.

  • Not a bug. You are just telling it to do weird things and it is doing it for you :) You have created some art with Construct.

  • PS I meant to ask - do you have a picture of the effect you were trying to create?

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads
  • I must have been dreaming about this - because I woke up and realized what you mean by the 'bug', i.e. the sprite being displayed in the tilemap. Let me try to explain what's happening. To improve performance - specifically batching to reduce draw calls - sprites, tilemap images etc. are combined into a spritesheet. Let's take a look at your project's spritesheet:

    There you see your tilemap image and sprite together in the spritesheet. Your tilemap image has 64 individual tiles, with tile number 0 at the top through to tile number 63 at the bottom.

    In the action Tilemap -> Set tile, the parameter 'Tile' is expecting a tile number, i.e. something between 0 and 62. But you are not giving it a tile number, you are giving it the Tilemap instance ID (self.IID). Each time you create your Tilemap object, it is creating an 'instance' of that object, and it is given an instance ID, the first Tilemap IID = 0, the second Tilemap IID = 1, the third Tilemap IID =3 and so on.

    At the start of your layout you are creating 128 Tilemap instances, so Tilemap IID will range from 0 to 127. So what happens when you reach tile IID = 64 and use this as the Tile (number) parameter in the 'Set tile' action? There is no tile number 64 in your tilemap image, but Construct doesn't seem to check that, and keeps pulling data from the spritesheet, assuming there is another tile there. Eventually your Tilemap IID and hence Tile parameter is so that large that it reaches the Sprite image in your spritesheet, and starts putting that data into your Tilemap.

    For those who are really interested and want to keep reading - would I call this a bug? Probably not. I would call it an 'unintended use case'. What's the difference? A bug is when your code is correct but the result is wrong. An unintended use case is when your code is wrong, but the engine still lets you do it anyway, and gives a strange result.

    I have reproduced it in a minimal project and will report it anyway just so they are aware. It will be up to the Construct team if they decide to 'fix' it.

    Because I think this might be interesting topic for some people - why might they decide NOT to fix an unintended use case?

    Assuming my theory is correct, the problem could probably be fixed by 'bounds checking' the Tile parameter in the Set tile action. It would do something like:

    if tile number > max tile number { tile number = max tile number}

    This would stop it from moving out of the tilemap image into the rest of the spritesheet. They might decide to do a fix like this to stop people from making the same mistake.

    But why might they NOT do a fix like this? Because it might have a negative performance impact on people who are using the Set tile action correctly. The bounds check adds an additional calculation that has to be done every time Set tile is used. For people who are for example, doing procedural generation on a tilemap, or using a chunk system to stream data into a tilemap for a large open world game, this could reduce their performance.

  • simstratic Awesome analysis! How do you know so much about the inner workings of Construct?

  • Oh sorry I don't want to give that impression, I don't know anything about the inner workings other than what is out there in the manual and Ashley's blogs, but part of it is just based on observation combined with experience with other engines, I guess you start to learn how to identify how things are probably implemented on the engine side. But I should make it clear, what I wrote above is just an educated guess, that why I'm still submitting it as an issue.

  • PS I meant to ask - do you have a picture of the effect you were trying to create?

    I expected to create a prospective terrain similar to the "top gear" (snes) game.


    My idea was to reconstruct the tilemap using the dimensions 32x2. Every 2 pixels at a different depth in the Z elation.

    When creating 128 tilemap objects, I thought I could use each "IID" to reference the correct 32x2 tile in ascending order.

  • Sorry my other reply was probably long and confusing.

    You could use the IID as the number for the Tile parameter. The problem is you have too many Tilemaps (128) compared to how many tiles are in your image (64). So you can reduce the number of Tilemaps to 64 and it should work.

    If you need 128 Tilemap objects, then you can scale the IID (divide by 2), so IID will fit the same range of how many tiles you have. See below for what I mean (note: I made some other changes to make it more optimized):

  • thanks for the help, now i understood my mistake

  • Sorry event sheet was supposed to be attached:

Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)