From: quacci AT vera DOT com (jon) Newsgroups: alt.msdos.programmer,comp.os.msdos.djgpp Subject: Re: 640x480 or 320x200? Date: Tue, 20 May 1997 15:42:38 GMT Organization: Yale University Lines: 72 Message-ID: <3381bd62.1082930@news.cis.yale.edu> References: <01bc6120$d9fcc380$82a42499 AT syntaxlogic DOT earthlink DOT net> <337b1557 DOT 3473841 AT linux DOT compd DOT com> <863909695 DOT 25001 DOT 2 DOT nnrp-3 DOT c2deae5f AT news DOT demon DOT co DOT uk> NNTP-Posting-Host: slip-ppp-node-09.cs.yale.edu To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk On Sat, 17 May 1997 23:53:12 +0100, "Green Background Chicken" wrote: > > >IMO djgpp is much better than anyone lets on. Look at quake for an >>example of just what kind of power you can get out of djgpp. And allegro >>is a really good game library (IMO), it doesn't have everything, and >>isn't portable, yet, but Jlib is portable- DJGPP, X-windows, Linux, DOS-watcom, maybe more. >djgpp is crap, producing huge executables, Two things to say regarding this size misperception: firstly, many people fail to strip debugging info from their finished executables, because they don't know they can. you just need to link with the "-s" option, and executables under 200K will normally end up in the 60k-70k range (an average I tend to get). On top of that, you have all of GCC's optimizing options- more than any other compiler I know of, and you can shrink it up pretty well, if for some reason that is your prime goal. Or make things gigantic. Secondly, people don't tend to realize that part of the price of a 32-bit protected mode compiler is that a certain amount of stuff has to *always* be included in the final executables to give it it's 32-bit, protected-mode extended functionality. *This "stuff" is the same size whether you are compiling a 5 megabyte game or a "Hello World" test program*. It is a simple *addition* of a fixed amount of stuff, not multiplication by some factor.. Fact is, if it really matters to you that a piece of code end up smaller than 60k, then a slower 16-bit non-protected mode executables is what you want. Fair enough. Or maybe it isn't a compiler you want- maybe an assembler would be more the ticket. >wasting drive space with small >files, There is no denying that GPP is big. It is for serious programmers, and if this sort of disk space is a problem (10-40 meg, almost as big as an average game these days), you don't want it. Of course, if someone isn't going beyond "hello world" sorts of applications, you could throw out 70% of those files; you can already download packages for djgpp for small footprint. But then, why not just use Qbasic? When that is what I want, that is what I use. BTW, if you think GPP is big- incredibly, emacs is even bigger. Everything coming from unix is big; I think that is the nature of the beast. In that world, results and functionality are what matter, not cost. >slow to compile things I don't particularly find compile times to be a problem. It is a smart compiler, and doesn't touch what it doesn't need to recompile. Perhaps your style is to make a monolithic file with everything in it- then perhaps it does seem slow. What I do like is absolute control over every aspect of the compile, from optimizing features I see on no other DOS compilers to debugging features that zero in on problems I've often missed in other compilers. > and uses at&t syntax in the crappy assembler. Ever heard of NASM? http://www.dcs.warwick.ac.uk/~jules/nasm1.html >Quake would not have been possible without assembly language, and I bet you >they wrote it in intel format and used a converter on it.... Must have been worth the effort ;)