home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / rec / games / programm / 4750 < prev    next >
Encoding:
Text File  |  1992-11-18  |  2.6 KB  |  62 lines
  1. Newsgroups: rec.games.programmer
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!uwm.edu!ux1.cso.uiuc.edu!news.cso.uiuc.edu!uxa.cso.uiuc.edu!jas37876
  3. From: jas37876@uxa.cso.uiuc.edu (John A. Slagel)
  4. Subject: Re: speedup PutBlock
  5. References: <24034@galaxy.ucr.edu>
  6. Message-ID: <BxyFn4.Ktu@news.cso.uiuc.edu>
  7. Sender: usenet@news.cso.uiuc.edu (Net Noise owner)
  8. Organization: University of Illinois at Urbana
  9. Date: Thu, 19 Nov 1992 08:30:39 GMT
  10. Lines: 50
  11.  
  12. blaisdel@ucrengr.ucr.edu (james blaisdell) writes:
  13.  
  14. >however the table lookup is much more flexible and faster, the only
  15. >possible argument against the table look up is that it requires 400 bytes
  16.  
  17.    One point--- If you're using ModeX on a 386, remember this:
  18.    1. The Y-coordinate can be greater than 256.
  19.    2. There are several X-modes that have different resolution.
  20.    3. Most people using ModeX have a 386 or higher.
  21.  
  22.    My point---
  23.    Remember the early-out feature for multiplication on a 386.  If the
  24.    argument to the MUL instruction is small, the multiply routine times
  25.    out, so the MUL takes much less time on a 386.
  26.  
  27.  
  28.    My 2nd point---
  29.    ModeX addressing uses the X-width divided by 4 to multiply by
  30.    to find the pixel offset.  This will always be less than 256, so
  31.    enter the early-out feature on 386s.   
  32.  
  33.    My main point---
  34.    MUL works almost as fast as shifts on a 386 with VGA, but has the
  35.    potential, unlike shifts and adds, to be used across many different
  36.    ModeX resolutions. 
  37.  
  38.    The point of this note--
  39.    Please, please, please, keep code portible between different modes.
  40.    There is *ABSOLUTELY NO SENSE* in writing shift and adds to save 2 or
  41.    3 clock cycles per sprite at the sake of code portability.  Just always
  42.    use the X width divided by 4 as the argument for MUL, and your ModeX
  43.    routines will *NOT* be significantly slower than shifts and adds.
  44.  
  45.    Forgive me for taking a long time to drive a point home.... Its
  46.    just that a lot of people keep saving a few clock cycles per
  47.    sprite on a 386 at the expense of portability.   Figure-- If you
  48.    have 50 sprites miving around, and save 10 clock cycles per sprite,
  49.    you save 500 clock cycles, which is insignificant, compared to the
  50.    delays necessary for page-flipping, collision detecting, Z-sorting,
  51.    etc...
  52.  
  53.  
  54.  
  55.    Think about global, not local, optimizations.
  56.  
  57. -- 
  58. -----------------------------------------------------------------------------
  59.  John A. Slagel              "My old man used to tell me, before he left this
  60.  j-slagel1@uiuc.edu           shitty world, never chase buses or women- you
  61.  (217) 337-7930               always get left behind." -The Marlboro Man
  62.