Re: Tools

[Bert Peers <rat@larian.com>]

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

This is a vague statement.  The performance may be
identical because the windows version doesn't use
hardware blitting either, or maybe it does but he
measures performance relative to the windows software
renderer.  In that case FPS should match, or even be 
faster, under Linux.  But I have a hard time to believe 
that the software only blitters in SDL can perform like
the DirectDraw cards, like Pierre confirmed too.
Except ofcourse if the CivCTP load is so light that
the cards are idling 99% of their time.

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

I agree with you that the best way to get performance
is to wait for Moore, instead of pushing high-perf but
unreliable drivers/SDKs out the door.  The biggest
issues are not performance (up to some point.. don't
read this as a contradiction with the previous part.
90% of the Win98 perf is ok, 10% isn't) but stability,
completeness and availability.  That's mostly what
I meant with :

> >  Comparing with MS, there's something
> > to say for their monopoly; there's only one SDK

Developers like monopolies.  Pierre's right in that
coinops are easier : the developer has a monopoly on
the hardware used.
>From your comments I would almost believe that the
Linux SDK situation is an image problem after all.
I voice a joystick concern and Ingo pops up an URL
to a solid looking supported joystick list.

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

Contradicted ?  Well, no, it was exactly a demonstration
of what happens in lack of a monopoly.  I agree with
the regular Linux people that monopolies are normally
Evil.  But here I tried to use the D3D/OpenGL battle
that raged once to demonstrate the kind of "hold back"
attitude it induces in developers when there's too many
options.
  There's a difference between mere coexistence, and a real
battle for domination.  To answer Erik, currently the
situation is that D3D and OpenGL coexist more or less
peacefully.  So developers can pick one, or if they have
the resources, support both.  Two years ago the situation
was however that D3D seemed out to crush OpenGL, and
everybody believed that only one would survive, the other
would disappear.  Ergo the very real risk of writing an
engine for one SDK and then needing a costly retargetting
if it turned out to be the loser.  Few people expected
both would coexist in the end.
  Compare to the Linux situation.  SDKs may not die out
as easy, since there's more of a friendly competition -- but
one SDK may still "win" in terms of driver support.  So we're
back to square one..  There's something to say though for
the responses that :
- if 3D gfx settles, and sound and input come along, eventually
there aren't any areas left to work on, and the dust settles.
- most SDKs have retargetable backends themselves, so you
can retarget those instead of your engine, who knows even
on a per-setup basis (detect which subSDK has the best driver
on a particular machine, use that subSDK)...

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

.. if you want to write a driver :(

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

Yeah, that's the problem, "fine" doesn't sell titles.
If you're writing educational software etc it may be ok,
but any serious title (or a title that wants a serious
publisher) will need AEX etc.
  I agree with your assesment that Linux games are getting
a certain goodwill from management because they know the
lack of stiff competition means money.  Not because they
(or their developers) feel there's a technological edge
to be cut switching over.

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

Yeah, well, it has to be in, period.  I don't think you
can sell a FPS without 3D sound these days, or a flightsim
without force feedback joystick support.

> > 2) Tools.  My favorite editor is vi, and I
> ...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.

Ok, I'm gonna try and refocus my opinions here before
we totally get off track.  My post was getting lengthy
so I packed the sentences, but maybe I overdid it
since there seem to be a few misunderstandings here :)

What I basically wanted to say was : Linux is an OS made
by hackers, for hackers; and 50% of the game developers 
are not hackers.  Carry with me for length support of 
this argument :

(slicing up the reply)

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

When I started building games, I too, like everybody else,
assumed the majority of the work was writing all these
things : engines, audio, GUI, networking.  It's not;
the suprising reality is that 50% of the work is split
between the actual game, and the tools.

I'm sure your software, besides cutting edge tech, also
needs modelers to build a landscape, the aircraft, .. ?
You may use Autocad R14 or something, I don't know, but
in any case you'll probably have to get your models from
somewhere.  Same story with a game.  Case study : I'm in
a project that's rolling for 30 months and still not there;
we're talking about a massive RPG here with thousands of
NPCs and 10000s of objects.  All those need their
parameters set : semantic properties, sound and visual
properties, behavior properties, AI settings (for NPCs),
dialogs need to be written, inventories constructed,
branching story lines have to be written and rewritten,
stored and reloaded, scripted sequences have to be
built and edited, spells with dozens of parameters need to
be tuned for gameplay, weapons, shields, armor need to be
balanced using a dozen parameters per item, and so on.

What, you think we'll modify all these using vi and a
text file parser ? :)  It's simple : if the tools suck,
the editors won't experiment.  If misplacing one comma
in a txt file gives them a parse error, they'll try it twice,
maybe 3 times, and then give up.  If you want the editors
to experiment a go go so they can come up with truly
creative content instead of just recycling tried and proven
ideas, you'll need kickass, fast, *robust* tools.
Furthermore, those tools need to be easy to change.
Over those 2 years we've changed the meta-properties and 
whatnot of the world about a zillion times, and every 
change meant changing the dialogwindows of the tools.  

That's why we're so happy to have a good framework like MFC
to assist us.  Erik may be right in that it dumbs us down
to click-click monkeys, but it also gets the job done.
The first year, when I was *not* using MFC, every change in
some data format meant running down my C++ code looking for
widget creation, positioning, property readout, whatnot.
I really really don't want to do this again if I write my
tools in Linux, using Qt or whatever.  I, and others, will
not settle for anything less than MFC, *if* we have to write
the tools.  Ofcourse, 

(other post)
> Yep - and in any case, we are talking **GAMES** here.  How many 
> commercial games use any of that GUI stuff from the OS anyway?
>  Since Xmas, I've installed RailRoad Tycoon, Quake-3, Civ 
> and Heretic II - not *ONE* of them uses the GUI provided by 
> the OS.  They all have custom written GUI's that are utterly
> unique to that specific game.

..you're right in that the actual *game* is much less relying
on the GUI, SDKs, frameworks, whatever, and could probably
readily be done for linux.

But since tools are 50% of the work, 50% of the developers are
on them.  I'm not gonna convice 50% of our developer pool that,
if they want to build tools for Linux, they'll have to go back
to Win32'ish X/Qt/Gtk programming.  And building the game for
Linux but the tools for Windows, sucks.

I'm sorry for this lengthy post, but I think that you, and most
other people who're not into professional game development,
missed my point when I asked for a solid MFClike framework with
the required IDE support : it's for the ever so important tools.
Maybe you now see why I'm wary of statements like :

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

Loki doesn't build games, they port them.  *Huge* difference.
They get the "cool" 50% part.  They don't have to build the
contents, so they don't have to build the tools.  I can
understand their largest concern then is how to port non-X
graphics code to X.  I'm sure they'd have other issues
if they were asked to build tools that need to be
*very* flexible, yet robust, under Linux.  Not saying
it's impossible though.  So ehm...

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

.. I disagree with this.  I do respect them ofcourse.

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

Well, let's not get into counting how many clicks
this or that needs, or the GUI vs command line
debate.  I admire MSVC for the support it gives me
for situations where I just have to get something
done and don't care about who or what.  I mean,
come on, if you want to build a CORBA component
for Gnome, do you really want to write the IDL
(or what is it) spec yourself, manually convert it
to C++ and manually adhere to the semantic specs ?
Not me, I appreciate it if 3 clicks give me a full
working component where all I have to do is fill
in the actual logic, not all the pooha surrounding it
to make it CORBA like.  May be 12 clicks too, or
ctrl-alt-f4 and then f11.

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

This sounds promising.

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

I'm not saying it's perfect; why else do you think
we're looking at Linux ?  Not for the money, but
because we're tired of the windows "issues".

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

Actually, for the "games" part of games, Linux
probably *is* better, if only it was there on the
edge as well as for possibilities and support..

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

Hm, well, yeah, it'd be nice if we never noticed
the difference ;)  Seriously, Linux should
be Linux, but there should be a solution to write
solid game editing tools; this solution should
hold together in the real world..  Manual hacking
with this and that GUI, SDK, script, doesn't cut
it imho..

I think that's what I tried to say last time ;)

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

Trust me, we're not talking M$ drones here.. the disgust
is deep enough to turn these guys into the hardest
Linux zealots you've ever seen  ;)  

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

Yeah, ok, but right now we're looking, exploring.
Hiring means the project already got the green light,
but right now it's looking around and checking the
options.  We could ofcourse hire a Linux Guru
to do the lookaround for us, but chances are he
might not be very objective ;)

> > 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 meant the article.

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

To be honest, posting this to the game list might
not have been such a good idea :)  In retrospect,
I guess my second concern was actually more into
the realm of writing solid desktop applications.



(back to part 1 of My Issues With Linux)

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

Does this mean the Linux community should, for
it's own good, pick an SDK asap and officially
declare it a monopoly ?  Is this what Christian
tried to do, actually ?  (the PenguinX thing)

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

Yep : Linux, built by hackers, for hackers.
Content editors aren't hackers either.

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

*shrug* that was a rhetoric example on my way to
making a point.

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

:)

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

Hmyeah.  You haven't written much desktop apps if you think
the largest contribution of MSVC, and thus the reason you
think I praise it for, is the fact it's part of a family 
that shoves dancing paperclips around, have you ? :^) :^) :^)


Woohaa

Bert
-- 

-=<Short Controlled Bursts>=-