www.delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1997/05/19/00:32:04

From: "Green Background Chicken" <green_background_chicken AT happillama DOT demon DOT co DOT uk>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: 640x480 or 320x200?
Date: Mon, 19 May 1997 02:05:43 +0100
Message-ID: <864003457.15451.0.nnrp-1.c2deae5f@news.demon.co.uk>
References: <01bc6120$d9fcc380$82a42499 AT syntaxlogic DOT earthlink DOT net> <19970518 DOT 130000 DOT 7111 DOT 2 DOT fwec AT juno DOT com> <5lnm9c$iel AT news DOT interlog DOT com> <337F711B DOT 5151 AT cornell DOT edu>
NNTP-Posting-Host: happillama.demon.co.uk
Lines: 48
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp

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

I also stand by the slow compile time and slow running time due to crap
optimization, 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. 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.
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).

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

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


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019