home *** CD-ROM | disk | FTP | other *** search
/ Acorn User 7 / AU_CD7.iso / _movies / _armovie / documents / paintrouts < prev    next >
Text File  |  1998-04-09  |  7KB  |  119 lines
  1.          Just How Many Paint Routines Are There?
  2.          ---------------------------------------
  3.  
  4. Replay has lots of paint routines. Indeed, it makes life a little worse for
  5. itself by providing routines for decompressors which produce <=8bpp (both
  6. colour mapped by painter and colour mapped by decompressor), ones which produce
  7. <=16bpp (both colour mapped by painter and colour mapped by decompressor) and
  8. the 'normal' ones which produce 32bpp (both colour mapped by painter and by
  9. decompressor, though painter support is only provided for 4:2:2 input). But
  10. basically it has a routine for each interesting screen mode - and this isn't
  11. all the modes which a RiscPC is capable of. Replay limits itself to providing
  12. simple pixel magnifications: 1x1, 2x2, 2x1, 1x2, 2x4 in simple modes. In 16bpp
  13. modes, scaling by 3:1x1, 3:2x3:2, 4:3x1, 5:3x1, 5:4x1, 5:4x5:4, 7:4x1 are also
  14. supported. In 32bpp modes, x scaling by eights between 7:8 and 15:8 and by
  15. sixths between 7:6 and 11:6 are also supported (over 16bpp's scaling). y
  16. scaling is produced either by dedicated drivers, or by using a y scale by 1
  17. painter (which is less efficient). This would lead to quite enough drivers!
  18. However there are also interpolated versions of some of the drivers - Replay is
  19. capable of doing horizontal only interpolation, or of doing both horizontal and
  20. vertical interpolation in 16bpp and 32bpp output modes (but only for some x and
  21. y scaling combinations). And there are special undithered drivers for 8 and 16
  22. bit per pixel modes. There are a LOT of drivers:
  23.  
  24. depth/mag:
  25. -----
  26.   1                    1x1       2x1, 2x2
  27.   2                    1x1,      2x1, 2x2
  28.   4                    1x1,      2x1, 2x2
  29.   8                    1x1, 1x2, 2x1, 2x2, 2x4
  30.   8 undithered                        2x2
  31.  16                    1x1, 1x2, 2x1, 2x2, 2x4, 3:2x1, 3:2x3:2, 5:4x1, 5:4x5:4
  32.                                                 7:4x1, 4:3x1,   5:3x1
  33.  16 undithered              1x2, 2x1, 2x2, 2x4, 3:2x1, 3:2x3:2, 5:4x1, 5:4x5:4
  34.                                                 7:4x1, 4:3x1,   5:3x1
  35.  16 horiz interp                 2x1, 2x2, 2x4, 3:2x1, 3:2x3:2, 5:4x1, 5:4x5:4
  36.                                                 7:4x1, 4:3x1,   5:3x1
  37.  16 horiz/vert interp                 2x2, 2x4,        3:2x3:2
  38.  32                    1x1, 1x2, 2x1, 2x2, 2x4, 3:2x1, 3:2x3:2, 5:4x1, 5:4x5:4
  39.                        7:4x1, 7:6x1, 8:6x1, 9:6x1, 10:6x1, 11:6x1, 7:8x1, 9:8x1,
  40.                        11:8x1, 13:8x1, 15:8x1
  41.  32 horiz interp                 2x1, 2x2, 2x4, 3:2x1, 3:2x3:2, 5:4x1, 5:4x5:4
  42.                        7:4x1, 7:6x1, 8:6x1, 9:6x1, 10:6x1, 11:6x1, 7:8x1, 9:8x1,
  43.                        11:8x1, 13:8x1, 15:8x1
  44.  32 horiz/vert interp                 2x2, 2x4,        3:2x3:2
  45.  
  46. There are 80 drivers. Since this is greater than the filecore directory limit
  47. up to RISC OS 3.7x, the 32bpp drivers are stored in their own subdirectory
  48. "d32". Each set of paint routines for a screen mode, interpolation and
  49. magnification state is stored in a file (in MovingLine.PaintCode) whose name
  50. represents the above information - for example the routine 'd322xI2y' is 'depth
  51. 32 bits per pixel, 2 times magnification in x direction by interpolation, 2
  52. times magnification in y direction by replication'. In order to restrict the
  53. name length, the 3:2 and 5:4 scale names are d323/2x1y for 3:2x1 and d323/2xy
  54. for 3:2x3:2 (instead of d323/2x3/2y). (The undithered drivers for 16 bits per
  55. pixel are stored in the normal d162x2y (etc) files and accessed via szmul%=2,
  56. paintmap% FALSE (a normally invalid combination for 32 bits of output),
  57. similarly the extra undithered driver for 8 bits per pixel is in d82x2y) The
  58. code is assembled at run time and can thus contain explicit knowledge of screen
  59. mode dependent variables such as the number of bytes per line on the screen -
  60. due to an extreme shortage of registers this gets compiled into ADD immediate
  61. instructions in some routines (the x4 vertical ones). The bilinear
  62. interpolating drivers also end up compiling the source movie x size (in order
  63. to access successive lines of the source) into the code.
  64.  
  65. In the file procedure PROCd has a set of routines to paint consecutive pixels
  66. in a row, called to assemble code at runtime. The variable szmul% is 1, 2 or 4
  67. depending on the size of values coming from the decompressor. The variable
  68. paintmap% is FALSE or TRUE to indicate that the painter should do the colour
  69. conversion using r14 as the base register for the colour table and FNplook(,,)
  70. to compile the colour lookup. The variable incno% is how many pixels got
  71. painted - by default 8 - by the routine (a few routines can only manage to do 4
  72. pixels, a few routines check to see if they can do 16 pixels). The procedure
  73. FNplook(dest,src,base reg=14) can be used to lookup pixels in the szmul%=1
  74. case. The constant rowbytes% is how many bytes in a RISC OS screen row. The
  75. procedure FNaddmacro(dest,src,offset) can be used to add values which do not
  76. necessarily fit in an immediate constant (such as the value of rowbytes%!). The
  77. variable slow% can be used to limit just how expensive some operations are (for
  78. example, failing to paint all the lines in the 2x4 case!). r0 is the base of
  79. the decompressed frame, r2 is the output for alternate lines (if the
  80. magnification in the y direction is more than 1), r11 is the output for normal
  81. lines, r14 is the colour map base register when paintmap% is true and is free
  82. otherwise, r3 is in use, r13 is a stack (so the painting algorithm usually uses
  83. r1, r4, r5, r6, r7, r8, r9, r10, r12). r12 is preloaded to &ff for szmul%=1 and
  84. to &ffff0000 for szmul%=2, but can be overwritten. Changing the default of 8
  85. and any initial constants are set up with PROCsetinc. Additional procedures
  86. PROCdr8, PROCdr7, PROCdr6, PROCdr5, PROCdr4, PROCdr3, PROCdr2, PROCdr1 allow
  87. for a potential accuracy of 1 source pixel. If the default is larger than 8
  88. (e.g. 16), then PROCdr8 is used to paint multiples of 8. For interpolating
  89. painters, PROCd and PROCdr<incno> will both be used so as to get the right hand
  90. edge correct (so its expected that you'll have PROCd which does 8 and PROCdr8
  91. in an interpolating painter). At some point PROCdlN may exist.
  92.  
  93. PROCs2al has a set of routines to paint two adjacent pixels into a word aligned
  94. destination. Registers:
  95.  
  96. r0: frame base
  97. r1: destination
  98. r2: shape list
  99. r3: number to move-1
  100. r4: destination second row
  101. r5: pixel
  102. r6: second pixel
  103. r7:
  104. r8: &ffff
  105. r9:
  106. r10:
  107. r11: screen start
  108. r12: pixel translation table for source=bytes?
  109.  
  110. PROCs2unal does the same for unaligned destination.
  111.  
  112. PROCs1 paints just one pixel into a destination of unknown alignment. The pixel
  113. is in r5.
  114.  
  115. Paint routines are not necessarily called for every frame in the decompressed
  116. movie (its that slow% variable again, folks!). If the computer can't cope with
  117. painting a frame exactly on time (network packet, disc IO interrupts etc) then
  118. a frame (or more) maybe skipped.
  119.