Re: Tools

[Steve Baker <sjbaker1@airmail.net>]

Bert Peers wrote:

> 1) There are few really stable, complete SDKs.  Of
> those, like SDL, even fewer have broad hardware
> support. Win98 dev'ers are ROFLing when Linux
> crawls on at 30 FPS while their hardware blitting
> goes at 300.

In a recent presentation to our local Linux User
group, the boss of Loki said that this stuff was
no longer a problem and that the performance of
their (non-OpenGL) games was pretty much identical
to Windoze.  I own all of their games (thanks Santa!)
and they certainly don't seem slow to me.

OpenGL is a somewhat different issue - and unless
you have a 3Dfx card, you can expect slower frame
rates for at least a couple of months more.

>  Comparing with MS, there's something
> to say for their monopoly; there's only one SDK
> (DirectX), so :
> - bloated as it may be, it's also the
> centerpoint of all development, so it's pretty
> stable, bugfree, even fast
> - it's on every end user machine
> - all OEMs know what SDK to build a driver for
> - 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..

You just contradicted yourself.  Linux has only
ever had one 3D API (OpenGL) - M$ has at least
two (OpenGL/D3D...possibly also GLIDE) as viable
options.

The situation with 2D API's is indeed more confused
in the Linux world - but all that means is that you
have more choice.

> 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.

Well, at present the digital joystick market is
dominated by Microsoft - and the joystick-with-force-feedback
market even more so.  That makes it hard for Linux
driver writers to EVER get those peripherals working.

Audio is less of a problem.  OSS is fine for *simple*
audio - the sound on my copy of Heretic-2 sounds fine
to me.  However, Linux drivers certainly aren't taking
advantage of all the bells and whistles of some of the
more exotic sound cards.

I don't regard either of those things as a reason to
not build games for Linux.  The percentage of people
with those exotic devices is small anyway.

> 2) Tools.  My favorite editor is vi, and I
> use it under Win98 as well.  That said though,
> manual editing of Makefiles is a sign of
> where we are in Linux.

...you havn't discovered auto-make?  I now only
edit Makefile.am - and that's seldom more than
5 lines long - even for the most complex projects.

> I forgot which LJ
> issue I read it in, but some IDE review mentioned
> as a pluspoint the stunning feature that with
> only 1 click of a button you could launch
> gdb in a window !  Wow.
> What Win98 dev'ers need to switch over, is
> Visual C++, period.  Like I mentioned, I use
> MFC, and it's for a reason.

I think this is largely a matter of a preference
for what you are used to rather than some absolute
measure of merit.  I find MSVC utterly horrible to
use.  The integrated debugger sucks, the whole
thing is way too unreliable.

About a year ago I had to build a Windoze project
and the whole experience was HORRIFIC compared to
working on my cosy little Linux world.

> Tools are very
> critical in the game dev process, and when I
> started building them I programmed directly to
> the Win32 API.  It works, but building the
> simplest dialog window is a serious effort :
> managing resources (brushes, contexts blabla),
> positioning labels, buttons, ..., writing
> eventhandlers, filtering out what actually
> interests you, finding ways to draw your
> contents properly on every kind of desktop
> (res/bits per pixel) etc.  Compare with MFC,
> which is indeed kindof where KDE etc are
> going to : draw the GUI, a few clicks, write
> the needed code, done.

Once again, I disagree.  I've been working on
the PrettyPoly 3D modeller - and using FLTK
as a GUI toolkit.  I was able to throw together
the entire GUI in a couple of hours.  I just
drew what I wanted in 'fluid' and I was done.

Under Windoze - even with all the fancy toolkits,
I still hear things about the events you have
to turn off manually if you want your program
to survive something as simple as the screen
saver kicking in.

Once again, I'm not trying to say that Linux
is inherently better in this regard - it's
just a matter of what you are used to.

>  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 really don't think that's the case.  The Loki
guys don't report any of these horrific problems
and they have to port existing Windoze programs
to X without the benefit of being able to start
with a clean X-oriented design to start with.

When I asked the Loki guy what the hardest part
of working under Linux was, he didn't mention
any of the things you complain about.  His
biggest beef was that the various window
managers don't respond in quite the same way
to requests to remove window decoration, they
couldn't agree on whether the size of a window
would include the decoration or not, etc, etc.

Those guys have been there - so you have to
respect their comments.

> 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.

That's very encouraging.

I think your problem is that you expect Windoze
programmers to simply transition overnight to
writing Linux code.  You seem to want Linux to
be just like Windoze - and it isn't (thank God!).

You just have to realise that a lot of the arcane
BS these guys have internalized has to be replaced
with whole new chunks of arcane BS.

A company that wants to be serious about Linux
games should not start out with a bunch of Windoze
programmers and expect to convert them to Linux
Guru's as an 'on-the-job' learning process during
the development of your very first Linux game.

Go and recruit some Linux Guru's. It's not like
there is a shortage of us - or that we are hard
to find!

> The above is what emerged as common "omg, is
> this the middle ages"...

Which was *exactly* my reaction when I was
unceremoniously dumped into the Windoze world.
I eventually decided to install the CygWin
package on my Linux box - and cross-compile
to build Windoze binaries.  To test, I had
a Windoze box running NFS so it could see
the directories on my Linux machine.

I know I'm not the only Linux developer to
work that way when *forced* to work in the
Windoze world.

> Yet probably nobody can write it (except maybe
> people at Loki or something)...

You are *way* wrong about that.  There really
isn't that much that's special about games
programming compared to other comparable realtime
programming tasks (I know - I do both).

I design and code flight simulation software
in my 'day job' - we routinely build programs
that contain several million lines of code - which
have to run at realtime rates - which do heavy
graphics processing, networking, audio, GUI's etc...not
that different from games work actually.

We have always used UNIX for this - mostly because
the Windoze platforms are such junk when it comes to
making 'real' programs.  We transitioned from 'real'
UNIX to Linux without even really noticing that it
had happened.

> Are these issues real, or is the
> situation improving fast and is this just an
> image problem ?

The situation *is* improving fast - but it's
not converging on the Windoze solution. Linux
is not about being compatible - or even vaguely
similar to Windoze.

>  How are OEMs looking at Linux,
> how do they decide what drivers to build ?

Very few drivers are written by OEM's right
now.  They are best advised to stay out of
the software business - give us the specs for
your board and great drivers will 'emerge'.

The whole problem with the slow start for
3D hardware under Linux is a good case in
point.  3Dfx gave us access to their low
level API - and a viable Mesa (OpenGL)
driver appeared within a matter of weeks.

3Dfx themselves didn't get a usable OpenGL
driver out the door (under Windoze) for
over a year after that.  Mesa-for-3Dfx
is still more reliable and less buggy
than the OpenGL that 3Dfx wrote.

However, nVidia decided to quietly
go off and create an OpenGL for Linux,
it's taken *ages* for them to get close,
and they eventually gave up and let
the original team who got the 3Dfx
driver up and running do the work.

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

The tools aren't at all bad - it's just that
most Linux people (but not all) *prefer* the
command line style of working to the GUI/IDE
approach.  OK - so we can't start the debugger
with one mouse click.  It takes FOUR keystrokes
(shock, horror!) to type 'gdb<return>'...but
that's irrelevent because once we are inside
the debugger, we are going to enter dozens and
dozens of commands anyway.  The issue of *STARTING*
the debugger is far less important than the quality
of the debugger you get in the end.

My pet example of how the Windoze designers are
totally out of touch with reality is this:

The windoze debugger requires you to compile your
code in 'debug mode' in order to trace it's execution,
but when you do that, the compiler automatically
initialises all uninitialised variables to zero.

This means that if you have an uninitialised variable,
it'll crash your program *only* when it's not compiled
for the debugger.  Hence, your program dies, you recompile
for the debugger - and the bug "goes away".

Those kinds of things matter MUCH more to me than the
ridiculious question of how much effort it takes to
start the damned thing!

I'd *far* rather see Linux developers concentrate on
functionally useful tools that are reliable and which
work cleanly - than on putting a cute dancing paperclip
into my work area.

In fact, there are graphical versions of GDB - most people
don't use them.

If you absolutely MUST have an IDE, then I suppose you
should get CodeWarrior.  I have no idea how good it
is - I've never had the slightest inclination to try
it.

The 'command line' versus 'gui' debate has been raging
for *years* and there is never a conclusion.  I think
it's simply a matter of how you currently work rather
than any absolute technical reason why one is inherently
better than the other.

-- 
Steve Baker                  http://web2.airmail.net/sjbaker1
sjbaker1@airmail.net (home)  http://www.woodsoup.org/~sbaker
sjbaker@hti.com      (work)