Bryan Edds

I'm currently working on putting the main subsystem processing on separate threads. If this works well, it should at least double performance.

I've managed to get rendering and audio onto separate threads, but not physics. Putting physics on a separate thread may play hell with certain semantic guarantees that are highly desirable....

I just found out that threading does not work with the out-of-box SDL renderer, so I have to temporarily put the rendering and audio code back on the main thread....

Today I attempted to utilize WeakReference in ComponentRef to lighten the load on the GC's scan process. This was not a good idea since it crushed performance. Apparently there is...

Another solution to the rendering performance problem is the use of SDL_gpu to do rendering. I will be playing with this possibility over the next week.

I was unable to utilize SDL_gpu due to this issue - https://github.com/grimfang4/sdl-gpu/issues/15#issuecomment-851590757 I don't know if the maintainer, @grimfang4 is aware of the issue tho?

Most of these files are SDL2 C dlls. However, there doesn't seem to be a nuget package for SDL2 C dlls like is requested here - https://discourse.libsdl.org/t/getting-sdl2-dll-through-nuget-using-c/26699 ...and I'm not...

Does it work when audio is enabled?

Been thinking about this. Not sure if we want to support this scenario where a device does not expose basic features like audio, rendering, etc. We'll keep this issue around...

YES, I was having the exact same issue trying to get my game engine to run under NUnit, and calling GetTexDataAsRGBA32 and ClearTexData fixed it! That said, I'm ALL on...