Re: Tools

[Erik <br0ke@math.smsu.edu>]

On 06-Jan-2000 Pierre Phaneuf wrote:
> 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.
> 

Strange, I think console is a better place for games. But I think console is
better for a lot of things :) I think re-targetable sdk's are important and
will be a strength linux has over windows. (yeah, will be. there are a few that
do it, but I think they could be a lot better.)

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>

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

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

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

a lot of people have been saying "when X4 is out", myself included. Now I'm
wondering how much is hype? :)

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

I'm afraid I'll have to pass on that one...

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

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

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

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

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

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

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

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?

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

3d is sexy :) what's wrong with joystick support? do ya mean the kernel
interface, or the drivers?

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

a few years back I developed on borland, and before that msvc++. When I
switched 100% to linux, I had a real hard time adjusting. "where's the ide?
where do I click to compile? where's the gui constructor?" I learned joe, then
vim, I learned man, I learned qt and gtk+ and svgalib, and a little xlib and
esd's api and joysticks and a few kagillion other things, and it took quite a
while. Now when I try to use msvc++ (6.0) I get pretty frustrated pretty quick.
The problems is the familiarity I think. I would think the emphasis should be
stepping stones, not emulating their way...

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

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

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

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

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

I d'no, there's an aweful lot of ".asm" in quake and doom and wolf3d... 

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

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 :)

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

        -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.