SMBX Limits Are "Dynamic"

[Emral]

I found this one out during recent testing when, in a large test level spanning over 16000 blocks, 80 events and 6500 bgos, the game started crashing on me during testing. Despite no defined limit being reached, I kept getting overflow errors (RTE 6).
After finding out how to reliably create this error message, I wanted to get to the source of this behaviour, and my results are really not that mindblowing and probably not even that interesting, but I feel like they're worth pointing out to you:

Even when not hitting any debugger limit, testing can make the SMBX CPU usage jump above its limit, causing a runtime error.

My theory is that blocks "weigh" more than background objects, as replacing 300 blocks with 300 background objects fixed this and stabilised the program.

Things that don't cause any destabilisation which I tried:
Lots of custom graphics. These only increase loading time.
Too much stuff going on on screen or too many permanent events. These only cause lag.

I previously said that this error can be consistently recreated. That's due to the fact that it always occurs at the same spots in a level. I found multiple spots where this happened during testing. So if you find yourself running into Runtime Error 6 over and over above the same water pit, try equalizing the debugger items a bit (as in, move the one close to its limit away from it).

Adding a massive graphic file will cause an overflow error on load.

Nothing mindblowing, as I said, but still interesting, in my opinion.

[SilverDeoxys563]

Would one 128x128 block weigh more than sixteen 32x32 blocks? Both have the same area, and I tend to use the big one.

[Emral]

Would one 128x128 block weigh more than sixteen 32x32 blocks? Both have the same area, and I tend to use the big one.

I have upped the block count to 16381 to get the overflow at one of my favourite over flow spots. After getting the error I replaced blocks with 128x128 blocks, 30 to be exact, bringing the block count down to 15965 (around how much I had after the initial test).

Just as with replacing blocks with bgos, replacing them with larger blocks stabilised the level. Block size does therefore not (or at least barely noticeable) influence the block's weight.

[Kevsoft]

Simple answer to this error: Every index for every item-array has a maximum size of 2 bytes (2^16).
That's what you get when developing a game in an old language.

[Emral]

Simple answer to this error: Every index for every item-array has a maximum size of 2 bytes (2^16).
That's what you get when developing a game in an old language.

Why would background objects have a smaller maximum item-array size? If I didn't misunderstand what you said, they have to, since evidentially don't take up as much space as blocks.

[Kevsoft]

No idea... but in the programmical way this is only the one possible and logic answer.

[Imaynotbehere4long]

Things that don't cause any destabilisation which I tried:
Lots or large custom graphics. These only increase loading time.

You just didn't make the graphic large enough (or used enough large graphics). Just the other day, I tried to use a 512x422 NPC sprite swap with 94 visible frames (that's 512x42112 total, for a cut-scene), and SMBX overflowed, even when I tried to open the level without testing. Removing the graphic stopped the crashes.

[Emral]

Things that don't cause any destabilisation which I tried:
Lots or large custom graphics. These only increase loading time.

You just didn't make the graphic large enough (or used enough large graphics). Just the other day, I tried to use a 512x422 NPC sprite swap with 94 visible frames (that's 512x42112 total, for a cut-scene), and SMBX overflowed, even when I tried to open the level without testing. Removing the graphic stopped the crashes.

Oh really? I thought I was on the safe side with two 700x6000p graphics with 18 frames working just fine (amongst 600 other graphics on a smaller scale), because there aren't many people using files that large. I shall add the information you provided to the OP.

[Ness-Wednesday]

Things that don't cause any destabilisation which I tried:
Lots or large custom graphics. These only increase loading time.

You just didn't make the graphic large enough (or used enough large graphics). Just the other day, I tried to use a 512x422 NPC sprite swap with 94 visible frames (that's 512x42112 total, for a cut-scene), and SMBX overflowed, even when I tried to open the level without testing. Removing the graphic stopped the crashes.

Oh really? I thought I was on the safe side with two 700x6000p graphics with 18 frames working just fine (amongst 600 other graphics on a smaller scale), because there aren't many people using files that large. I shall add the information you provided to the OP.

I did a similar thing to this small animation I wanted to do.
It had 148 originally and the size was WAY big and I got the same thing too.
I took away 48 frames and eventually decreased it into 45 frames in total.
After I took away 48 frames, which fixed the "Run time error-6", I constantly got a white square on the screen instead of what was shown in the graphic.
I decreased the size by taking away the frames which was first 76,69,58, and I got to 50 and decreased by 2 until I stopped at 45.
I put your map graphic in and it was the same thing (I was going to make it inspired by that and I would have made more just like so if this bug didn't occur).
Tomorrow, I'll make a topic about the problem with my graphic in the "Help and Support" forum to see what causing the problem, but it is strange for that to happen.

[HenryRichard]

snip

Just out of curiosity, are you using LunaLua? If you are, are you using the latest version?

[Ness-Wednesday]

snip

Just out of curiosity, are you using LunaLua? If you are, are you using the latest version?

Not exactly, I lost my LunaLua version of SMBX like the usual (Malware protection stupidity).
But I could post a screenshot this afternoon.
EDIT: I have a screenshot in this post.
http://www.smbxgame.com/forums/v ... 31&t=11475