video: Add hardware-accelerated rendering backend

[fgsfdsfgs]

Adds a hardware accelerated SDL renderer backend that uses pbkit. Could be useful for upscaling screen-sized textures, especially in games like Chocolate Doom, where a 320x200 software rendered framebuffer texture is stretched all the way up to cover (almost) the entire screen.

In addition, this fixes a couple issues that I found in nxdk-sdl:

• the xbox_window pointer was never set to NULL upon window destruction, meaning recreating windows was impossible;
• GetDisplayModes was unimplemented, meaning SDL_GetDisplayMode would always fail.

There are still some issues with the renderer left to solve, namely:

• while rendertargets are now supported, I haven't tested them very thoroughly and I'm not sure they are correctly implemented;
• SDL_RenderReadPixels is unimplemented;
• pbkit is never deinitialized after creating one accelerated renderer, because doing that in DestroyRenderer and then recreating the renderer causes a loss of video output (black screen, but the app is still running) for some unknown reason.

This was tested in my Odamex fork and appears to work fine.

UPD: The SSE define fix and the ARGB8888 change have been reverted, since there appears to be no need for them anymore.

[Ryzee119]

Ive tested this in SDLPop and Xenium-Tools. both work quite well. I definitely notice a performance gain in 720p Xenium-Tools. Good work with this.

[JayFoxRox]

nxdk-sdl/include/SDL_pixels.h

Lines 236 to 238 in a2a2d9c

	SDL_PIXELFORMAT_RGB888 =
	SDL_DEFINE_PIXELFORMAT(SDL_PIXELTYPE_PACKED32, SDL_PACKEDORDER_XRGB,
	SDL_PACKEDLAYOUT_8888, 24, 4),

RGB888 is a 32-bit mode (XRGB, X is implied), but it's alphaless. I believe we chose it because the existing framebuffer is alphaless at application startup.
Other nxdk APIs which share the same framebuffer (like debug.h) also don't support alpha.
Therefore, I consider RGB888 to be more correct.

I believe this was also a format that was taken from existing backends, because some popular backends (or those we took as reference) are also alphaless:

• Windows backend is alphaless
• Wayland backend is alphaless
• dummy backend is alphaless
• offscreen backend is alphaless
• haiku backend is alphaless

For this change, we should verify that apps aren't broken. I believe I actually had some trouble with some apps not working correctly with alpha channel (maybe it was even zombie-breakout?).
I believe some PSP ports of SDL apps also required a hack to avoid issues with the framebuffer having the alpha channel.

If we want to use alpha based modes we'll also have to modify RGB555 for consistency.

[fgsfdsfgs]

Truth be told I actually don't remember what issues this was causing and why I changed it. I assumed it was 24-bit because of the name, since there's SDL_PIXELFORMAT_RGBX8888 I would expect the other one to be named _XRGB8888.
Could've been something related to surface blitting in the Odamex renderer.

[GXTX]

What's the status on this? I was looking into the intrinsics in SDL and noticed we had a PR here already addressing it. Could we perhaps open a 2nd PR to fix just that if this is deadlocked?

[kosmas12]

It works but doesn't support some things like render targets. I tried to use it in my fixed Zombie Breakout port but due to not having render targets the zombies weren't properly rendered. I also tried it on some more things that don't use render targets (like an old project of mine) and it seems that it gives quite the performance boost, even when just going software mode now that MMX and SSE work.

[fgsfdsfgs]

The SSE define fix and the ARGB8888 change have been reverted, since there appears to be no need for them anymore. I've also added (barely tested) support for rendertargets and (untested) SDL_RenderSetClipRect.