Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!rice!cimbria.rice.edu!cliffc From: cliffc@cimbria.rice.edu (Cliff Click) Newsgroups: comp.arch Subject: Re: Mario Bothers Message-ID: <9926@brazos.Rice.edu> Date: 17 Jul 90 19:22:46 GMT References: <2767@awdprime.UUCP> <64280@sgi.sgi.com> <2779@awdprime.UUCP> Sender: root@rice.edu Organization: Rice University, Houston Lines: 35 In article <2779@awdprime.UUCP> tif@doorstop.austin.ibm.com (Paul Chamberlain) writes: >In article <64280@sgi.sgi.com> bron@bronze.wpd.sgi.com (Bron Campbell Nelson) writes: >>And you'd be dead wrong. Video game software is some of the ugliest >>and most arcane assembler there is. > >(I won't include my quote since it's embarassingly unfounded.) > >Really? Is that changing? I am seeing more and more of the popular >games very accurately duplicated on radically different hardware (at >least I assume that these game systems use different hardware). Do >they rewrite it completely? I've worked on a few such games. Some of the games are very well written in a HLL, with a few assembler routines to hack out such stuff as graphics, timer & other interrupt handling, sound, keyboard, mouse, etc. In short, many games do port fairly well, especially on the "beefier" machines like a Mac, PC with 512K, Amiga, etc. Games that ALSO go to the Apple II or Commadore 64 take a machine-specific "guru" to write much of the stuff in assembler. Some of the more spectacular effects are changed/removed when you go from machine to machine (sound on an Amiga is of a completely different sort than sound on a PC). On the flip side of the coin, I made some routines to do a rasterized polygon fill on the IBM PC; the polygons were disjoint, degenerate, and fell partially outside the screen area. Naturally the display update was the slowest part of the code, and I desperately needed speed on a 4.77 8088 - so the assembler there is of the worst sort; unrolled loops, self-modifing code, the whole 9 yards. Cliff Code Rot Click -- Cliff Click cliffc@owlnet.rice.edu