DirectX...for X

SDL stands for Simple DirectMedia Layer and it was developed by Loki Games (maintained by Ryan AFAIK) as an API layer to easily port/develop games by providing interfaces to networking, audio, video, etc.

While SDL is not DirectX, it's a close equivalent and it did make Loki's task of porting DX games relatively more straight forward than without. At least that was the theory, hehe.

I reckon some commercial Linux games use this (all Loki ones, I think) as well as games like Neverwinter Nights.

SDL's video section, I think, kind of wraps to OpenGL. It's been a while since I've last handled SDL though so I could be wrong.

I'm sure Svartalf can provide more accurate info. I feel old already. hehehe.

Quote:

---

Originally Posted by niniendowarrior

SDL stands for Simple DirectMedia Layer and it was developed by Loki Games (maintained by Ryan AFAIK) as an API layer to easily port/develop games by providing interfaces to networking, audio, video, etc.

---

Heh... I'm not sure what official/original relationship SDL had with Loki- my somewhat fuzzy recollection of things places SDL's existence a tad bit before Civ:CTP's start of development (i.e. the start of Loki...); that could be wrong, but I do know that SDL was actively maintained by Loki during it's existence- with varying parties maintaining it throughout it's existence, including Sam Lantinga and Ryan Gordon. I think Sam's still got some involvement in the whole thing, even.

The rest would be pretty accurate though. However, having said this, the sound support's VERY primitive and the network support's also that way- you'll want to probably consider using OpenAL-soft or Portaudio for sound and Grapple or OpenPlay (I'd vote for Grapple, myself- while it's an LGP originated LGPL library, there's a REASON we ditched OpenPlay and spent 4-6 months inventing Grapple...) for the networking.

Quote:

---

While SDL is not DirectX, it's a close equivalent and it did make Loki's task of porting DX games relatively more straight forward than without. At least that was the theory, hehe.

---

Theory sometimes is the reality. Sometimes, it's not so- it's not always the impedance mis-match between the APIs that is the problem. It's the atrocious code that VC++ allows a studio to get away with that is the real bugbear in a porting project.

Keyboard and joystick is close enough to not be too much of an issue. Simple sound playback is also not an issue. Simple networking is not an issue. Basic threading as well. For positional and more complicated Audio, OpenAL was supposed to be the biggie- on MacOS and Windows, it still is. With OpenAL-soft, it should be back on track for Linux. Grapple should handle many of the network solutions- unfortunately, it's not interoperable with DirectPlay.
2D graphics is dealt with nicely so that differences in getting a framebuffer plane is simplistic- and in some cases, some functionalities are hardware accelerated on the platform where possible. 3D is handled by your system's OpenGL layer, but it provides a clean wrapper framework to tie into it portably.

All in all, if you WRITE a game with SDL, OpenAL, and Grapple, you'll end up with a title that will cleanly run on Linux, MacOS, Windows, and more. There may be some performance glitches on some platforms (On Windows, it wraps DirectX with a thin shim, but it's still there... And so on, and so forth...) but all in all, it's not a bad way to make a game if you want to target things easily.

Quote:

---

I reckon some commercial Linux games use this (all Loki ones, I think) as well as games like Neverwinter Nights.

---

Pretty much every one of them that I know of brings in SDL to provide the threading handling, user input handling, and OpenGL abstraction handling. It makes life a bit easier.

Quote:

---

I'm sure Svartalf can provide more accurate info. I feel old already. hehehe.

---

YOU feel old? Damn, I feel ancient. ;) :D

Quote:

---

Originally Posted by Svartalf

Heh... I'm not sure what official/original relationship SDL had with Loki- my somewhat fuzzy recollection of things places SDL's existence a tad bit before Civ:CTP's start of development (i.e. the start of Loki...); that could be wrong, but I do know that SDL was actively maintained by Loki during it's existence- with varying parties maintaining it throughout it's existence, including Sam Lantinga and Ryan Gordon. I think Sam's still got some involvement in the whole thing, even.

---

Yeah. Sam does have involvement in the project. Much of what I said, I'm basing on what I remember from Sam Lantinga's book before. I think Sam spear-headed SDL development when Loki was starting, or something like that. My memory is terrible with details though, so it's fudged with Rocky Roads and Black Forest cake. :D

Thinking about SDL, OpenAL and others makes me think of how I should have taken SDL a bit more seriously. But well, SDL is still a nice api to have to build games. If it directly interfaced with the GL procedures of graphics card, I wouldn't know how good would that do.

I tend to think the benefit of doing that is almost negligible.

Quote:

---

Originally Posted by niniendowarrior

If it directly interfaced with the GL procedures of graphics card, I wouldn't know how good would that do.

I tend to think the benefit of doing that is almost negligible.

---

Direct acceleration of 2D functionality, even when a title is Windowed (which right now fubars hardware acceleration in many situations...). It's a definite benefit, esp. with us going to AIGLX, etc. How much of one, I couldn't tell you, but it's not negligible. I just don't know if the payoff would be worth the needed work.

Quote:

---

Originally Posted by niniendowarrior

If it directly interfaced with the GL procedures of graphics card, I wouldn't know how good would that do.

I tend to think the benefit of doing that is almost negligible.

---

I'd assume the benefit would be great, but I suppose it depends on what you want the end result to be.

I might be wrong, but accelerating 2D stuff in hardware might not be worth it with a fast CPU - the desktop might be responsive enough that you could get away with it.

Obviously 3D stuff is a different kettle of fish, and needs to be done in hardware.

So the question is, for games and other 3D stuff is libSDL.so->nvidia.ko worth the effort over libSDL.so->libGL.so->nvidia.ko?

Are the SDL data structures that different from OpenGL ones?

Quote:

---

Originally Posted by alurien

So my question is this: in the same way that I have a /usr/lib/libGL.so.169.12 which is built for my nVidia card, why can I not have a /usr/lib/libDX.so.169.12, which implements DX9 (or 8, or 10 or whatever), and is built for my card (since the GPU has hardware support for DX8,9,10 operations)

Other DirectX stuff such as sound and networking is already handled nicely by WINE, so it's really the graphics stuff that needs to be plugged in.

Is this possible? Would it require loads of work inside the X server? Is it worth petitioning nVidia to do something like this?

---

Is this possible? Yes.

Would it be extremely useful? Yes.

Will it happen? No.

Microsoft and its Linux infiltrators will make sure it doesn't.

Quote:

---

Originally Posted by alurien

So the question is, for games and other 3D stuff is libGL.so->nvidia.ko worth the effort over libSDL.so->libGL.so->nvidia.ko?

---

T, FTFY ;)

Quote:

---

Originally Posted by alurien

I'd assume the benefit would be great, but I suppose it depends on what you want the end result to be.

I might be wrong, but accelerating 2D stuff in hardware might not be worth it with a fast CPU - the desktop might be responsive enough that you could get away with it.

Obviously 3D stuff is a different kettle of fish, and needs to be done in hardware.

So the question is, for games and other 3D stuff is libSDL.so->nvidia.ko worth the effort over libSDL.so->libGL.so->nvidia.ko?

Are the SDL data structures that different from OpenGL ones?

---

To be honest, the way it's probably going to work is libSDL->libGL->.ko, primarily because you'd have to be an in-house nVidia developer to effectively build an SDL api that directly interfaces with nVidia's graphics card.

libGL->.ko is done by nVidia and chances are, it's not going to be easy to figure out how nVidia renders things on your own.

Perhaps there is a performance increase. How much, I can't really say. But yeah, if you ought to build a api that directly interfaces gfx hardware... you should look at sdl.

So, whatever happened to DirectX for X?

It would probably be a lot less work to optimize or otherwise adjust Xorg and friends toward accommodating wine's DX->OGL translation better.