| 1 | Software r1 implementation. uses span buffers, or draws polygons in the order
|
|---|
| 2 | received.
|
|---|
| 3 |
|
|---|
| 4 | if perspective mapping is enabled (via the R1_PERSPECTIVE_CORRECT flag, r1_api->modify_features)
|
|---|
| 5 | it will automatically draw smaller polygons as affine
|
|---|
| 6 |
|
|---|
| 7 | if any texture mapping is enabled, it will draw REALLY small polygons (<5 pixels I think) as just
|
|---|
| 8 | a solid color. this is primarily to counteract black lines in the terrain where polygons meet, and
|
|---|
| 9 | triangles end up being really tiny
|
|---|
| 10 |
|
|---|
| 11 | lighting uses 2 lookup tables. theoretically, you only need to lookup 3 bytes total per pixel,
|
|---|
| 12 | however due to a lack of registers and the slowness of mixing 16 and 32bit code, the lookups
|
|---|
| 13 | are all 32bit values. further description of the tables is in tint_manage.cc and the simplest
|
|---|
| 14 | lit mapper is in affine_map_lit_c.cc. All of them "dither" the lighting value, meaning that
|
|---|
| 15 | if the lighting value on some line of pixels is 10.5, it will actually alternate between 10 and 11
|
|---|
| 16 | when lighting those pixels.
|
|---|
| 17 |
|
|---|
| 18 | 3 types of alpha are supported.
|
|---|
| 19 | 1) solid color, half alpha. Smoke trails use this. See solid_blend_half_*cc
|
|---|
| 20 | 2) true texture alpha. the texture must be 4-4-4-4. a lookup is performed on the lower 12 bits
|
|---|
| 21 | to get a true 565 (or whatever the screen format is) for that pixel. the screen pixel is read
|
|---|
| 22 | from memory. the 2 pixels are then lit using the lighting table lookups with a properly scaled
|
|---|
| 23 | alpha value, added together, and stored. look at affine_map_unlit_true_alpha_c.cc
|
|---|
| 24 | 3) dithered alpha. uses the same texture format, but skips pixels based on the accumulated alpha
|
|---|
| 25 | value of the scanline
|
|---|
| 26 |
|
|---|
| 27 | aside from alpha and lit texturemapping (perspective and affine), there is one other texturemapping
|
|---|
| 28 | mode supported: "holy" texturemapping - both affine and perspective. The texture format is the
|
|---|
| 29 | same as is used in regular texturemapping, but all texels that are black are skipped
|
|---|
| 30 |
|
|---|
| 31 | lighting, alpha, and holiness are mutually exclusive. if you try to set a mode that isnt supported
|
|---|
| 32 | (for instance, lit alphatextureing) the resulting output is undefined. look at update_tri_function()
|
|---|
| 33 | in r1_software.cc. Thats what evaluates the current "state" of the renderer and chooses the
|
|---|
| 34 | appropriate "type" of polygon that will be drawn. All types are enumerated in mappers.hh.
|
|---|
| 35 |
|
|---|
| 36 | I *THINK* only win32 spefic code is in win32_specific.hh and win32_specific.cc. Of course,
|
|---|
| 37 | the inline assembly in the texturemappers is not portable, and the fpu state management code
|
|---|
| 38 | in inline_fpu.cc is not portable, but otherwise the rest of the code should be.
|
|---|
