Open fgsfdsfgs opened 3 years ago
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.
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?
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.
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
.
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:
xbox_window
pointer was never set toNULL
upon window destruction, meaning recreating windows was impossible;GetDisplayModes
was unimplemented, meaningSDL_GetDisplayMode
would always fail.There are still some issues with the renderer left to solve, namely:
SDL_RenderReadPixels
is unimplemented;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.