A lot of things can make game to crash. Infinite loops, for example.
But, you said your project is big and Clickteam also crashes. So I suppose you are out memory. Probably you are using very big sprites with tons of animations.
FNaF game? Try to deactivate parts of code and find that crasher condition. Or maybe uncheck "Create on start" for every object you don't need on start. Create objects only when you need them and destroy objects when you don't need them.
Hello, and thanks for replying.
The crash only happens when I try to run the application, after turning certain events that already exist in the project, into parent/child events from what they were previously. It's very specific that the crash follows doing this particular thing, and doesn't happen at all otherwise.
Maybe a screenshot of what I'm trying to say will help...
Please login to see this attachment.
This is an example of what I'm trying to do. This block of code has been arranged in a parent/child structure, and crashes Fusion in the way I described when I try to run the application.
Please login to see this attachment.
This is the same block of code in it's original form. This does not cause a crash at all.
In addition, there are similar structures in my project that I've tried to retroactively turn into parent/child events, in the same way that i have in the first screenshot, which does not cause a crash, and works as expected. There seems to be no obvious reasons why some parent/child events crash, and not others.
I thought it might possibly be a memory issue, indeed, the way it crashes made me think this at first, but even though the available memory on my dev laptop is very low, there's still about 20 GBs free, which should be more than enough, & the applications RAM usage when running is relatively low (97mb, 191 objects). If anything, by using sub-events I'd be reducing the memory usage, because the whole reason for using them was to try and reduce the condition count on very computationally heavy areas of code which are frequently run. In order to turn the original events into sub-events means I have to delete conditions, like the "on loop" ones.
Ths project doesn't use any large objects or objects with many animation frames. In fact the entire thing runs in a single frame and most active objects are either invisible value containers, or small UI buttons. It's otherwise very stable and rarely ever crashes.
It's definitely not a FNAF game
it's essentially a fantasy console/Chip 8 emulator, although I've added features to the chip 8 side of things that weren't in the original spec, such as programmable horizontal and vertical blanking periods, a scanline interrupt, a 16 colour mode, a tilemap with an attribute table, & up to 16 8x8 "hardware" sprites on screen at once. The code block in the screenshot actually shows a segment of how the colours are being fetched from memory ("memory" is just a big 2D array), via alterable values, for each 8 pixel row of a sprite. It uses a loop which, for a minimum of 8 sprites, runs 512 times per frame (64 times per sprite), so i had identified this area as one that could potentially benefit from being optimised with sub-events.