Tile Map Viewport + Active objects as collision tiles: Destroy and create again?

[Zebedy]

Hey all,

Wondering if someone can help me out with my issue regarding loading and destroying (but then loading again) collision tiles.

-So, my levels are quite large. Maybe 10,000 x 5000.
-Tiles are being loaded in from Tiled, no problem.
-I have a separate set of invisible collision tiles (active objects) that are created on top of the relevant graphic tiles.

Is there a way to destroy these active objects when they're off-screen? And have them recreated when on screen?

As it stands, it loads all the collision tiles for the entire level at once, and it's definitely causing fps issues.

Initially, I was just loading in an extra layer from Tiled as a collision layer, but the collisions get very weird if you're using lots of slopes and curves
(ala sonic the hedgehog)

[Volnaiskra]

In general, lots of tiny objects tends to be worse for performance than fewer medium-sized objects. So consolidate your objects into larger ones where possible.

Is your problem a long slowdown at the start, when everything is being loaded in? Or continual lagginess as you play the game? If it's the latter, then there's a good chance that the slowdown is caused not by the objects themselves, but by Fusion constantly checking for collision checks with them, as collision checks are relatively expensive.

Creating objects is relatively expensive too (not hugely, but creating many objects at once may produce a detectable FPS stutter), so rather than destroying/creating collision objects all the time, try turning the collision code on/off selectively instead. For example, if you have an event that checks for [player] is overlapping [collisionTile], try adding a condition above the overlap condition that will limit how often the overlap condition is triggered. For example, Is ODistance( "player", x("collisionTile"), y("collisionTile")) < 500 would cause the event to ignore overlap checks for any collision tiles further than 500px from the player. You may find that if you disable the collision checks stringently enough, then having all those collision objects floating around doing nothing most of the time won't cause any slowdown.

BTW, The ODistance function is accessed via Active Object>Position:

[Zebedy]

Hey Volnaiskra,

That's definitely something I should try then!

I have events activating/deactivating depending on the player's distance for nearly everything, except for these collision tiles 😂. I'll try ODistance.

The fps issue is a continuous lagginess, it sort of sits around 55-60, with certain areas definitely dropping into the 40's for a second.

Also, my tiles are currently 64x64. Do you reckon that will do?
I did have 128x128, but that seemed to cause slowdown on some devices, although it runs fine on the PC.

[Zebedy]

Double post, coming back with results:

- First of all, you're a magician. That was it. It's 60fps 100% of the time now.

-New problem though : the player doesn't collide with tiles anymore - but if I scroll across the level now, the fps is rock solid.

obstacles.png

[Volnaiskra]

Hmm. I think that's a scoping issue. I probably didn't think it through properly when I made the suggestion. Fusion usually scopes on the left of conditions, so probably the collision tile(s) that are identified in the first condition (ODistance...) are not necessarily the same ones that are identified in the second condition (is overlapping...). Try it this way around:





If that doesn't work, then you might need to use a For Each loop, like this:






I think that should work. The idea is that if the player is within 500px of 6 different collision tiles, then the [ODistance...] condition will find and scope those 6 tiles. It will then run a For Each loop 6 times, for each instance of those 6 collision tiles, and one by one will test each of those 6 collision tiles to see if it overlaps with the player.

[Zebedy]

Honestly I thought that would have done it

Tried both suggestions, but the collision still seems to behave in the same weird way.

[Zebedy]

Alright so, hands are tied. I think I'll have to call for collision tiles during runtime.

I've been using this tidy example made by @Kisguri
https://community.clickteam.com/threads/103479-On-Call-Tile-Map-Engine
(is there a way to tag/mention people, by the way )? Would love his two cents on this.

I've done the math and from the looks of it, it *should* work now for a screen size of 1920x1080, using tiles that are 64x64.

It calls tiles perfectly from all sides, *except* if the player is moving up or down - a small section to the player's right never loads in the tiles.
So, naturally, I tried playing around with the borders, extending them so there's more tiles being drawn on screen, etc.
But then some tiles don't load within the visible screen, while still loading in tiles at the border.

I've been trying to figure out what's causing it for 7-8 hours now

Kisguri, if you get a minute, do you mind if I send you my edited versions of the editor and streaming files?

[MistaSub]

Hey all,

Wondering if someone can help me out with my issue regarding loading and destroying (but then loading again) collision tiles.

I mean I suppose you already tried this, but there is a built in function to have object as "inactive" when far from window. I actually used this in previous version of my game, but it caused problems. I had thousands of river objects and while it did save a lot of frames, it desynced the animations naturally.
The thing is it's all fine if the gameplay is supposed to happen only around the player. For example if only the player needs to collide with these hitboxes, it would probably work fine.
But if it means platformer enemies will fall through them when you are far away, you will have to implement a system where you deactivate the enemies as well when the player is far from the hitboxes.
I don't know what kind of game you are making, but if this is an option I would think deactivating the enemies code would be safer, if possible. Then you could control at what distance this happens, and maybe you could avoid doing it to all the hitboxes and simply use the built in function. Does anyone by any chance know what this range of "far" is for the built in "deactivate if far from window" property?

I don't know, just a thought. I mean most likely the hitboxes aren't really doing much so unless you are hitting object limits, they shouldn't be too much of a problem.

**EDIT**
If it helps at all, I solved the river animation problem by syncing the animation to a single master object, which calculated the frame shifts, thus enabling me to have "inactive if too far on". Or maybe I made my own inactivation, I don't remember and I scrapped that project in favor of my new one which I can actually finish.

[Zebedy]

I mean I suppose you already tried this, but there is a built in function to have object as "inactive" when far from window. I actually used this in previous version of my game, but it caused problems. I had thousands of river objects and while it did save a lot of frames, it desynced the animations naturally.
The thing is it's all fine if the gameplay is supposed to happen only around the player. For example if only the player needs to collide with these hitboxes, it would probably work fine.
But if it means platformer enemies will fall through them when you are far away, you will have to implement a system where you deactivate the enemies as well when the player is far from the hitboxes.
I don't know what kind of game you are making, but if this is an option I would think deactivating the enemies code would be safer, if possible. Then you could control at what distance this happens, and maybe you could avoid doing it to all the hitboxes and simply use the built in function. Does anyone by any chance know what this range of "far" is for the built in "deactivate if far from window" property?

I don't know, just a thought. I mean most likely the hitboxes aren't really doing much so unless you are hitting object limits, they shouldn't be too much of a problem.

**EDIT**
If it helps at all, I solved the river animation problem by syncing the animation to a single master object, which calculated the frame shifts, thus enabling me to have "inactive if too far on". Or maybe I made my own inactivation, I don't remember and I scrapped that project in favour of my new one which I can actually finish.

Sorry, been away on holiday.

Yeah, unfortunately, using the built-in "inactive" when far from window still doesn't help things enough.

For code that deactivates - I've done it for all the enemies, objects you can interact with, technically anything I can turn off while it's off-screen, without messing the game up.

It's the tiles I'm using as active objects specifically that cause slow-down. Normally, you can just call in a collision layer from Tiled and it deloads/loads as you scroll across the screen. But the player collisions are a mess when I do that. So I need to use active objects for more accurate collision detection.

[Zebedy]

So, I genuinely cant find a fix. It seems like it should be so easy.

And as it turns out, most game development software these days cull tiles by default anyway.
5 years, and I think Im going to have to move my efforts on to something else. I swear Fusion always has problems that just shouldn't exist in 2023. I also don't understand why a dev would refuse customer support for an asset he's sold on the store.

Anyway, Unity was my first choice. But Im sure you've all seen how upper management at unity has gone mad.

Ill be moving over to GameMaker for this project; and I think possibly Godot for the project after that; once it matures a bit.