home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / sys / atari / st / 18902 < prev    next >
Encoding:
Internet Message Format  |  1992-12-24  |  3.3 KB
  1. Path: sparky!uunet!mcsun!julienas!loria!loria.fr!eker
  2. From: eker@loria.fr (Steven Eker)
  3. Newsgroups: comp.sys.atari.st
  4. Subject: Re: Apology:  True Colour *IS* great for games.
  5. Message-ID: <711@muller.loria.fr>
  6. Date: 24 Dec 92 15:51:38 GMT
  7. References: <11490@uqcspe.cs.uq.oz.au> <1992Dec24.053556.20186@leland.Stanford.EDU>
  8. Sender: news@news.loria.fr
  9. Organization: CRIN (CNRS) Nancy - INRIA Lorraine
  10. Lines: 54
  11.  
  12. In article <1992Dec24.053556.20186@leland.Stanford.EDU>, geomorph@leland.Stanford.EDU (Bayard Wenzel) writes:
  13. |> Another nifty thing about TRUE COLOR Mode is that when writing complex computer
  14. |> generated screens in real time, like the 3D projections of a flight sim., you
  15. |> do not have to go through all the palette registers to find the closest RGB
  16. |> match to the color you want to display. This looking up can take a lot of time,
  17.  
  18. Not if you choose the positions of your colours in the palette to work for you
  19. rather than against you - with smart allocation scheme it can be faster.
  20.  
  21. |> specially when the comp. gen.'d screen has many colors, i.e. gouraud shaded
  22. |> polygons (now some people qill say "Wait a minute! You can't generate g. shaded
  23. |> polygons in real time! can you?" well think again. Simple gouraud shading is
  24. |> not too time consuming.
  25.  
  26. The good thing about true color is that it is 1word/pixel layout in memory
  27. rather than interleaved bit planes. Thus you can set the colour of a pixel
  28. with 1 access rather than 16. With flat shading this isn't so important since you
  29. can write 16 consectutive pixels with the same colour. With gouraud shading the
  30. value of each pixel is calculated individually and it makes a big difference.
  31.  
  32. 256 colour palette with 1byte/pixel would be much faster for shading and texture
  33. mapping but unfortunately 256 color modes use interleaved bit planes on the
  34. falcon.
  35.  
  36. It _might_ be possible to do real time gouraud shading and even texture mapping
  37. in true color mode if the bus is fast/smart enough.
  38.  
  39. |> especially with a DSP. Look at the latest flight sims
  40. |> for the PC line for some impressive example of this. And those things have slow
  41. |> buses too!). What this all means is that TRUE COLOR Mode will not only look
  42. |> better but it may also perform faster than 256 color mode when using this kind
  43. |> of graphics!
  44.  
  45. The DSP<->main memory bus is unlikely to be fast enough for the DSP to do shading.
  46. The trick is to have the DSP do all the 3D/lighting calculations/facet
  47. sorting/clipping at polygon level so that the 68030 can spend ~90% of its
  48. time rendering polygons
  49. - ideally with a tight (<=128 byte) inner loop so that it gets most of its
  50. instructions from cache to avoid bus contention.
  51.  
  52. Suppose 6byte/vertex (16bit x, y, color) and average of 6 vertices/polygon.
  53. At 30fps with say 500 polygons on screen we need ~540K/s DSP->main memory.
  54. Assuming the world is stored in DSP RAM the main memory->DSP transfers will
  55. only contain position updates for moving objects. Just about doable...
  56. but only just.
  57.  
  58. Its the speed of the 68030 and the 68030<->main memory bandwidth that worries me.
  59. Even with the best algorithms and coding tricks I doubt you can render even a
  60. small gouraud polygon in ~300 instructions... but maybe its possible to find
  61. a neat way of preprocessing the polygon on the DSP (eg y-sorting verticies,
  62. precomputing Bresenham increments for each edge) to speed things up; or do
  63. something clever with the blitter.
  64.  
  65. Steven
  66.