Extend functionality of Mega Surfaces

[Splendide-Imaginarius]

pon7126 reported on Discord that on a particularly low-spec GPU (I suspect the texture dimension limit is 4 Kipix but I didn't verify this), Symphony hits the texture size limit (killing the game) on the save menu.

It might be nice to handle this case with Mega Surfaces, so that we don't rely on GPU specs quite so heavily.

I suspect that extending usage of Mega Surfaces might also improve performance in LLVMpipe and similar software rendering environments, though some benchmarking would be necessary to determine if this is actually the case.

[Eblo]

A rather common example of bitmaps that exceed the texture limit are window contents. At least in VX Ace, the widely used Window_Selectable class creates a bitmap for all of its contents even though only a subset can be in view at any given time. If a child class has a ridiculously large list (Symphony being a possible example), it runs the risk of exceeding a system's texture size limit. I am not certain of XP and VX, but I imagine the same concept might apply.

You floated around the idea of a preload script that might mitigate this, whether it be having Window_Selectable create a bitmap for only part of its contents or something else. I want to throw that idea back out here. A mega surface revision would ideally fix everything, but if that turns out to be nonviable for any reason, this other option exists.

[WaywardHeart]

I actually wrote a script that does that a couple months ago. I think it's pretty hideous and I don't trust it to not break, but here it is if anyone wants to use it.

[Ancurio]

From the top of my head, to support being used as a window contents bitmap (at least the most common cases) , a mega surface would require support for:

• being used as a blit destination (medium)
• text rendering (simple)
• having subrects of it rendered (medium/hard)

(assumed difficulty in paranthesis)

[WaywardHeart]

Nah, I just looked into it and that first one's easy. Bitmap::getPixel generates an SDL_Surface for normal bitmaps, so we can just use that for blitting to them.

Rendering the subrects is a little tricky, but I'm planning on adding parent/children variables to the bitmaps and have the window spawn a child bitmap for the mega surface to blit to and manage that, and attaching a vector of rects to the child so I can try to optimize the blitting a little.

The only real stopper at the moment is #21. I'm going to have to build it on top of that, so I'm so not submitting a PR until that one's finally merged.

[Splendide-Imaginarius]

The only real stopper at the moment is #21. I'm going to have to build it on top of that, so I'm so not submitting a PR until that one's finally merged.

@WaywardHeart I'm targeting getting that merged within the next 2 days, unless something truly unexpected happens in terms of a new bug being found. Sorry it's taken so long.

[Splendide-Imaginarius]

I suspect that extending usage of Mega Surfaces might also improve performance in LLVMpipe and similar software rendering environments, though some benchmarking would be necessary to determine if this is actually the case.

Based on discussion with @LiEnby in Matrix/Discord today, it sounds like this might also help with the PS Vita, which has very limited VRAM and very limited OpenGL support. See https://github.com/LiEnby/mkxp-vita/tree/mkxp-vita.

[WaywardHeart]

Based on discussion with @LiEnby in Matrix/Discord today, it sounds like this might also help with the PS Vita, which has very limited VRAM and very limited OpenGL support. See https://github.com/LiEnby/mkxp-vita/tree/mkxp-vita.

While #148 does a lot to improve support, I don't think it would help much with VRAM limits. Setting maxTextureSize to something closer to the game resolution would help a little, but even setting it to 640 would result in child bitmaps that take up 10% of the Vita's VRAM, plus whatever the surface takes up in system ram. I could maybe get around this by having all child bitmaps share a TEXFBO and blit to it during the draw call instead of the prepare call... yeah, that looks doable, we don't need to touch glState.viewport for child bitmaps. I don't know what it would be like performance wise, but it's better than no performance at all. I'll get that done for you... eventually.

[LiEnby]

Based on discussion with @LiEnby in Matrix/Discord today, it sounds like this might also help with the PS Vita, which has very limited VRAM and very limited OpenGL support. See https://github.com/LiEnby/mkxp-vita/tree/mkxp-vita.

While #148 does a lot to improve support, I don't think it would help much with VRAM limits. Setting maxTextureSize to something closer to the game resolution would help a little, but even setting it to 640 would result in child bitmaps that take up 10% of the Vita's VRAM, plus whatever the surface takes up in system ram. I could maybe get around this by having all child bitmaps share a TEXFBO and blit to it during the draw call instead of the prepare call... yeah, that looks doable, we don't need to touch glState.viewport for child bitmaps. I don't know what it would be like performance wise, but it's better than no performance at all. I'll get that done for you... eventually.

speaking of FBOs the vita actually also has a limit of about ~50 FBOs in total,
you can disable this by patching the kernel which gives you some unknown extra amount, ..
which is what i did in the mkxp-vita port but its really not a great solution