Re: Tools

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

On 07-Jan-2000 Pierre Phaneuf wrote:
> 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?
> 

my dogslow 'puter is why :) X adds a noticable overhead (even w/o a wm). I
typically shut down X and apache and any other hefty programs before I can
consider playing glqwcl...

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

more push for win32 attention, definitely. "automatic" handling of making sure a
change in vc's or windows is handled appropriately (like I can hit alt+f3 and it
doesn't stay in fullscreen opengl mode.) SDL is almost there, but I feel it has
a few downsides, like being limited to bmp and wav. Documentation is a biggie,
I realize both clanlib and sdl have good reference documentation, but I'm too
plain stupid to just jump in and know what to look up in a reference manual :)
Good tutorials are a must. The most amazing tutorial I can think of is the one
that came with qt, where it'd walk you thru the aspect, then had "do this"
challenges at the end (I actually did them, and that helped me a lot. Too bad
I'm not fond of qt itself :). there is an effort at a clanlib tutorial, but
it's an outdated sliver of what it should be... After looking at a lot of sdk's
a few months back and using clanlib a little, I'd say the most appealing is
sdl. It's small, light, C (not c++, I like C.), and seems fairly well featured.
I looked thru the docs on it and it seems like most of the main features are
documented, and there little "how to do this" code snippets here and there. A
strong tutorial and some good advertisement can probably make it a common sdk...

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

awesome :)

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

hehehe, yeah, ta:k will change to the desktop, but when you try to get back in
the game, you get a plain black screen. that pissed me off a lot. However, I
wouldn't consider a windows product to be an amiable goal quality-wise. I just
lust the game selection ;)

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

linux is becoming present in a broader spectrum of society. There're some
people in their 60's and 70's at the lug that I attend. Young children are
being exposed, etc... They seem to have no problem getting some of the groove.
probably the biggest impedence to learning linux is windows experience. Even
macos ppl seem to get into linux pretty easily :)

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

part of me says yeah, and part of me feels like that would be bad. If you make
things easier, people will learn less, the average users ability will lessen,
and the software will become... windowsy. (that's my speculation)

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

cool, now I can't wait to check it out :)

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

I was saying that linux is nowhere near as stable as aix :) My experience with
aix has been that it does not crash. Period. (I d'no 'nuff on aix to comment on
out of memory... never seen it)

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

there was a blurb about that on some game site recently, uhhh, "ask dr hook" or
something silly like that, where the guy talked about the "preferential
treatment" id received... What DX offers that opengl doesn't is stuff like
input, sound, network, and mebbe threading and stuff. This is exactly the kind
of a place a xp sdk like sdl would be immensly useful :) To create a full
platform independant development environment using ogl for gfx and the sdk to
set the window/mode and handle the "other stuff"

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

the linux driver in 2.2.x will tell you how many axis, how many buttons, the
name of the joystick, which buttons are pushed, and which axis are where...
buttons are stored bitwise so you just & the ones you want out. axis are stored
in an array of floats, so you just look at the one you want... one read() to
get them all. Meta info is gotten thru ioctl calls... (hats are handled as
buttons iirc). I'd imagine you could easily write a light wrapper to give the
axis names and stuff... xaxis=axis[0] and such... I personally would rather
work with an array than 4 variables myself :) *shrug*

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

I've seen the libglade stuff, ummm, I think in memprof

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

I about wigged out on a professor for calling unix "glorified dos" once... 
I prefer console, used to use svgalib, and prefer small light libraries... I
also feel that the libraries and kernel should provide good abstraction for
hardware... so I d'no if you're being fair :) I can beleive that there are 
plenty of people who think they can do a much better job than the library
providers and kernel abstraction, tho... Be nice if those people offered their
skills to the libraries and kernel instead of making their own little
psuedo-drivers for their use only, tho

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

that wasn't the subject of my response :) You made a statement that "real"
programmers don't use asm, and used carmack as an example. His code is rife
with assembly...

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

I haven't seen the q3 support tools. The q1 support tools were pretty sluggish
and shoddy imho, and when I was writing q1 mods, I quickly ditched id's for
modified re-implimentations...

> -- 
> Pierre Phaneuf
> Ludus Design, http://ludusdesign.com/
> "First they ignore you. Then they laugh at you.
> Then they fight you. Then you win." -- Gandhi
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
> For additional commands, e-mail: linuxgames-help@sunsite.auc.dk
> 
> 

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