Re: Tools

[Pierre Phaneuf <pp@ludusdesign.com>]

Erik wrote:

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

Of course, a computer on the limit of requirements for a game stays
that. That's partly why I think an option for using the console is a
nice touch, for those people with lower-end computer that know what
they're doing and would like to play the games also, even if it means
hacking around a bit... :-)

What I've noted with X is that its mainly a memory thing. If you can
have enough memory to avoid swapping, just don't run memory hungry stuff
(like Netscape for example, or extravagant themes, or Enlightenment (I
use Window Maker with a very simple theme with a high level of success))
and you'll be fine.

I play Quake okay with my Voodoo2 accelerated Pentium 225 with 96 megs
of RAM while leaving Netscape and XEmacs running (the advertised minimum
is a Pentium 233). I cheat a bit, since my bus speed is 75 instead of
66, compiles a kernel faster than a 233/66. ;-)

Apache I have no problem with: if you don't use it, it stays blocked in
its select() all day and gets completely swapped out as needed. :-)

> > Like how? Do you have any suggestions? This is the place to do it, we're
> > listening!
> 
> "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.)

This one is hard to get right with some targets, particularly the
console ones. For example, on a VC switch, you have to give up the
content of your video memory, on and offscreen. I guess moving the data
in video memory to system memory before doing the VC switch is the right
solution, but I heard some of the console targets themselves had problem
with VC switching (fbcon?). Svgalib is okay, except for a slight mouse
problem.

> SDL is almost there, but I feel it has a few downsides, like being
> limited to bmp and wav.

This is by design. Image or sound loading isn't in its goal, and the BMP
and WAV loaders are there only to demonstrate how to do it. Look at
IMGLib, on the same site, by the same author (and contributors), for the
"other" loaders. Soon to be renamed SDL_image or something like that.

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

Ouch, this one hurts. :-)

> Good tutorials are a must.

I see. One nice thing is that often, test programs can do double duty as
tutorials, but I'm not too hot in the "teaching" part... Hey, if
somebody can make head or tail of DirectX (what? I have to speak
hungarian?), Unix-style programming should be a cinch! ;-)

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

Hmm, our library is C++, but uses a component system similar to COM,
that DirectX uses, so a C interface similar to the one DirectX has
("surf->vtbl->bitblt(surf, ...);") is possible. Note that this is not a
wrapper, but a C technique to access C++, so there is no penalty for not
using the "native" interface, except on your fingers. :-)

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

If you want to make a "strong tutorial" (or have some ideas), don't
hesitate to come on the SDL mailing list (or newsgroup, on
news.lokisoft.com), they would love it and be more than happy to help
you out as needed!

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

Yes, that's great, and I always thought Linux wasn't any *harder* than
Windows to *use*, but for the setup and administration side, it's
another story. Somebody installing Red Hat or Corel Linux and dabbling
around in GNOME or KDE is one thing, finding out if your video card is
VESA 2.0 compatible or not and edit libvga.config accordingly is
another!

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

I have to be of those that says yeah, because I have to sell software to
make my money. :-|

Software becoming easier isn't too bad if done properly. For example, I
am often amazed of how well done are the configuration scripts for
networking on Red Hat Linux. Sourcing shell scripts, with the
/etc/sysconfig system is an excellent idea, easy to edit by hand, easy
to parse for configuration front-ends, very cool. It is bad when the
actual workings are really hidden and you cannot explore and hack the
system if you want to, that is the Windows danger.

> > > and correctness. (and it don't even hold a candle to aix for
> > > stability...)
> >
> > 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)

Ah, I see (I'm french, sometimes I don't know "sayings" with strange
literal meaning (like "holding a candle"!))! The software was known to
be buggy, we had to inflate the ulimit for it and it bited back. :-)

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

Hmm, that column is written by Brian Hook, who worked at id Software in
the past... If you could find me the URL to that article, I'd love to
know what he had to say about this, thanks in advance!

SDL is going into that direction, being able to be the support layer for
OpenGL, but it isn't all what DirectX offers, it also has Direct3D
immediate mode, which is an OpenGL competitor, and DirectDraw, which is
a 2D API.

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

Hmm, nice! Where does it get its meta-information? Also, is there the
information about what buttons are part of a hat (and are what
directions!)? A nice interface to joysticks IMHO would be an array of
"objects" (sounds C++ish, but can be done in a C way, like X events for
example), of type "stick", "hat", "button" and "axis" (for lone axis,
like a throttle or a brake pedal). A stick would have 6 members, one for
each possible axis. Those that don't exist on a given stick stays at
neutral position.

> 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

I see the X server as a kind of big windowing graphic kernel, in a
way... And as such, it is quite nice, but it has its problems too...

Do you have any example of people that made their own "pseudo-drivers"?

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

Yes, but that's different in a way. This is still part of the "here is
the linear framebuffer" technology era, and as such requires a good dose
of assembler to work at its best.

I didn't say that they do *not* use assembler, but use it in an
intelligent way. Carmack *prefers* C code to assembler, but knows when
and how to do it in assembler. The "demo coder" style of game programmer
is the kind that writes assembler on a whim, like this incredibly stupid
tutorial I saw recently on http://www.gamedev.net/gamedev.asp where the
author showed how to program a complete DirectX game in assembler.
DUMB!!! The "tricky" parts that could require assembler are all inside
the DirectX libraries anyway!

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

BTW, I cannot get to your home page (math.smsu.edu not found)...

-- 
Pierre Phaneuf
http://ludusdesign.com/