Mail Archives: djgpp/1997/05/21/06:32:36
On Mon, 19 May 1997 02:05:43 +0100, "Green Background Chicken"
<green_background_chicken AT happillama DOT demon DOT co DOT uk> wrote:
>
> OK, to set the record straight, the original "djgpp is crap" post was made
>in error, by responding to a cross-posted message in an asm group, I
>certainly wouldn't have posted it here intentionally...
>
>I agree, nasm is great, and that solves the assembly problem nicely- I use
>NASM anyway- it's the best assembler in my opinion for the PC at the
>moment...
>I still stand by djgpp taking up lots of space- a fullish install takes up
>about 100 meg, of which approx. 50% is wasted due to the loads of small
>files and the essence of FAT16.
I just checked mine- 24.9 megabytes. NASCAR2 took up 100. Longbow took
up 100.
> I don't just mean the include files- they
>have to be small and seperate obviously, and I don't just mean the huge
>size of the install, which yes, probably can be brought down to a minimum
>install type option thing, but the plethora of small files. Anyway, Watcom
>C takes up less space in every sense, IMNSHO.
Watcom is definitely a good compiler.
>I also stand by the slow compile time and slow running time due to crap
>optimization
Explain- what aspect of the optimization is crap. I generally consider
GCC as having the best optimization options of any compiler.
>, and cite the case of my 3d demo which runs at 30 something
>fps under djgpp compile, but, changed only to be compatible with watcom c's
>slightly different syntax in various commands, runs at *53* fps.
Comparing Jlib things is handy for this, since the same game library
works with both watcom and DJGPP, and in the one file I remember
looking at compiled with watcom and djgpp, they looked identical. OK,
to me DJGPP looked faster- but this wasn't a pentium-optimized
executable from watcom, and i didn't do an detailed analysis, but it
certainly convinced me that DJGPP was at least good enough to do my
job, and beyond that, had every potential to be everything any of us
ever would dream of in a compiler because it is being developed
endlessly by hordes of input from people here.
To put it another way, given two products that are either equal of
shades apart, the choice comes down to which one you can depend on
more to continue growing and to adapt to it's users. Anything GNU is
going to take that award, in my estimation. Look at linux, emacs, etc.
They all share similar "flaws" in some people's eyes- bloated, too
complex for casual use... but in the end, they all pretty much do more
than anything comparable if you really need to handle "big jobs."
> The reason
>is that djgpp is a straightish port of gcc, which doesn't have pentium
>optimization yet- so no scheduling of floating point and no pairing of
>instructions etc etc, which all makes a big difference in speed in 3d apps.
It is a fair point that the port aspect of djgpp means we get
essentiall something built for the generic world of unix machines, not
just for a single processor. I see that as being dealt with in a
modular way by people here in the DOS world eventually putting
together optimizing features to our "generic" gcc port.
>Yes, you can just use NASM and write the speed critical bits in assembly,
>but in a 3d game, speed critical refers to most of it, and what remains
>could equally be written in any c compiler.
>As to the free nature of djgpp, well yes, ok, but NASM is free too and I
>love that, because I don't love things just because they're free. Also I
>use the c++ libraries, and isn't it the case that things written with
>djgpp's c++ libraries are not allowed to be used commercially without
>licence or something? I read something about it somewhere, once, (goes
>vague).
Not totally clear on what you mean here... but it isn't just that
DJGPP is free- it is GNU, it is, like I said above, it is "of the
people", it is being hammered like gold by thousands of users around
the globe who *have access to the source code* of it, and in the end,
that is how you get the best gold. I consider it a major plus that
already, this "early" in it's development, it already is a great
compiler- but in the long run, I think it is a safe bet that it is
going to adapt very affectively to the various twists and turns,
probably better than any other similar compiler around. And GPP
certainly isn't dying.
>Anyway, YES I do bash djgpp a bit now, but it was excellent when I was
>learning c++, and who cared about speed then? If it ran I was happy! Also I
>did write my first game in the excellent allegro game library for djgpp (My
>balls have dropped) but I felt guilty using Shawn's routines for everything
>because it was, as Darth Vader says "All too easy"...
I know what you mean there. I try to make it a policy to be sure I can
do everything first before I use routines- or if I do use library
routines, I eventually figure out how to do it myself. But then, I
consider the fact that I don't know how to make a compiler, but I use
'em to make my life easier. Heck, I don't know how to make a
generator, but electricity certainly has made my life "all too
easy";-)
>Also a final note to whoever posted the "oh so amusing" multiple-choice
>style flame form in reply to my original post: next time at least fill the
>boxes in correctly: eg I didn't quote the whole original message in my
>post, and I didn't incorrectly punctuate my post etc so get your facts
>straight before trying desperately to be funny...
I didn't see that.
But I will admit that my first response to a "djgpp is crap" post is
a) take my response out of this newsgroup, and b)write something vile
in response! Fortunately, I can withstand such "b)" urges. Because I
absolutely hate the back-biting, flaming that goes on in
rec.games.programmer and the like. One think I really appreciate about
comp.os.msdos.djgpp is the civility of the tone. Let's keep it that
way.
- Raw text -