Re: Tools

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

On 07-Jan-2000 Pierre Phaneuf wrote:
> Erik wrote:
> 
>> 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 :/
> 
> Maybe you're right, I'm very happy with Window Maker, as I like the NeXT
> look very much (call me romantic!)...
> 

I use wmaker at work and have my home desktop set up with the gnome panel on
the right side a la wmaker/NeXT :)

> It's not very often that the window manager will take a lot of CPU. But
> using a lot of pixmaps in a theme eats the memory alive and make the
> computer swap, killing performance. To me, it just looks like
> Enlightenment lends itself to overuse of pixmaps very easily... With a
> Pixmap GTK+ theme on top of this, OUCH!
> 

gtk+ 1.4 is supposed to incorperate some changes that will make pixmap themes a
lot faster, I haven't been watching those mailing lists too closely lately
(little interesting stuff, this list is much more fun :)

>> > 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.
> 
> Oops, I meant Quake 3: Arena, by the way! :-)
> 

ahhh, different game :) q3 barely sludges along on this thing, I was playing it
on a p166/48m with a v2 and at a noticable disadvantage to my coworders (all
v3's on 400's with 128m ram)... i was only leading them by a little bit :) One
thing I'd like to say is that my coworkers became very envious of my stability.
They would crash many times a night and I would have no reboots or anything, I
just kept going. My boss was asking a lot of questions about office
productivity stuff, so I got to show him stuff like star office. Unfortunantly
he chickened out, but I may still turn him :)

>> 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 :)
> 
> Hmm, G400 are okay, but trailing in most benchmarks and tests (I look at
> Tom's Hardware and Ars Technica every once in a while). nVidia hardware
> seems to be the best, with TNT2 Ultra and GeForce 256, but Voodoo3
> hardware seems to be the biggest bang for the buck, mostly lacking in
> the visual departments (only 16 bit and picture always look too dark
> with the 3Dfx chipset, dunno why).
> 

I read a couple reviews and comparisons in gaming magazines, and they seem to
indicate that g400's are "ok" speedwise, but offer better visual quality. These
were before geforce256, so I d'no how that compares :) I've talked to people
who have g400's and they say that they run really well on linux. If matrox
would give the "utah" drive ppl the rest of the information, I think that the
millenium cards will be pretty hot under linux :) I still have time to consider
the options, and I will definitly do more research. 

(clip)

>> Interesting :) png and jpg loaders would really help SDL's appearance
to
>> potential users, I think... *shrug* :)
> 
> Take a look at http://www.devolution.com/~slouken/SDL/libraries.html.
> Note that DirectX doesn't support loading of any kind of image format I
> think, no? Maybe BMP thru some Win32 hack, but whatever...
> 
> I like it better that way. I don't need to have a JPEG loader if all I
> use is PNG, it's "pay as you go" instead of one big monolithic library.
> SDL provides the video surface, you provide the content! It's a good,
> clean, separation of work.
> 

Yeah, I see. I guess I feel that bmp was a bad choice :) I see "wav" and "bmp"
in the documentation and I think it's a windows wannabe type thing *shrug* but
everything else indicates a high quality peice of work :/ I guess I'm biased :)

>> 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)
> 
> Hmm, I see... Stoned on codeine, eh? :-)
> 

you betcha :) I remember uncontrollable wobbling and 800 lines of code a
night... (I think 800 is fairly decent for one sitting)

(clip)

> 
> It's not that much beginner (you didn't see Corel Linux, and it shows!),
> it's just so well done. They were among the first to leave the BSD boot
> style and go with rcX.d SysV boot style I think, and it's the kind of
> improvements they have. For example, they use a lot of the "foo.d" style
> to replace a "foo" config file, similar to the "update-modules" script I
> saw on Corel Linux, don't know if it came from Debian or not, but this
> was nifty.
> 

I saw corel :) with it's "insert the cd in windows and click this" install and
everything... :) I used to use redhat, and I personally feel 4.x was their high
point. I got frustrated with their scripts and how flaky rpm was so I switched
to debian. I got into linux in '96 and I always remember it being rc?.d and
sysv-ish.

> What *wasn't* nifty with Corel (Debian also?) was network interfaces
> configuration. All in a single file. With variables, oh, so friendly! I
> like the "ifup" and "ifdown" scripts in Red Hat a lot, if they weren't
> already there, I'd do them myself! See, maybe I'm not a beginner and I
> am rather experienced, but I don't have time to lose on fiddling in
> files when it could *easily* be faster ("easily" as in "without
> compromising my control").
> 

debians got ip-up and ip-down.... I d'no, I never use 'em anyways. I like to
scrap together my own scripts, it's a nominal amount of effort :)

(clip)

>> 
>> 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 :)
> 
> Yes, they could have a bias. :-)
> 
> But anyway, commercial games do get written using D3D, so it is actual
> competition.
> 

Anything that has "MICROSOFT" stamped on it will get used. It's an unfortunant
reality. I've been working a lot with databases lately (mysql and postgresql),
and have had the misfortune of being exposed to access. But access seems fairly
common in smaller business environments (cheaper than oracle, but still a "name
brand"). DX is being used, but I'd imagine most developers aren't happy about
it. I have a suspicion that the programming groups that work as independant
teams use dx as little as possable (sound and interface), while the corporate
drone groups with pointy haired bosses use dx is all it's "glory"... I think
the things we can learn from dx are to use it as an example of what not to
do... :)

(clip)

> 
> Yes, of course, and the beauty is that you can do it, with things like
> XShm, DGA and direct rendering!
> 

these're things I guess I should learn :)

>> 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
>> theyhave to :)
> 
> Ok, maybe a kernel-space ttysnoop could be useful on boxes with a large
> number of terminal or telnet sessions going on, where you'd like to be
> able to provide phone support (ttysnoop has a noticeable overhead, not
> that much, but with 50 or 100 sessions going on, might be a lot).
> 

this was a "hax0r" wannabe who didn't want to be seen spying :/ (renaming
ttysnoop and ttysnoops would have sufficed...)

> How many games I saw had their own separate sound process. I don't think
> this is the best way to do sound in a game (a thread is an improvement,
> but synchronous is the best IMHO), but at least, if you're going to use
> that, use something already existing (like esd)!
> 

hehehe, I plugged in esd support into my game engine for q&d sound, it's
extremely easy to use and seems to be pretty good in terms of memory and speed.
However, there is some sound degradation going on. I have an mp3 player that
can output over oss or esd, but I use oss because it sounds cleaner and retains
the lows... Why I'm saying this, I have no idea. for putting sound into
something quick, esd is very good. And since gnome uses it, gnome desktops get
the benefit of real mixing, which is something I personally think should be
kernel level.. (does also do mixing? someone mentioned alsa and the kernel)

> 
> Yes, knowing assembler is important, and even with todays compilers,
> sometimes you have to use assembler. For example, we have a sound mixer
> for Quadra (no threads, no sound server process, doesn't skip or lag!)
> that adds the samples together and then uses if's and whatever to
> properly clip it. This is a good case that could be replaced with
> assembler. I think MMX has such a bounded add, and if not, I could
> simply do an add and a jump on carry to replace the if's, that would be
> much more efficient (considering this is kind of an "audio alpha
> blending blitter", moving a few megs per second of data)... Turned out
> okay without it (Quadra is a simple game), but maybe it would help my
> 486 if I did it.
> 

I don't think you should learn assembly to use it occasionally... I really
doubt there's a serious need. I think asm is important to learn so you
understand why x++ is better than x=x+1 (unless the compiler optimizes that for
you...). And stuff like loops... having an idea of how that gets handled by the
machine lets you make your programs more friendly to the machine. (but we still
need skilled asm hackers to glue together the compilers so they use mmx and
3dnow and superdoopermegahyperglobalultra4324252 instructions... :)

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