| |
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 |
I'ts a good idea and certainly would save some calculations. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
i mean 320x256 pixels :)
|
| |
MagerValp
Registered: Dec 2001
Posts: 1078 |
Yes, the C1 has a blitter.
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
While trying to keep it simple, I have had an idea that should be easy to add to the design but not knowing much at all about 3d graphics I would like to know if it's worth including? My idea is to use either the V-blank area or the raster lines above and below the bitmap to move memory around while the graphics cct doesn't really have to be accessing memory anyway. To transfer 1 byte will take 2 clock cycles, 63 cycles per line minus 5 for refresh so thats 29 bytes per raster line. If I use just V-blank area (28 lines) it could transfer 812 bytes which would probably be reduced to 512 or 768 when put into my design. If I use all the raster lines above and below the image (minus the 4 lines I might need for ram access depending on the design) it could do 3132 bytes which would reduce down to 3072 (3k) when put into design. Using all the area above and below the display will give better results but may restrict me with some future enhancements I may whish to make to the circuit. This would actually be pretty simple to add to the design, I'm thinking a couple of addressable latches for writing the transfer pointers to (these are the bytes the programmer would write to), one latch for the cct to read to and write from (this holds the byte being transferred) and a n-bit ripple counter. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
instead of trying to make a blitter, you could rather add an option to have it clear memory. Clearing the gfx screen will CERTAINLY speed up 3d gfx a lot!
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Thats not a bad idea, it would be almost as easy to make it fill a segment of memory with any byte including #$00, if that would be better? So you think this clear/fill thing would be better for 3D speed then data transfer? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
yep, awesome idea from wvl. how about adding an eorfiller aswell? thats another bottleneck of 3d gfx, and should be plain ass simple to realize. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
OK, data transfer is out and filler is in. I have two options with the filler.
A: Only fill 6K per frame
B: Add 30 badlines and steal about 1500 cpu cycles/frame
I don't plan on having any badlines for normal graphics access (at least not at the moment). If I did go for option B, the badlines would only be switched on for frames when filling was being carried out. Option A is simpler to design but is clearing 6k per frame acceptable?
Oswald, this could be a stupid question (I know next to nothing about 3D graphics) but do you mean for example- EOR 3K of memory with byte #$80? If so this would take 2 cycles per byte meaning 3 frames to EOR 8k using option A or 2 frames using option B. Is this good enough? You wouldn't be able to byte fill on the same frame you EOR fill (that would be pointless anyway, wouldn't it?). Just wondering, what would be more useful if I had to decide between one or the other, Byte fill or EOR fill?
I know I have asked a lot of questions and you fellows have helped me out heaps. I am starting to get an idea of what the spec will be. I must stress that this cct will be VERY low spec (at least for now), no frills at all, just quicker for 3D.
|
| |
WVL
Registered: Mar 2002
Posts: 902 |
What Oswald means is this :
lda column0
eor column1
sta column1
eor column2
sta column2
etc
eor column199
sta column199
if you run a routine like that, you only have to draw 2 pixels in a column to have it fill the lot.
the first pixel turns the pixel in the accumulator on, the 2nd pixel turns it off again => you filled a column, and pretty fast aswell!
eorfill and simple clearing will MAJOR speed things up.
ofcourse you need at least 2 banks for gfx.
edit :
even better is that it saves heaps of memory ;) a lot of coders have an eorfiller and normal filler like this unlooped in memory! Also note i only once did 3d graphics and very lousy at that.. dont take my word for anything ;) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
wvl: to be more precise:
lda 0
eor 1
sta 1
eor 2
sta 2
...
eor 199
sta 199
column #2:
lda 200
eor 201
sta 201
...
eor 399
sta 399
IMHO the lda at the top of the columns negligable, and the circuit can do just eor sta eor sta.. if the design is simpler that way. OR the lda might be replaced to load the accu with a fixed value. (preferably a choicable value).
How hard it would be to implement lines ? :)
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 20 - Next |
