at the same time, its also correct.
Yes, SDL has no hardware acceleration for 3d... in fact it doesn't support 3d at all. what it does support is an opengl pass-through, which allows you do do hardware 3d rendering yourself....
SDL does has overheads above that of native winapi stuff, but such overheads should be small enough as to be insignificant, especially with rtlights.
On the plus side, the way SDL does its audio mixing with threads basically forced on the program, audio mixing (in any semi-decent engine like dp) will be on a different thread. However, dp is lazy and doesn't mix audio in a different thread unless its SDL doing the threading stuff.
This means that DP's SDL port should be something like maybe 5% faster than its winapi/'opengl' port (varies depending on channel counts, audio khz, number of times per frame that the mixer is invoked, etc).
That has nothing to do with rendering.
so yeah, tangent that's back on topic! yay multithreaded audio!
Yes, SDL has no hardware acceleration for 3d... in fact it doesn't support 3d at all. what it does support is an opengl pass-through, which allows you do do hardware 3d rendering yourself....
SDL does has overheads above that of native winapi stuff, but such overheads should be small enough as to be insignificant, especially with rtlights.
On the plus side, the way SDL does its audio mixing with threads basically forced on the program, audio mixing (in any semi-decent engine like dp) will be on a different thread. However, dp is lazy and doesn't mix audio in a different thread unless its SDL doing the threading stuff.
This means that DP's SDL port should be something like maybe 5% faster than its winapi/'opengl' port (varies depending on channel counts, audio khz, number of times per frame that the mixer is invoked, etc).
That has nothing to do with rendering.
so yeah, tangent that's back on topic! yay multithreaded audio!
Comment