| |
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....
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
So just use 40 bytes to hold the next EOR for each column, sounds like a better solution. Actually I think thats one of the best ideas so far. Wow 2 frames to clear and EOR, that does sound good. So the C64's memory won't be EOR filled but the display will be, could that be a problem to anyone?
Triple buffer? is that like 8k actual screen image, 8k image being prepared for screen and 8k image being cleared? I'm just trying to get a better understanding of whats going on from the coders perspective.
P.S. Just had an idea, if I made the 40 bytes addressable the coder could write to them before the screen is drawn. You can now EOR each column with whatever byte you want; you could even use interrupts to change the EOR byte at a specific point on the screen. Which brings me to my next question, what are the reasons for changing the EOR byte for different columns anyway?
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
yes. one screen for displaying, one screen for drawing in and one screen for clearing.
about the eor-ing : it's vital you understand that you don't EOR with a fixed byte, but with the next column-byte!
let me give an example :
original data
0000
0011
1100
0000
0000
0000
0011
1100
which after eor-ing like
lda #0
eor column1
sta column1
eor column2
sta column2
will look like
0000
0011
1111
1111
1111
1111
1111
1100
-> the area between the pixels that were set is filled with that specific pattern (11 in this case)
there's no such thing as a specific EOR byte for each column, you just eor the data in memory with the next byte to display, which fills areas for you.
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Yeah, What I wrote wasn't that clear. 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, giving the same result as your example. Something Oswald said earlier sounded like it was desirable to be able to load the first EOR byte at the start of each column, which is what I was talking about. Did I misunderstand what Oswald was saying or is there a reason for doing this? Would this be used for filling in the background or something?
Another question: This kind of filling could be done in hardware for a screen that addresses the graphics data in rows instead of columns (It would just be a flip flop not an EOR) so with this in consideration would it be faster (simpler calculations) to have the screen made up of 200 rows rather then 40 columns?
e.g.
ROW1: byte0 byte1 byte2. . . . . . . . . . byte39
ROW2: byte64 byte65 byte66 . . . . . . . byte103
all the way down to row 200
rather then
ROW1:byte0 byte256 byte 512 . . . . . . . byte 9984
ROW2:byte1 byte257 byte 513 . . . . . . . byte 9985
all the way down to row 200
This is a rather important question and will have a major effect on which way I go with the design so feed back would be very helpful.
Another equally important question: Color information, I could make the screen out of layers of screen, example two screens are seen as one therefore giving 2 bit planes (4 colors). Or I could use 1 byte per pixel (like someone suggested earlier) of course filling would still be done in either option. It's just a question of what option is faster for the coders to do there 3D calculations in. The only problem I see is that with one byte per pixel the screen will have to be drawn a part at a time (or you use 64k for the image, not likely) and sent to the graphics cct, just like each bit plane would be sent individually to the cct.
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
I think column-based memory would be faster.. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
I've been discussing that with the fellows on CBM hacking and they agree with you. It's also a little more memory efficient. I'm also leaning towards bit planes; 1 byte per pixel is going to get messy unless I give the cct it's own memoery that gets banked into C64 memeory map, in this case 1 byte per pixel could be worth doing. Which way would be better for 3D calculations. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
WVL's eor on the fly idea is awesome :)
column based screen is better. (you can adress 8 pixels in one column by one lda/sta using different bitmasks, you need 8 times the code to do that if row based)
"Something Oswald said earlier sounded like it was desirable to be able to load the first EOR byte at the start of each column, which is what I was talking about"
in some cases you might not want the eor filling to be started with 0. being able to choose the value adds some level of variability, and shouldnt be hard to implement imho.
Im against bit planes. Look at the amiga HW, it was something kewl at the start, but later became the biggest bottleneck of fast 3d gfx. IMHO 4 colours ought to be enough 4 everyone :) bitpairs, or simple hires is the fastest solution. Drawing into 2 bitplanes = twice as many write instructions, more adress calculations, etc, etc. Byte based pixels are faster. (you can also forget about lda ora sta, just lda sta, while at 2 bitplanes you do 2x lda ora sta) |
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
oswald, you can eor with any value if you eor the first byte of your buffer with it. you dont need any other initialization than 0. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
It definitely looks like column based screen is the way to go. I thought bitplanes would be OK (If using only 2 or 4 bitplanes) If you want a particular color you just draw the same lines on the appropriate planes, not to much more calculation I wouldn't have thought, especially if clear and fill are being done in hardware.
I'm surprised you bought up bit pairs; I wonder what other people think of using bit pairs and if losing half horizontal resolution would bother them?
If there are enough cells on the CPLD I would like to include both bitplane and byte per pixel (is thee a proper term for this?), I know bitplanes are a bit slower but itÂ’s going to be awkward dealing with a 64000 byte screen on the 64. The only practical way of doing it is switching between two banks while building up the screen with 32k in each bank, is that going to be acceptable?
Filling on a byte per pixel screen would be a bit diffrent (just solid fills of whatever color) and woudn't use EOR but would still be done on the fly.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
great, my post is lost.. anyway
graham: true
stingray:
byte per pixel = chunky mode
writing 2-4 pixels at a time can make the fastest existing lineroutines go 2-3 times slower. thats why I say no to planar.
how about a 4bit/pixel mode ? 2 pixels in a byte ? so the 32000 byte limit is solved.
switching between 2 banks is no problem, if the screen is halved vertically.
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Chunky mode, thanks.
2 Pixels per byte sounds alright, and with chunky mode, the two banks would split the screen vertically.
I guess I could go either way, which way do you think would be fastest for coding with?
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 20 - Next |
