Multi-Threading Quake

[Spike]

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!

[Efess]

quake+quakec loves to abuse those

This is why newer CRmod has issues on other engines (I attempted to use it in JS Quake) - the developer of CRMod created a QC compiler (qccx) which allows the QC dev to access memory directly, which is great for adding features, but breaks compatibility for engines that map memory differently

[Baker]

How is that 99% wrong when it is what SDL's own site says?

Spike did a nice thing saying you are grammatically correct (the thing that doesn't matter), while picking apart the guts of what you said in a technically polite way (the thing that does matter).

SDL mostly just reorganizes system messages into a uniform format so it is comes out the same on every operating system (setting aside Spike's technical points about the sound system).

The overhead is small.

You know the main Quake 3 engine ioQuake3 is SDL, even the Windows version as far as I know. And the current version of ezQuake (the Quakeworld engine where those guys play with 2 colors and the screenshots look like pong and they demand 1400 fps) And Quakespasm is SDL. And most games ported to Linux are SDL. And most games ported to Mac are SDL?

Anyways your text quotes are right. That and a subway ticket will get you a ride on the subway.

[enderandrew]

A lot of Linux and Mac SDL ports use software rendering because Mac OS X has outdated OpenGL drivers and the state of proper hardware accelerated drivers on Linux is always up in the air. SDL is used because it is platform agnostic and makes ports easy. That doesn't mean it always have the best performance. Just saying that people use SDL has nothing to do with my point.

The SDL software renderers are always much slowerer than hardware rendering for a 3D engine.

Even when SDL is passing on the 3D hardware rendering to DirectX or OpenGL and not doing software rendering, it is an additional overhead.

At not point should SDL actually be FASTER than native OpenGL calls.

I believe everything I said was technically correct and you're saying I'm 99% wrong because you want to defend SDL.

But I'm not aware of any scenario for a 3D engine where SDL would be faster than OpenGL. And I didn't say that OpenGL absolutely 100% is always faster, but that it SHOULD be in most cases.

Again, how is that 99% wrong?

[Spike]

SDL provides OpenGL support using direct native function pointers (which you will need to use for any part of opengl beyond gl1.1). The only part of SDL's 3d rendering that isn't exactly as fast as not using sdl is the context creation.
window events

At the end of the day, SDL is just an API. All else being equal yes you will have _slightly_ higher overheads, but the time you save by implementing+maintaining just SDL is time you can reinvest optimising things elsewhere.
Yes some opengl drivers suck, but they suck equally as much whether you're using SDL to create your opengl context or wgl/glx/agl/egl(ie: non-sdl).

In the context of quake, SDL's 2d acceleration with alternative backends is basically irrelevant, while 3d acceleration is native opengl anyway.

[vibok]

SDL is software only (DirectDraw on windows, I think).
SDL2 has hardware 3d, via OpenGL
Not sure which one is used in darkplaces-sdl.exe, for some reason there are both SDL.dll and SDL2.dll in the same folder.

Edit: looks like it uses both, SDL1 for CD, and SDL2 for everything else. Got this info from QuakeSpasm readme.