Re: Tools

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

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

netscape is a pig, lots of pixmaps naturally bloat up the xserver, but I have
to disagree about enlightenment. Once I cut down the config files and set it up
in a usable appealing way, E is very light and fast. It's got a couple oopses,
but dr16 seems to be 99% good. E itself isn't the problem, it's the unfortunant
choice of the default theme, which is pixmap heavy. People complain about E
being big and slow, when it's the theme causing X to be big and slow :/

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

hehehe, I played it on my cyrix 120mhz (150+)... it runs about the same speed
with or without the voodooG, but it looks much better with the card. A new
computer is next on my list... by the tiem I get enough saved up, athlons will
probably be reasonably priced and g400's well supported :)

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

I use fbcon, and I don't have a problem changing vc's... If I run an svgalib
program, it will do some damage to that console, but switching to a different
one and back magically fixes. If only they'd glue in s3 support... :)

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

Interesting :) png and jpg loaders would really help SDL's appearance to
potential users, I think... *shrug* :)

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

I got a handful of programs I wrote a while back (when I was very stoned on
codeine after some oral surgery) that are pretty decently commented, and I was
planning on using them in howtos or tutorials, but never got around to it.
They're in http://math.smsu.edu/~br0ke/gamedev/ if you want a good laugh,
mostly really old technlogy (svgalib, emphasis on 320x200x8)

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

hehehe, have you read my tutorials? they suck ass :)

(clip)

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

I've heard horror stories about win2k's attempt at "system administration".
When you get a true multiuser system, there will be issues with administrating.
It's not just a dos box, like win9x... With m$ inflicting this transition, I
expect people will start having an easier time transitioning...?

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

I personally think of redhat as a beginner linux. It candycoats the fun stuff,
but gives you some exposure, and when you're confident, you naturally move on
to a less candycoated distro... (I'm using debian and looking seriously at
trying ROCK...)

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

sorry about the idiom :) (past tense of bite is bit, btw)

(clip)

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

I d'no where the dr peice came in... (anyone knows who dr hook was/is, shaddap,
I don't wanna feel old :)

http://www.voodooextreme.com/ask/askgrand.html#jan3a
some interesting stuff on that q/a forum :)
the toplevel is http://www.voodooextreme.com/ask/askmenu.html, there's some
frames and shtuff

> 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 windows game developers I talk to are generally disgusted by d3d. But my
interest is in opengl so I talk to people who are interested in opengl, so
they're naturally biased :)

>> 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 beleive the driver stores it, I think if you unplugged the joystick and
plugged in a different kind, you'd have to unload and reload the joystick
module?

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

it's definitely a unique beast :) To people who work with networks, the
possibilities are staggering :) at work, I have a p166 that just runs my mail
reader, an old dec dual with scsi for netscape, and I sit infront of a 400mhz
thing :) I run wmmon on a few of my boxes, I get graphical displays of
everything and the only times I have to get up are to get more coffee or use
the restroom. I laugh at my friends who admin small NT lans, they're forever
walking from computer to computer :) Because it does everything through the
network proto, it's slow. But for games, it may be a worthy tradeoff to lose
the network capability for a speed gain... :)

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

I said I beleive they exist, not know they exist :) Plenty of apps have peices
that sit on oss and do the same thing as say esd or alsa... I saw a kernel
module that was basically ttysnoop before. I'd imagine there are plenty of
examples of people getting closer to the kernel or wire than they have to :)

Ok, while I'm kinda sorta talking about drivers and shtuff, if anyone listening
developes drivers or api's or knows ppl who do.. I think it's very important
that the API for all the features should be there, even if driver support is
not. Even if no 3d cards work, we should have the api to do 3d sound in oss or
alsa or whatever. Even if we can't wiggle force feed joysticks, we should have
the API to control the servos in them. If these things aren't supported, we
should probably mark them as not being implimented, but we should have them
there. For once, coders will write their programs to use them so they don't
have to modify crap when the support DOES get there. The second reason is it
tells the hardware guys and driver writers that we HAVE a standard way and we
HAVE the api and all they got to do is plug their hardware into our system and
it magically works. (am I wrong?)

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

I personally feel that assembly is important to learn and never use again. 99%
of the time, the compiler will do a better job of making fast machine code than
the human (given good source). Understanding how the machine works helps you
make appropriate decisions for the C code... bootloaders and mebbe drivers are
a use for occasional asm, just enough to get the job done... :) 

>>         -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]
> 
> BTW, I cannot get to your home page (math.smsu.edu not found)...
> 

my schools uplink fritzed :( I was stuck staring at cvs mozilla compile and not
being able to do anything on the 'net outside of my school :( obviously, it's
back now, but my page sucks.

> -- 
> Pierre Phaneuf
> http://ludusdesign.com/
> 
> ---------------------------------------------------------------------
> 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.