Re: Tools

[Pierre Phaneuf <pp@ludusdesign.com>]

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

Eric Ultimate Solitaire has its slowness: it uses a huge amount of CPU
and the backdrop tiling is slow, partly because it does the background
itself instead of having GTK+ tile it. Also, choosing the backdrops
themselves is quite painful!

Also, non-accelerated blitting can be bearable in cases where the
display size and color depth is low enough (like the classic 640x480 in
8 bit PseudoColor) *and* updates are done only to the smallest possible
regions. SDL (used in most Loki games) tells the game that a local
buffer is actually the video memory and updates the real framebuffer as
little as possible. This is for the windowed X target, DGA and other can
be different, of course (but not necessarily much faster).

A top-view scrolling shooter would be a good example of a game that
would probably make SDL crumble apart, particularly so if you run in
TrueColor modes or in larger displays. Raw Xlib would have an edge,
because window-to-window XCopyArea (to do the scrolling) is hardware
accelerated, at around 300 MB/s on my video card (if I remember
correctly). But this would scroll the sprites too, so in the end, making
this run fast wouldn't be trivial at all.

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

Even with a 3Dfx card, there is a noticeable difference, but by large,
it is playable.

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

He was talking about the Microsoft scene as a comparison, saying that
our lack of a single API is comparable to the time where developers were
holding out on 3D because of OpenGL and Direct3D. Then Carmack decided
and they all got on with life. ;-)

And Linux also "possibly" has Glide. I didn't see a lot of stuff in
Linux using Glide directly though...

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

Practically every serious Quake players (like the clans and tournament
players) have 3D audio and smooth USB mouse! Obviously, you didn't play
Quake3 with 3D audio, you can pratically AIM (with something like the
rocket launcher) with the sound!



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

About that "one click to gdb in a window" thing, I think he was being
ironic. Some company or open source developer claim to have a great
visual IDE with all bells and whistle, but the "debugger" feature in
their IDE is a button that starts good olde gdb in a window. How
disappointing for a visual IDE!

Visual C++ may be unstable, but the ideas within are nice, like putting
your mouse over a variable name in your source code will show its value
in a tooltip, or you can right click on it and use the contextual menu
to set a conditional breakpoint or a watch, etc... gdb is powerful, but
in terms of features, the Visual Studio debugger is almost as
feature-rich (the only glaring thing it miss IMHO is the ability of
hooking to an already running process). If someone does something
similar the Right Way for Linux (maybe as a front-end to gdb), it will
be a Good Thing (I don't think *I* will use it, but many people will
appreciate such a thing).

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