Raise TR2 texture limits

[lahm86]

Resolves #1795.
Resolves #1796.

Checklist

• I have read the coding conventions
• I have added a changelog entry about what my pull request accomplishes, or it is an internal change
• I have added a readme entry about my new feature or OG bug fix, or it is a different change

Description

This raises the following limits:

• Object textures (2048 => unlimited) - TR1 and TR2
• Sprite textures (512 => unlimited) - TR1 and TR2
• Texture pages (32 => 128) - TR2

The internal game_buf now also matches TR1 at 128 MB. Object and sprite textures are now allocated in game memory as opposed to keeping two permanent arrays at the maximum size. Texture pages are already using game memory. As an aside, there is a bit of a disjoint in the way we initially process texture pages, mainly because of injections in TR1, so I'll aim to get this behaving more commonly in a follow-up PR.

I've also separated the texture storage/handling from output.c, making split modules here instead. I'm aiming also to get texture pages moved from globals into the new texture module. The split is in its own commit, so this may be best reviewed overall per-commit.

I've tested a level with everything at the maximum and it loads fine. For regular levels, there should be no change.

[github-actions]

Download the built assets for this pull request:

• TR1X-4.7.1-677-g7b3b2d2-linux.zip
• TR1X-4.7.1-677-g7b3b2d2-win.zip
• TR1X-4.7.1-677-g7b3b2d2-win-installer.zip
• TR2X-0.8-455-g7b3b2d2-linux.zip
• TR2X-0.8-455-g7b3b2d2-win.zip

[aredfan]

Found an issue - the game crashes when I play The Deck (10) or Catacombs of the Talion (13), then use the level skip cheat.

[lahm86]

Thanks @aredfan, fixed.

@rr- I've added an Output_UnloadBackground call when unloading a level, I think we were using the previous level's object texture in some cases, so because we're now clearing out the array this was a null. Maybe this call would be better in M_End in the stats phase? Or perhaps flushing it regardless when unloading the level is best as we don't necessarily know the GF sequences that have preceded.

[rr-]

@rr- I've added an Output_UnloadBackground call when unloading a level, I think we were using the previous level's object texture in some cases, so because we're now clearing out the array this was a null. Maybe this call would be better in M_End in the stats phase? Or perhaps flushing it regardless when unloading the level is best as we don't necessarily know the GF sequences that have preceded.

Apologies – I missed your comment earlier. I think that normally, the module that loads the backgrounds should also be the one to unload them. The O_INV_BACKGROUND does stand out as a special case, but unloading it from Level_Unload() could unintentionally impact other types of backgrounds, like image-based ones. This might not cause noticeable issues to the player, but it does result in a bit chaotic dependencies.

Having Phase_End always handle background unloading could be a better approach, but it's not perfect either. On reflection, even the current setup is a bit shaky – phasers using backgrounds assume these will not be changed, not even by nested phasers. To deal with this, they'd need to manage changes during suspend/resume routines, likely by checking what the current background is.

With all that in mind, how do you feel about adding a function to check the background type, then unloading it only if it's INV_BACKGROUND_OBJECT during the object/texture unloading process?

[lahm86]

Thanks, I've added this check now. LMK if this looks OK.
@aredfan looks OK to me in-game, but would appreciate a second quick test if you get a chance.

[aredfan]

@aredfan looks OK to me in-game, but would appreciate a second quick test if you get a chance.

Of course. 👍

I can confirm all the OG levels are loading properly, LGTM.

[walkawayy]

@lahm86 @rr- this first TR1 changelog entry should say object texture limit I believe. I think it's wrong in develop currently.

[lahm86]

You're right. I can fix in the next texture PR. Thanks!