| |
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. |
|
| |
Oswald
Registered: Apr 2002
Posts: 5020 |
the best would be a column organized screen :) the first 0-199 bytes in a row makes the first char column of the screen, 200-399 the 2nd column, etc
so the upper left byte's addy is 0, the next to it is 200, the next to it is 400, etc.
The way todays speedy linedrawers, plotters, eorfillers,etc works begs for a mode like that.
is this for C= one ? :) will it have a blitter please ? :) |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Thanks for the response Oswald, and no this isn't for C=ONE. I asked because for my final semester project in the advanced diploma course I'm doing I have designed a simple graphics cct for an 8051 micro (not my choice, the project had to be related to 8051). I have been considering adding RAS and CAS refresh and adding Phi1 and Phi2 signals to it so it can be interfaced to a 64. (I've also got some crazy idea where the VIC chip would be mounted on my cct board, my cct could sync it self to the VIC and gate data to it for normal VIC operation giving the 64 the extra graphics mode plus the normal operation). I do plane on at the very least interfacing my cct to a 64 and thought I would ask the question about 3D graphics because I would like my cct to be useful for something.
|
| |
White Flame
Registered: Sep 2002
Posts: 136 |
I'd say an easy speedup would be to make the address offset for each line a power of 2, instead of having to add multiples of 40 or 320 to move down. Either change the horizontal resolution to 256/512/whatever, or pad each line with extra data to fill out the power of 2, and use that padding space for extra sprites/fonts/palettes or something. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
White Flame thats an awesome idea. I had thought about doing something like that when Oswald mentioned doing 40 columns of 200 bytes but only because it's easy for me to redesign my cct doing it that way, I actually didn't think of it being a coding advantage and was going to go down a different path (adding 200 every column then subtracting 7799 at the end of each line or something equally bizarre and difficult). But thats a bonus now that youve pointed out that it's actually a coding advantage. This adds speed and makes my cct simpler (as long as I stick to reading one byte per cycle since now an image would take up 10K out of 16K) |
| |
WVL
Registered: Mar 2002
Posts: 886 |
Even easier would be Oswalds idea, but then on a screen 320 (or any value)*256 pixels (instead of x200).
this way a simple inc/dec of the highbyte of the adress will move you left/right. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
at least none of the 10K would be wasted that way. |
| |
Oswald
Registered: Apr 2002
Posts: 5020 |
wvl: you mean 40byte*256 do u ?:) or do u want a 256 color mode ? :)
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
I'm pretty sure he meant 320 x 256 pixels, anyway I'm trying to keep this simple so there will be no 256 color mode at least at the moment anyway. It's taken considerable time to design the cct i've got and so far it's pretty basic. The more complex I make it the longer it will take for me design it. |
| |
hollowman
Registered: Dec 2001
Posts: 474 |
only 16 colors, but one byte per pixel is fine with me |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
1 byte per pixel would be 64k and my cct will only be addressing 16k like the VIC or are you thinking my cct should have it's own onboard RAM or something? |
... 185 posts hidden. Click here to view all posts....
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 20 - Next |
