| |
Nightlord
Account closed
Registered: Jan 2003
Posts: 131 |
Release id #112378 : Coma Light 13
now that we all had watched this many times, I wanted to ask if the authors can give a bit more info on the technical side of things. The demo has a really entertaining notefile but coders want more detail, so that we know what exactly we need to beat :)
For instance is the shadow casting vector realtime, or the dualpyramid with the 4 circles attached to its vertices. is that realtime?
Thanks again for a great demo.
|
|
... 24 posts hidden. Click here to view all posts....
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
It is an FLI done each second line to force a new charset and screen to be loaded and not to stretch the dithering what would happen on a per line update like with FPP. Also the stuff is interlaced by using two banks. During FLI the z-tab is cleared to have a bit more time for generating a new one and be able to load the next part (Mostly this part was thought for bootstrapping the second side)
The z-effect is done by creating a z-tab, by starting with the deepest z-value and just writing the y-positions from a sine-table (higher z-values by that overwrite lower ones and thus lower parts get automatically hidden). Z thereby determines x-size of the chessboard that is represented via the FLI, as well as what colors that are set for the multicolorcharset (be aware of gray dots, YUCK). So for the white parts of the chessboard colors are changed interleaved, while the blue parts just fade from blue to black (multicol 3 -> colram), as else one would run out of colors.
Basically one can put any bitmap-texture on all that, but there are some caveats with the color-interleaves and horizontal lines that appear very stretched.
That is how the texture looks like before it is split up into 2 line high blocks and converted to the respective charsets + screens:
 |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
checked again the cube shadow, maybe I was thinking too much into it, as the cube and the shadow can intersect heavily, that would cause big headaches with sprite layer tricks.
it's not a huge problem to draw it entirelly either tho. probably axis is being clever the other way round, and only updates what needed & to have the shadow intersected by the chessboard its not much extra stuff having to plot into the eor buffer, you can speedcodize the chessboard lines plotting lda sta sta sta sta style. even pick only the lines that have to be redrawn.
edit: or, setup the eorbuffer with the chessboard lines, then draw/erase the shadow lines with eor, only fill out what needed and done. |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
thanks, I get the chessboard stuff now, it helps a lot also that there are only 100 lines to calculate :) thats a cool cheat as its not visible at all. I guess it wouldnt look 5% nicer if all 200 lines were done. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
It would look uglier with 200 lines, as you'd then stretch the pixels in y-direction what would spoil all the (interlaced) dithering put into that effect, something i really dislike with the FPP effects. Win-win i'd say :-) |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
it is possible to dither correctly 200 lines aswell. just split the Z gfx mapping tables into dither style A (*x*x*) and B (x*x*) and read from A on odd lines from B on even lines. split up GFX similarly, gfx type A is all *x*x and vica versa. |
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Well, should work, but a quite some obstacles connected to that, compared to:
lda $dd00
eor #$02
sta $dd00
per frame :-)
That way you might need to update per line: $d018, $d011, $dd00, $d021, $d022, maybe a bit tight with having badlines only :-)
I'd be very happy to see lots of effects in a better quality, either in hires/ecm or at least properly dithered and maybe even interlaced. So don't hesitate to come up with a hires 200 line version :-) |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
in soiled legacy I've managed to update all those ;), tho cheating like hell, d021/22 is updated on odd/even lines, and there's an lda dd00 in the raster speedcode for each line which is modded to sta dd00 when the checkers needs to be inverted (hint: lowest bit in d018 is unused, the value for d018 can be reused :) needed special drive code so it will not try to interpret all the crazy dd00 writes as input. |
| |
Peiselulli
Registered: Oct 2006
Posts: 81 |
use krill loader and let the upper 6 bits of $dd00 to zero, that works perfect. "SAX" instead of "STA" with X register set to $03 helps a lot here ...
|
| |
Bitbreaker
Registered: Oct 2002
Posts: 508 |
Yeah, a nice feature is that unsued bit, used that trick it in my hires twister in Ächzzeit as well :-) If you want to avoid loader trouble, SAX is your friend, if you can afford wasting one register for that purpose only, that is.
Edit: Urks, Peiselulli was faster :-P |
| |
Oswald
Registered: Apr 2002
Posts: 5095 |
that SAX trick could have been used nice one. btw looked at that code, its even more crazy than I remembered. the raster speedcode has to be all selfmodded, no time to load from tables each lda is lda #$00, also there's only time on each 2nd line to write to dd00 :) |
| Previous - 1 | 2 | 3 | 4 - Next |
