| |
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....
|
| |
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?
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
planar is completely useless if you have pixeldepths of 2, 4 or 8 bits per pixel. chunky is the way to go. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
So sounds like bit planes are a big NO. Only choice is between 1 byte per pixel (two banks for one image) or 4bits per pixel (and no need to bank switch). What do you think Graham? Live with the bank switching? how much diffrence would it make?
That brings me to my next question, If I end up going with chunky, the graphics memory will no longer be in columns of 8bits. What is the best way to address graphics data in chunky mode?
We are slowly narrowing the design down, which is good since I have to have a pretty certain idea where the design is heading before I start redesigning the cct.
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
packing as much pixels in a byte as possible is often a good idea. if you access the screen in blocks it doesn't hurt but even helps a bit. for single pixel access ofcourse one byte per pixel is the best solution. |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
chunky 4bit/8bit modes are fine with me. How will be the colors defined?
in these modes the mem layout is not that a big question anymore.pc style linear is as fine as columns, but for some reason Id still vote for columns tho.
bank switching is ok, should be just a tiny problem when coding.
but how much memory will this have ? how about doublebuffer/tripplebuffer?
(how about blitter line drawing?:) |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
How much memory? you will have plenty of banks to switch in and out of the 6510's 64k, well thats if my idea works. I will explain my idea for the memory banking in a post very soon. Triple buffering? not a problem at all - heaps of memory (but 64k max addreasable from 6510 at a time). You can even run code from the graphics cct's memory (when banked in). |
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 20 - Next |
