[SDL] DirectX 7?

David Olofson david.olofson at reologica.se
Mon Sep 30 06:46:01 PDT 2002


On Friday 27 September 2002 11:55, Neil Griffiths wrote:
> Hi,
>
> >> Need I mention that Linux is a server OS, not a desktop OS?
>
> NW> It's both. Right now I'm typing this on my home PC, running Linux,
> which I NW> don't use as a server :-)
>
> It's not up for debate, it's a server OS whether you use it as a
> server or not. :)

A server *kernel* I'd say. (Linux is a kernel; not an OS.)

KDE or GNOME are hardly server applications, and you don't have to 
install anything but Linux, some libc and a bunch of other libs and 
daemons not found in a typical server. Is it still a server *OS* if you 
don't even have basic file sharing and rlogin/telnet/ssh installed...? ;-)


> When the kernel starts being written with desktop users in mind, I'll
> change my opinion, but right now it is still being written for
> servers. Therefore my statement stands true.

Well, IMHO, using a server kernel for a desktop OS isn't a bad idea, 
provided there is support for what you need. I've never had to explicitly 
defragment a Linux fs, I don't have to wait for *minutes* with a frozen 
file manager after moving or deleting a few thousand files, and I don't 
have to wait for up to half a minute before even trying to look at a CD I 
insert. I have to do all the latter with Win98, and some even apply to 
Win2k.

If you're trying to tell us a server kernel is a bad thing to have in a 
desktop system, at least, I'm not bying it.


> NW> Surely SDL makes programming games on Linux (and Windows)
> relatively NW> easy??? Without it, using raw X or the Windows API, yes
> it would be NW> difficult, but it would be difficult on Windows too.
>
> Yes, but getting fast graphics and decent sound without break-ups and
> access to high-accuracy timers - things you really need for games -
> are really tough to do in Linux. It's not designed for that. And then
> you have issues with threading and so on...

Right. However, most of these issues are ones that will have to be dealt 
with before 2.6/3.0 for other reasons, since the underlying problems also 
affect high end MP servers. Most importantly, this means that worst case 
latency has to be reduced significantly, which just happens to greatly 
benefit multimedia as well.

As to hr timers, the lack of those are more a function of lack of need 
and interest than anything else. The RTC has been there for ages, but 
still, no one has bothered to implement a proper "multimedia timer" API 
for it. Also, "HZ" (100 Hz on x86 by default) will be increased 
significantly in 2.6/3.0, so the old timers will get much better 
resolution as well. Just a matter of minor tweak - not redesign.


> NW> Such egalitarian principles should extend to running on lower end
> NW> machines. By lower end I don't mean really over the top, like 386s,
> but NW> certainly higher end Pentium Is, and 32 or 64MB memory. Why
> should I have NW> to throw away money on upgrading my system because of
> lazy, inefficient NW> programming?
>
> That's not what the FSF are there for though. They're not telling
> people what spec the software would run on (which limits the amount of
> software that you'd be seeing if they did BTW), they're saying that
> software should give people freedom.
>
> I agree in principle with what you're saying - I certainly think that
> system specs have gotten out of control and software really doesn't
> need the specs that it does, but that's not for the FSF. It's for some
> other group...

Users, maybe?

I don't think there will be much serious work to support low end 
hardware, unless enough people *need* it.

That said, there *is* uClibc, busybox and a bunch of single floppy 
distros and whatnot for embedded systems, and embedded graphics support 
is improving as well - but I'd say it seems like even the embedded 
systems are getting too powerful to motivate much further work on 
minimizing footprint and maximizing performance on really low end 
hardware.

And what can you really do, anyway? On machines like Pentium(MMX) or 
slower, you're approaching the level where you have to "cheat" to get 
serious performance, and that means you have to use custom 
implementations for many things anyway.

Or, as an example, should we implement various forms of fake, dither 
based alpha and that sort of stuff in SDL? Now that the vast majority of 
us already develop on and for machines with >700 MHz and 32 MB 3D 
accelerators or better...?

Who are we going to force to do all this 486/586 asm hacking? ;-)


//David Olofson - Programmer, Composer, Open Source Advocate

.- Coming soon from VaporWare Inc...------------------------.
| The Return of Audiality! Real, working software. Really!  |
| Real time and off-line synthesis, scripting, MIDI, LGPL...|
`-----------------------------------> (Public Release RSN) -'
.- M A I A -------------------------------------------------.
|    The Multimedia Application Integration Architecture    |
`----------------------------> http://www.linuxdj.com/maia -'
   --- http://olofson.net --- http://www.reologica.se ---




More information about the SDL mailing list