| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
FASTER 3D GRAPHICS
I've heard it said before that the way the VIC chip addresses memory (8x8 cells) makes it slower fo rendering graphics because of the extra calculations needed. So what way would you have had the Commodore engineers design an alternative addressing mode so that 3D graphics could be calculated quicker? I would realy appreciate your ideas on this. |
|
... 185 posts hidden. Click here to view all posts....
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
row&$f8 => row/8 ofcourse. Silly me... |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Ok, I can see the convertersion of column based to bitmap based.
Still don't fully get how the filler is working, you have the lines in the line buffer, you EOR with bitmap and store in the next row, right? Is the bitmap clear when you start the EOR fill? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Ok, I can see the convertersion of column based to bitmap based.
Still don't fully get how the filler is working, you have the lines in the line buffer, you EOR with bitmap and store in the next row, right? Is the bitmap clear when you start the EOR fill?
No, I'm just tired and lost. Here's the proper example:
.repeat 32,column
lda #0
.repeat 128,row
eor linebuffer+column*128 + row ;column based
sta bitmap+column+(row/8)*320+(row&7) ;bitmap based
.endrep
.endrep
:)
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
ok, thanks.
So portal enigine draws the lines in a 256*128 column based format.
The portal engine then EOR fills it onto a bitmap
Is that right? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: ok, thanks.
So portal enigine draws the lines in a 256*128 column based format.
The portal engine then EOR fills it onto a bitmap
Is that right?
Correct. In two passes for dithering. Even row and odd rows seperatly.
However for a hw-assisted eor-fill I guess you don't have the luxury of having an A-register to use as temp. I.e. each store has to be stateless or?
If that is the case then you must do something similar to
lda linebuffer+row*128+column
eor bitmap+yaddayadda
sta bitmap+yaddayadda+one row down
And the engine must initialize the first row of the bitmap to the init values for the eor-filler (similar to the lda #0).
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
The EOR-filler was to work by:
40 registers (in hardware), lets say they all start with #$00
The 40 bytes are for setting what the first byte will EOR with at the start of each column. This byte will not EOR with every byte of the column but just the first byte and the 40 bytes are used to hold the result of that EOR and then the next.
e.g.
byte for first column first row of bitmap is EOR with register 0, and result is stored in register 0.
byte for first column 2nd row of bitmap is EOR with register 1, and result is stored in register 1.
So on and so on, then VIC starts on next row, excepte registers now have a value in them.
repeat 200 times
screen done. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: The EOR-filler was to work by:
40 registers (in hardware), lets say they all start with #$00
The 40 bytes are for setting what the first byte will EOR with at the start of each column. This byte will not EOR with every byte of the column but just the first byte and the 40 bytes are used to hold the result of that EOR and then the next.
e.g.
byte for first column first row of bitmap is EOR with register 0, and result is stored in register 0.
byte for first column 2nd row of bitmap is EOR with register 1, and result is stored in register 1.
So on and so on, then VIC starts on next row, excepte registers now have a value in them.
repeat 200 times
screen done.
Sounds good. And for dithered filling the engine have to update those registers prior to the second pass. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
do you mean that you need to initialize the registers to specific numbers at the start of the screen draw?
The EOR is taking place as the sceen is drawn.
The memory does not get touched. (EOR fill is done with no cpu cycles!) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: do you mean that you need to initialize the registers to specific numbers at the start of the screen draw?
The EOR is taking place as the sceen is drawn.
The memory does not get touched. (EOR fill is done with no cpu cycles!)
Well, for dithered eor-filling you need to fill the screen in two passes. And the initial state for those registers are most often 0, but for objects partly outside the screen the state can be different.
So if you wanna support dithered eor-filling in one pass directly in the screen refresh you need to remap the addresses so that it uses the first 40 registers during the even 100 rows, then the second 40 registers during the odd 100 rows.
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
ok, so a second set of 40 registers that can be used on every second row would do the trick?
Can you give simple explanation of dithering to me?
I can see the visual effect in the Demo, looks like you get diffrent shades, but how does it do that? |
| Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ... | 20 - Next |
