home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / sys / amiga / programm / 13389 < prev    next >
Encoding:
Internet Message Format  |  1992-09-15  |  8.1 KB
  1. Path: sparky!uunet!mcsun!uknet!cf-cm!csisles!carter
  2. From: carter@CompSci.Bristol.AC.UK (David Carter)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Various Questions about Fast 3d Vector Graphics
  5. Message-ID: <2289@csisles.Bristol.AC.UK>
  6. Date: 15 Sep 92 15:48:34 GMT
  7. Reply-To: carter@CompSci.Bristol.AC.UK (David Carter)
  8. Organization: Dept of Computer Science, University of Bristol, UK.
  9. Lines: 163
  10.  
  11. Hi there everyone,
  12.  
  13.    Recently, I have taken to playing around with Vector Graphics a la
  14. Elite for a little light relief. Having got the maths, clipping and polygon
  15. filling nicely optimised (using a mixture of C and assembler), I determined
  16. that a major overhead was the MakeVPort()/MrgCop()/LoadView() mechanism that
  17. I was using to double-buffer. (As recommended in the RKM)
  18.    Experimenting, I built my own copper lists, one for each 320x256x4 bitmap
  19. allocated, and did the switching myself by strobing the `cop1lc' register.
  20. This gave me very smooth animation indeed (it jumped from maybe 4 frames a
  21. second to no visible stutter, a pleasant surprise for me).
  22.  
  23.    I have a number of questions, mostly related to shutting down Intuition in
  24. a friendly manner. At least friendly enough that I can get back to my debugger,
  25. and find out what happened...
  26.  
  27.  
  28.    While all my double buffering works very nicely, I can't convince the
  29. machine to rebuilt the sodding Intuition display for me when my program
  30. is cleaning up to exit. I have tried the following methods, in decreasing
  31. order of desirability:
  32.  
  33.   a) LoadView(GfxBase->ActiView).
  34.         (in both C and Assembler)
  35.  
  36.    b) RethinkDisplay()
  37.  
  38.    c) RemakeDisplay()
  39.  
  40.    The Libraries and Devices Manual (sort of) infers that LoadView does any
  41. required poking to get Intuitions own cprlists installed and running. The
  42. effects that I get are as if the LoadView has been ignored - the last copper
  43. list that I myself installed carries on running, as if nothing had happened
  44. Do I have to dig around in GfxBase to find a copper list ptr, and install
  45. manually?
  46.    Other effects that I get vary between invocations (probably because of
  47. my own hacking around, trying to get it to work):
  48.  
  49. a) On occasions, typing a command (e.g dir) will flash the hard disk, so I
  50.    assume that the CLI, indeed the whole O/S is still functioning, even if
  51.    I cannot see it in action
  52.  
  53.    Does anyone have tips on debugging cprLists, when you can't see the
  54.    screen :=).
  55.  
  56. b) On other occasions, nothing happens [An invisible GURU?]
  57.  
  58. c) The third, and by far the most entertaining alternative, is on occasions
  59.    that I succeed in running a program that opens its own screen, such as the
  60.    debugger that I use, PowerVisor (highly recommended, apart from the lack
  61.    of scrollbars...) In this case, the application starts up and runs quite
  62.    happily, with the minor caveat that all the characters are weirdly
  63.    magnified, and overlapping, in a display of (I guess) 20 by 10 characters.
  64.  
  65.    I can't even see how I pull this last trick off, it seems to involve
  66.    hardware undocumented in my manuals [" bitplane fetch rate"?].
  67.    (And I am running with the original, not ECS chipset!)
  68.  
  69. Extra details:
  70.  
  71.    I know that DMA and interrupts are set up correctly, if only because
  72. I avoid playing with them at all while debugging. And DMouse carries on
  73. working quite happily in the background afterwards...
  74.  
  75.    While debugging, I have tried stripping my program down to a minimal
  76. single buffered copperlist, that is $FFFF, $FFFE - "WAIT ($FF,$FE), I hope.
  77. This only gives me option (b) above - no identifiable behaviour at all.
  78. The real copper lists that I use set up all bitplane pointers, colour
  79. registers and display registers: DIWSTRT,DIWEND etc. I know that this is
  80. a bit overkill for a dedicated display, but I *know* that it works, and
  81. guarantees that a whole display appears with a single poke to `cop1lc'.
  82. Get it working first, then optimise. And Intuitions 'View's do a lot more
  83. work than this anyway...
  84.  
  85.    If I comment out the "move.l d0,cop1lc(a0)" instruction in my program,
  86. if runs quite happily to termination, so I know that the copper list, or
  87. maybe the way that I install it (as WAIT ($FF,$FE) is just a *little* minimal),
  88. is the problem.
  89.  
  90.    I sincerely hope that someone comes up with a "don't be silly, you have to
  91. do *this* response", as the alternative is some really nasty bug in my minimal
  92. test code (or maybe my equally minimal understanding). Unfortunately, while
  93. the RKMs document the copper hardware well, and the View mechanism well, the
  94. intersection is non-existent.
  95.  
  96. Other questions, less involved:
  97.  
  98.    As the hardware itself reloads the copper `PC' from cop1ch for each frame,
  99. what is the benifit of strobing the cop1jmp register. Surely I don't want
  100. the list to start running until the next frame. Especially as the WAIT
  101. copper instruction cannot be adapted to "wait until *above* such and such
  102. a position".
  103.    With regard to my RethinkDisplay problems above, I have tried it with and
  104. without the cop1jmp strobe, and also tried a cop1lch/cop1jmp pair installed
  105. into the VBLANK handler. The effects are the same in all cases.
  106.  
  107.    A question on the philosophy of double buffering. With 3d graphics, I want
  108. to go to work on the next frame, as soon as the previous frame has been
  109. calculated. The problem is that the new "scratch" framebuffer is still being
  110. displayed, so if I clear it/write to it immediately, I get visible flicker.
  111. I can think of two solutions to this problem:
  112.  
  113. 1. Wait until the "new" framebuffer has been fully displayed, before switching
  114.    displays and writing to it. The problem is that this gives me
  115.    *significant* slowdown, even if I do all the maths while waiting. I did
  116.    say that my routines where chugging along at a fair rate of knots...
  117.  
  118. 2. *Triple* buffering:
  119.       a) Frame currently being written to
  120.       b) Frame currently being displayed
  121.       c) Frame that will be displayed after next VBLANK.
  122.            [Will be the same as (b) unless we are calculating faster than
  123.             25(?)/50 frames a second]
  124.  
  125.    Problem: 3 lots of 320x256x4 bitmaps is an awful of of memory to
  126.    AllocMem(...,MEMF_CHIP). Especially with only 512K chip RAM.
  127.  
  128.    Do any of you speed demons out there have any better solutions?
  129.  
  130.    On a totally different theme, I assume that mouse and keyboard input is
  131. gathered during the VBLANK interrupt. My debugger claims that a vanilla system
  132. has no exec-based vblank interrupts installed [apart from my own]. Question:
  133. how does keyboard and mouse information get to `keyboard.device' and
  134. `gameport.device' - I assume by behind the scenes interaction with the
  135. exec VBLANK handler. Does this interaction have a low enough overhead to
  136. justify me using these two device drivers during high speed animation? The
  137. alternative would seem to be to trash the 68000 interrupt vector and do
  138. everything myself, but that is *definitely* O/S unfriendly, even if I restore
  139. all vectors.
  140.    Which interrupts does the O/S itself need to keep running? I can happily
  141. switch off ALL interrupts, and switch back on only the ones that I require
  142. (currently VBLANK only), restoring the state of the world later, but it is nice
  143. to know these things.
  144.  
  145.    Finally, a DMA related question. What *does* bit 9 of the DMACON register
  146. do? My RKM would have me believe that is a "Master Control bit", that when
  147. set performs the set or clear operation on all DMA channels.
  148.  
  149. Example:  (From memory, so probably wrong)
  150.  
  151.     move.w  #($0200),dmacon(a0)   ; Switch off all DMA, using "MASTER" bit
  152.     move.w  #($81ff),dmacon(a0)   ; Switch back on through individual bits
  153.  
  154.    I think that this should have "no" effect, what actually happens is that
  155. I lose my display [BitPlane DMA switched off ?]. If I change the second
  156. "magic value" to $83ff, it works. Certainly, the copper example given in
  157. the RKM uses a value of $8380 to switch on copper and bitplane DMA. Three
  158. bits to set two up 2 DMA channels? Should I just read this as "set bit 9
  159. to play with DMA control at all"?
  160.  
  161. Setup:
  162.  
  163.    Ancient old A500 (original chipset), A590, 3MB RAM (1/2 Meg chip)
  164.       - Workbench 2.05
  165.  
  166.    I am using the original 1.1 RKMS (apart from a 1.3 Includes and AutoDocs),
  167. which I am hope are backwardly compatible, at least as far as the hardware is
  168. concerned.
  169.  
  170.    Thanks in advance for any help that you can give.
  171.  
  172. Dave
  173.    
  174.