Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!rochester!bbn!uwmcsd1!marque!gryphon!crash!pnet01!haitex
From: haitex@pnet01.UUCP
Newsgroups: comp.sys.amiga
Subject: Re: How do I read the Joysticks?
Message-ID: <2077@crash.cts.com>
Date: Thu, 3-Dec-87 12:36:08 EST
Article-I.D.: crash.2077
Posted: Thu Dec  3 12:36:08 1987
Date-Received: Sun, 6-Dec-87 21:19:06 EST
Sender: news@crash.cts.com
Organization: People-Net [pnet01], El Cajon, CA
Lines: 50

karl@sugar.UUCP (Karl Lehenbauer) writes:
>It is widely agreed, from much study of code, that 5% of one's code is
>responsible for 95% of the execution time.  It would be a bummer to discover
>that your hacked out, badly behaved joystick code made no significant
>improvement in the performance of your game because all the major time was
>being burned in some other part of your program.  Further, you presumably
>could have used the time spent writing the fast joystick code more
>effectively by instead identifying and speeding up that critical 5%,
>leaving you with a faster game that doesn't break with new releases of
>the operating system.
>-- 

	Please understand that I am NOT in favor of bypassing the Device
      Driver.  However, I could not get it to work reliably for me.  Now
      that I have the Bob Burns' article I will (when time permits) go
      back and try to re-write my routines.
        Have you written code that writes to pin 5 of the joystick port?
      From interrupts?  I suspect that it is possible to use the Device
      Driver to do this, but my attempts failed.  The time that I wasted
      were the hours spent trying to use the Device Driver, not the half
      hour it took me to write my own driver based upon data readily 
      available in the appendix of the hardware manule.
      
        Also, your figures regaurding how processing time is distrubuted
      are based upon the average program, most of which are not really
      optimised for speed, many not being optimised in any way at all.
      If you were to limit your study to real-time programs I think you
      would find the numbers very different.  
        Over the last few weeks, in the discussion of M2Amiga's linker and
      how it does not use interface code ("stubs") to make calls to the 
      ROM routines, people seemed to feel that the speed savings are
      negligable because the interface code represents a relatively small
      amount of the called routines total execution time.  However, I call 
      some of these routines VERY many times to generate a display.  If the
      stub requires only 3 instruction cycles, this could mean hundreds of
      cycles in a given display generation.  
      
        In general, I feel that using High Level access to the hardware is
      worth added access time, within reason.  However, THIS IS A GRAPHICS
      PROCESSING MACHINE, and to generate animated displays requires great
      attention to speed at all times!
      
						Thanks,
						
							Wade.


UUCP: {cbosgd, hplabs!hp-sdd, sdcsvax, nosc}!crash!pnet01!haitex
ARPA: crash!pnet01!haitex@nosc.mil
INET: haitex@pnet01.CTS.COM