| |
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 |
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: 5086 |
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: 899 |
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: 5086 |
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 ? :)
|
| |
WVL
Registered: Mar 2002
Posts: 899 |
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: 5086 |
the chip could do an lda #xx itself, at the top of each column |
| |
WVL
Registered: Mar 2002
Posts: 899 |
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: 899 |
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..
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 20 - Next |
