Re: Tools

[Pierre Phaneuf <pp@ludusdesign.com>]

Bert Peers wrote:

> Hey while I'm ranting anyway, I can explore the MFC/Qt
> issue further if you don't mind :)

Boy, that is a *good* rant!

IMPORTANT NOTE: the following post could be offensive to people with too
large an ego. I want to shake people to make them look around them and
see the reality better.

Reality check:

<rant style="blunt declaration">
Linux sucks for games!
</rant>

No, don't try saying it doesn't, because it DOES. ACCEPT IT and DO
SOMETHING ABOUT IT is what we should do!

> Particularly our coinops which run *gasp* Win98
> and crash like hell could use a stable OS..

One thing I'd like to clear: coinops and desktop machine games are
*very* different. Coinops are much easier, as hardware is under control
and the general workings are under control. For example, you might put
in a Matrox G200 video card and use fbcon, which has rather okay
hardware acceleration support on those cards. This could make a good
product right now.

fbcon-only games sucks for desktop machines, I personally prefer them to
be integrated with X. Going fullscreen is okay, but I want to start my
games by clicking on icons. fbcon is not configured on most stock
distribution, only available (which is hell, as I learned when we
supported only Svgalib for Quadra). The user might be using the vesafb,
which has no acceleration and generally sucks. Pure hell.

Giving fbcon as an *option* is nice and cool, but forcing anything else
than X is pure suicide I think (for a commercial game). The minimum is
X. *Then*, you are free to add funny things like GGI, fbcon or Svgalib.
GGI might be okay if statically linked for example, and DGA might not
count for "the minimum is X", as it doesn't work on many installations
and requires root privs.

> But, the difficulties (growing pains you could
> say) of Linux that I merely chuckled at in the
> past, now are mountain high obstacles to giving
> a Linux-only title the green light.

You mean that you chuckled at them because you are a Linux user,
accustomed to them and/or knowing how to overcome them in ways
commonstock Win98 users (developers?) cannot, right?

> 1) There are few really stable, complete SDKs.  Of
> those, like SDL, even fewer have broad hardware
> support.

This is a mixed point. For example, in Linux, the driver and SDK parts
are much more clearly separated. SDL doesn't have much hardware support
(except when it "plays DirectX", like with the joystick and fbcon
efforts currently ongoing) itself but instead relies on drivers to do
their job.

When XFree86 4.0 hits the street, many games and SDKs will experience an
instant boost in performance. XFree86 is more in the "drivers" category
for this. If SDL uses XCopyArea to do its blitting, SDL apps will double
or triple their performance instantly, and maybe get up to 10 times the
performance if the video card has enough memory to get the pixmaps all
in there! But there is a problem with this, which I'll talk about later,
in the "MS-DOS syndrome" part...

> Win98 dev'ers are ROFLing when Linux
> crawls on at 30 FPS while their hardware blitting
> goes at 300..

Don't talk to me about that! (30 MB/s versus 474 MB/s on cheaper
hardware with DirectX! ARGH!!!! FUCK ME HARDER WITH A BARBED TELEPHONE
POLE!!!)

> - bloated as it may be, it's also the
> centerpoint of all development, so it's pretty
> stable, bugfree, even fast

For the stable and bugfree parts, this is quite undecisive (for stable,
try your app with many video hardware, and bugs, there are!). It is
fast, as OEMs battle to prove their stuff is better. An open source
hacker doing a driver for some video card has nothing to prove about the
hardware, he has much less to lose if the video card potential is not
used at 110%.

> - it's on every end user machine

Isn't so bad. It's on every machine because its on every game CD-ROM.
You could do the same for SDL or ClanLib for example.

> - all OEMs know what SDK to build a driver for

I mentioned this earlier, is mostly wrong.

> - we know what to program for.  Watch the
> stagnation, or rise in cost during the
> OpenGL/D3D battle, when people where uncertain
> which one would win, and then developed either
> for none (waited), or for both.  Imagine how
> many Win98 dev'ers are held back to jump into
> Linux by the choice of SDKs available there.
> "What if I pick SDL but the only hardware
> accelerated blitting modules for a particular
> video card are written for ClanLib ?" people
> think..

This is partly a problem, but not as bad as it seems. High-level APIs
like SDL and ClanLib will use Xlib, DGA, fbcon, GGI, OpenPTC, Svgalib or
whatever it needs to do its work. I personally think that work should
converge on X, XFree86 and DRI as the low-level drivers, but if you
program to SDL or OpenGL, it will most probably use whatever is best
without any problem.

The "not already installed, not popular enough" problem is more
realistic, and is of less importance already for CD-ROM releases.

> The situation seems to be improving a bit, for 3D
> cool OpenGL support is coming up so future 3D
> can be safely betted on OpenGL.. But we're not
> there yet completely, plus, the same problems arise
> in input handling (say exotic joysticks, feedback
> support), sound (which sdk ? which drivers ?), etc.

3D is a difficult thing to get right, and strangely, because of that, it
is getting resolved better and faster than other problems. Things like
joystick support and sound are "working, but eeks", which satisfies too
many people and leaves them with nobody working on this. 2D hardware
acceleration is another example of this (my current favorite)...

> What Win98 dev'ers need to switch over, is
> Visual C++, period.

I was told "KDevelop is an open source Visual C++ for Linux"
somewhere... Never tried it, as I prefer makefiles (and our Win32 boys
are looking at my makefile system gleefully, on the verge of using it!).

> the needed code, done.  The difference between
> "barely support for a Makefile, oh and you
> can debug with gdb" and "DLL with GUI and
> COM/ActiveX support wizard, click here" is so
> huge I get depressed from the amount of work
> Linux needs to get there.  Yet once you've
> learned the hightech way, you never want to
> go back to bare Win32 API programming.  So
> the gametool dev'ers using MFC also don't want to
> go "back" to bare X/Xt/Motif programming, or
> for that matter Qt/Gtk-- with manual connection
> of signals to slots etc.  Again, they'll only
> switch over if they have Visual C++ for windows.

I agree 100% with this part. Glade and friends are making this soon a
reality, but not there yet.

Hmm, InterfaceBuilder on NextStep... MFC simplicity meet Unix excellent
design tradition, titillating! :-)

> Now, don't get me wrong.  I'm not trying to start
> a flamewar, nor am I suddenly very "antilinux".
> However like I said, recently the options for
> making Linux games are very real, so instead of
> casually surfing, me and other developers are
> now looking into the options very seriously.
> The above is what emerged as common "omg, is
> this the middle ages", the result is that most
> feel that gamedev for Linux is now at the
> level of MS DOS or Win3.1 at best.  The problem
> is lots of Linux people still consider those
> (esp. DOS) as excellent game dev platforms,
> to strive for..

OH MY GOD, the DOS syndrome, aka the demo hacker syndrome!

One of my biggest problem with Linux game development is that it seems
an awful lot of people seem to come from the demo scene. The thing is,
while making an ubercool demo is excellent work and requires an hefty
amount of wizardry, this is not so-called "serious game development".

The most easily seen symptom is the belief that direct access to the
framebuffer ought to send me running naked in the city, laughing like
crazy. And also that assembler will turn you into a chick magnet.

OpenPTC is a nice example. The thing is, direct framebuffer access is
OLD TECHNOLOGY, get it? Yes, it was incredible to see how demo coders
weaved fantastic assembly functions to extract that much performance for
your hardware. But did you ever wonder why a demo runs doesn't run any
faster after you changed your 1 meg S3 Trio64 to an incredible Voodoo3,
Matrox G200 or nVidia TNT? What, 20$ of hardware is just as good as
200$??? Ahem!

The thing is, the blitter on any modern video card can do most things
from 2 to 20 times faster than the very best hand optimized assembly
code. Straightforwardly usable in normal C or C++ using DirectX. Too
many people do assembler while letting their testosterone think. For
things like sound mixing and color conversion (like Hermes), this can be
what is needed, but the times of a demo with large amounts of assembler
is gone.

This is the difference between Demo Bob and John Carmack.

Just to kill over any "direct framebuffer" fan using locked DirectDraw
surfaces, you might want to know that the most recent crop of nVidia
video cards do not support that operation the way their DirectX driver
is written. The locking calls will succeed, but will be emulated by
copying the whole surface into system memory, letting you play with it
there, then copying the whole thing back to video memory when you unlock
it. Think about it, even if you touch a SINGLE PIXEL, the whole surface
will be copied TWICE! Generally, the direct framebuffer people will also
use a single screen-sized surface, getting them a maximum amount of
copying. You can get as low as 10 fps on a 200$ card capable of doing
the same effects at 80 fps!!! GREAT!!!

Incredibly, a cheaper card would be faster there. Hey, I'm dumping my
Millenium right away!

This IS the Middle-Age! We (mostly) think we're unbeatable in our
stronghold castles, but wait until a smart bomb hits us in the middle of
the night, with laser-guided precision through our bedroom window! We
are no match!

> Are these issues real, or is the
> situation improving fast and is this just an
> image problem ?  How are OEMs looking at Linux,
> how do they decide what drivers to build ?

Some of the issues are real, some aren't. Many things need to be done or
need to happen. For example, some people should leave their Mode-X days
behind and head into the hardware accelerated graphic pipelines of the
future instead. If OEMs could start seeing Linux as a market and come to
write *aggressive* drivers that will let them say that their
competitor's hardware is crap, that would help a lot.

> Are Linux people really shy of advanced
> coding tools, or are those under construction
> too ?

Many advanced coding tools are under construction, and are taking longer
than Win32 tools took for two reasons: they are under-manned and they
are doing it properly.

-- 
Pierre Phaneuf
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi