Re: Tools

[Pierre Phaneuf <pp@ludusdesign.com>]

Erik wrote:

> > 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.
> 
> Strange, I think console is a better place for games.

Why?

Note that I said "fbcon-*only*". X doesn't mean windowed by the way,
even without DGA! I've got a few tricks up my sleeve, don't worry! ;-)

> I think re-targetable sdk's are important and will be a strength linux
> has over windows.

Portable to other important operating systems like Win32, Macintosh,
BeOS and other Unixes is also very important. If we come up with a good,
clean SDK that offers very little overhead over DirectX and can replace
it readily (feature-wise, not API-wise, in fact, I think developers
would be relieved to use another API!) and offers them portability, this
could get big...

I think SDL and ClanLib for example, do not advertise themselves enough
to the Win32 developer community. Now we have Linux hackers making games
in Linux and bringing them to Windows, but it could go the other way you
know! :-)

> (yeah, will be. there are a few that do it, but I think they could be a
> lot better.)

Like how? Do you have any suggestions? This is the place to do it, we're
listening!

> as for fullscreen, that is how a lot of games should be most of the time.
> One thing that pisses me off is <rant> when a game sets full screen (via
> dga or opengl) and I cannot switch out without quitting the game. Even on
> winblows, I can "alt+tab" to get back to where I got work going on. This
> annoyed me a lot because I usually telnet all over the place and have stuff
> going on, and I'll get a "beep" which is how I know something needs
> immediate attention, quit my game, check the console, either fix it or
> ignore it, then reload my game back up... If alt+f? or alt+tab functioned
> as it should, then life would be good.</rant>

This is one of the Ludus Design team major priority. In another post, I
mentioned how our internal SDK revision will sport much integration with
the windowing system? That's what we're talking about. The only thing
that is niggling me is that there is no way to ask the window manager
what is the key binding equivalent to Windows Alt-Tab. It's not a big
problem, we'll probably just make it configurable and have Alt-Tab by
default (so Windows people would think it is a normal app).

Note that not all games support "alt-tabbing" properly on Windows,
rather on the contrary. For one blatant example, try EverQuest (also
called EverShit, EverCrap and EverCrash by a few people I know, among
other names...). Alt-Tab will do a variety of things, like crash the
whole computer most of the time, or, if it doesn't crash, freeze the
game, or do the alt-tab, but continuing to draw all over the screen over
the Windows desktop, and so on. If the alt-tab succeeded, big chances
that going back to EverQuest will crash the whole thing anyway. :-)

> > 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?
> 
> any os has obstacles that seem insurmountable at first. Yet companies
> seem to push their developers to learn macos for a tiny boost in
> profits. :/ Then when you compare the target market of most games against
> the average macos user and the average linux user, games are targetted at
> the kind of person who uses linux...

That's true (about the targeting of games market). But many Linux users
(in fact, a larger and larger proportion of them, as Linux is getting
popular with an ever larger range of population) don't know how to
surmount those obstacles, unlike you or I can do.

I would say that making Quadra work with a modern video card (say, an
nVidia TNT2, a Matrox G200, a Voodoo Banshee or Voodoo3) is impossible
without help or a lot of time researching a lot of stuff for a newbie.
Even if they dig out the documentation for Svgalib and find out about
the libvga.config, the chance is they won't know what to do with it, and
if they see the chipset setting, they won't find their video card. It is
expectable that a regular newbie doesn't know if his video card is VESA
2.0 compatible, even less know if his VESA BIOS is "very nicely behaved"
or even what the heck is VESA!

Ditto for making the connection between "framebuffer console" and
"graphics", or again, "vesafb" and "my video card". Bye bye console
video, was nice knowing you...

Any newbie Linux user can use the CD-ROM icon on their KDE or GNOME
desktop to get to the Quake 3 install program (documented in the
manual), install it, then click on the new icon on their desktop and
play right away. *This* is how easy it should be.

> > 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...
> 
> a lot of people have been saying "when X4 is out", myself included. Now I'm
> wondering how much is hype? :)

Well, some guy in the SDL newsgroup saw the numbers from a blitting
benchmark more than double, and Rasterman told gave me a number that was
about 7 times faster. That's an improvement. :-)

> > 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!!!)
> 
> I'm afraid I'll have to pass on that one...

:-)

> > 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%.
> 
> I'd rather have a card that runs 90% solid than a card that runs 110% and
> buggy. The fast game drivers for windows are often very buggy, inducing all
> sorts of oopses and "artifacts"... My experience has been that linux is
> faster than windows for a lot of things, but it's real strength is stability
> and correctness. (and it don't even hold a candle to aix for stability...)

The fast game drivers are not only fast, but also worked on very
intensely by the OEMs. If a magazine says there are artifacts playing
this or that popular game, you can be sure the day after there will be a
new version of the driver on the web site correcting the problem.

Open source is better at stability though, but OEMs also have plenty of
money to throw at the problem.

AIX is unstable? Hmm, I was admin of a farm of RS/6000, and I barely
remember a few going down from out of control memory usage (no memory
left, splat)...

> > 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.
> 
> sdl is so small it'd be trivial to static link it... both are seeing
> themselves into more distros, also. (as are other sdk's).

Exactly. Even packaging a separate library isn't that hard, like I said,
there's plenty of space on CD-ROMs for a small library like those.

> >> - 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..
> 
> am I correct in reading that you say dx has already beating ogl? I see more
> and more games coming out for ogl, and the developers I talk to have been
> pretty disgusted with dx and switching to ogl (and they refuse to support
> linux cuz of "bad opengl support", when I managed to get an answer out of
> one of 'em, he cited the lack of extensions. :( that just plain sucks.)

I think he didn't say any of them "won". He simply relates the time when
it was undecisive, and that most Windows game developers either waited
or developed for both (very few). The problem is driver support, OpenGL
drivers are more complicated and take longer to develop, while D3D
drivers can be done faster. In a way, when John Carmack said Direct3D
was crap and OpenGL was cool, it helped a lot. Very few people have that
much influence (many OpenGL drivers are written with the goal of "making
Quake go very fast").

> > The "not already installed, not popular enough" problem is more
> > realistic, and is of less importance already for CD-ROM releases.
> 
> if a game is really good, people will install the sdk... A lot of
> "commercial grade" games are 60+ megs for a DEMO. how big is the average
> sdk? 2 megs? 3?

Yes, this is a problem of very little importance.

> > 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)...
> 
> 3d is sexy :)

Exactly!

> what's wrong with joystick support? do ya mean the kernel interface, or
> the drivers?

Well, the inexistence of drivers or SDK? The low-level drivers seems
fine, but all they tell is how many axis there are, what are each of
those axis current position, how many buttons there are and what are
their status. DirectInput is much higher-level, knows about what buttons
are part of a "hat", how axis are related, it can even give you "names"
for each object! All of this through the driver that comes with the
joystick (there's no way to get this info from the hardware)...

No such high-level drivers for Linux.

> > 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! :-)
> 
> ok, I've done a lot of those api's, and I get a lot of "we can't find our
> bug, help us" crap. My personal flamebait opinion is that those "advanced"
> tools and "wizards" are *BAD*. They promote bad code style, they promote
> ignorance of how it really works, they promote m$-like products. I use toys
> like that when I need to slap out a quick prototype or I want to see how
> something would work, but when I put together the real code, I avoid the
> "automagick" shit as much as possible. (though I've been doing a lot with
> gtk+/gnome...)

Yes, I partially agree with you. "Wizards" that generate code for you
are generally bad. They often write outright buggy code and you have
some poor guy new to MFC trying to understand what the hell is going out
with code they didn't write.

But InterfaceBuilder (and Glade too, with a special library) for
example, do not generate code. It uses the real classes you would use if
you would write this yourself, them "freezes" the objects into a file.
Then, a function can read the file and "thaw" the objects. But OpenStep
is very different from MFC and most other object oriented widget sets,
you barely ever create new classes for GUI with OpenStep, even if you
write yourself (without InterfaceBuilder). You create new classes only
when you want new kinds of widgets.

So if you don't use InterfaceBuilder, all you'll be doing more is a lot
of object creation, mostly a thing of setting widget positions in
constructor parameters, etc... Not much "real" code. So you're not
actually missing a lot by using InterfaceBuilder!

> >> 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..
> 
> don't dos games have to act as the drivers for sound, video, joystick,
> networking, raw keyboard, etc? I remember seeing an aweful lot of sound card
> setup screens in dos games... :/

Yes, that's true. That's why even widely available 2D acceleration
wasn't used in that time. And now on Linux, sound drivers are in the
kernel, so much less to take care of. But people still think like if
they were in DOS. It just doesn't stick to them. To them, Linux is
similar to DOS but better, mostly because of the parallels (COMMAND.COM
-> bash, "win" -> "startx"...). And they often are the ones despising
Win95/98, because it stole them their precious command-line and text
mode, and they don't use libraries often, prefer small, out-of-the-way
libraries like Svgalib and OpenPTC, prefer the console, etc... You get
my drift?

> > 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.
> 
> I d'no, there's an aweful lot of ".asm" in quake and doom and wolf3d...

If you take quake with the assembler and compare the performance to
glquake without the assembler, which one is going to be nice and fast
and beautiful? Yeah, right, assembler is soooo cool.

> > 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.
> 
> I think there's a bit of a stigma against people who use those tools. Those
> tools allow good coders to become lazy and turn into bad coders. Those tools
> also allow bad coders pretend to be good coders, but no matter what kinda
> super tools are available, bad code is still bad code... I'm probably
> totally off base with that, though :)

Blargh, I don't use these tools much, as I am not doing much GUI work
anyway, but take this into note: Q3Radiant is done with MFC and Visual
Studio.

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