Curious about increasing Tile Collision Size? (now with footage)

[Obercooked]

Most likely NOT going to do anything with this if there somehow is a solution, but curious about this
Backstory is, I was starting with orbinaut the other day, i wanna work on this engine cuz i like sonic like physics/collisions more than baisic mario like physics/collisions. Moving some sprites and stuff to Orbinaut, i realized i was moving from 32 X 32 sprites to 16 X 16, meaning that id have to decrease sprite sizes. I thought to try to increase the tile collision size from 16 to 32 to try to be able to still work with the original sprite size i used, and came out with no luck, i both simply increased the size of the base collision tiles, and added new collision tiles to weird effects and angles not seeming to correspond to the right tiles. They seemed to be properly connected to the 32 by 32 grid, but completely disconnected from the correct tiles. While this was more than likely caused since i have little knowledge about how these collisions worked, i am curious, has anybody been able to or TRIED to increase the tile collision sizes to higher values and gotten it to work? I do know it says in the manual that that isnt recommended, so I'm again more curious than anything rather than looking for a proper solution. (cuz tbh, trying to make sprites in a smaller size could potentially be easier, or possibly a neat way for me to practice a new artstyle)

[TrianglyRU]

Are you by any chance using the default binary collision data? If so, you'll need to regenerate it or use real-time collision (i.e., regular collision_load, not collision_load_binary), because all binary collision data uses height and width arrays based on 16px tiles

[Obercooked]

I did try it again, and recorded footage, and the tiles here seem to work in an odd way

8mb.video-FxD-yxfKb8Uk.mp4

Now i am still not at all understanding how this works, but what im seeing happen is:
Every other row seems to work with collision (first, and third, but not second, or fourth)
the first row of tiles seem to work flawlessly, and im not sure what the third row is doing
Each wall in the video represents testing the next row of collisions, which you can see here

Im not sure what its doing, but from what i see, coincidentally at base each row here has 16 tiles, and of course each tile is 16 by 16. is orbinaut using ENGINE_TILE_SIZE to both, count the width/height of the tiles, AND the ammount of tiles in each row during generation(or otherwise for this to happen)??
I cant tell what the tiles are doing in row 3 to prove that or not. I would say that they have the collision of row 2, but the angles of row 3, but i simply cant tell and dont see how that would work codewise?
and note: that i copied the test zone collisions, these should ideally correspond and work exactly the same as the original tiles, just bigger, id assume
upon inspection and more testing, this seems to be it??
It takes the angles of what should be the third row and the collision of the tiles from the second row, how would this be fixed?

[TrianglyRU]

Yeah I see what's the problem now. So, in short:

function collision_generate(_sprite_id, _angle_data, _off_x = 0, _off_y = 0, _sep_x = 0, _sep_y = 0, _row_limit = ENGINE_TILE_SIZE)

As you can see, the function defaults _row_limit to ENGINE_TILE_SIZE, so it expects to have exactly 16 tiles in each row by default. Since your ENGINE_TILE_SIZE is 32, it expects 32 tiles in each row. Simply override _row_limit with 16 and see if your issue is fixed

[TrianglyRU]

I've pushed a change to the function to make its usage more straightforward (762767f)

[TrianglyRU]

Any updates on the topic? @Obercooked

[Otukuoi]

I'm never using this, but this looks really cool so far