| |
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....
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
i think the first lda should be inside the eorfill itself. it makes no sense to have to w8 for the correct cycle the chip finished eorfilling one column, and then do a lda, and give the chip orders to start the next column.
it should be made easier -> the chip just has to do the first lda #0 by itself..
|
| |
Oswald
Registered: Apr 2002
Posts: 5026 |
the chip could do an lda #xx itself, at the top of each column |
| |
WVL
Registered: Mar 2002
Posts: 886 |
yes, but also the chip has to do all columns by itself. it takes too much time to tell the chip to eorfill all columns individually. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Alright, so an EOR filler only does vertical lines? It looks like its only one access per cycle so therefore the cct could EOR one byte per cycle (same as byte filler). This should be pretty easy to design and would probably share a lot of common logic with the byte filler; it could possibly even be a mode for the byte filler to run in with a control bit that turns EOR on or off, how does that sound?
About my previous question of weather to go option A (fill 6k per frame) or option B (add in the 30 bad lines and fill 8k per frame). I'm leaning towards option A simply because it's easier to design. This would mean two frames to clear a screen and another two frames to EOR fill (It's important to remember that these fills are at no expense of cpu cycles since they are all done during the video ctt's memory access part of the clock cycle). Ive got know idea of what kind of frames per second we should be aiming for or even what typical frames per second are for C64 with full screen 3D. I really want to know is 4 frames to clear and EOR fill (plus all the normal number of cpu cycles per frame to do what ever it is 3D graphic coders do) going to cut it?
|
| |
WVL
Registered: Mar 2002
Posts: 886 |
idea :
why not do the eor-filling during display of the gfx data? so you can toggle a switch to have a normal display mode, or a eor-type display mode.
i imagine when in eor-display mode, instead of fetching a byte from memory to display it, you eor it with a byte in your internal buffer, and only then draw.
-> saves 2 frames, not? :)
during clearing in the other 2 frames, you should have enough time to calculate and draw nice 3d shapes, so with triple buffering, 25 fps should be possible in that case..
|
| |
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: 886 |
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: 886 |
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. |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 20 - Next |
