| |
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....
|
| |
Death Demon
Account closed
Registered: Feb 2005
Posts: 68 |
White Flame is pretty much dead on. It sounds like you want to do more 3D processing than simply providing a simplistic 2D graphics (C64 gfx) interface that can be a little bit faster. If you're talking about doing full frustum clipping, you're going to need to rethink things a little bit. Your computation bandwidth needs to be a bit higher than what I'm getting from this post. You'll need to do high enough precision calulations to generate the clip planes based on your viewport. Then you'll need to calculate planar intersections and generate new verteces for polygons that cross the clip planes. Then you'll have to rasterize things. I suppose I would also suggest doing some visibility culling as well so that you don't waste time rasterizing portions of polygons that you aren't going to see.
If you're looking to do full-on 3D in hardware, there's a lot more you'll need to do than what you've described here. And it's not really simple. If you're getting into frustum culling, that sort of implies that you're doing geometry as well. At least some of the area associated with generating the planar equations and doing the clipping would be used in other geometry operations. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
I don't want to do full on 3D in hardware, firstly because I wouldn't know how to and secondly I would never get the project finished. I guess I just want to do the simplest filling in hardware I can without it being completely useless. At first I envisaged the coder having a bitmap in memory filled with wire frames (with the wire frames drawn in the desired colors) and as my hardware draws the screen it fills in the wire frames. Seemed pretty simple but then I thought what about objects only part on the screen? how will my hardware handle that? and now I'm starting to think about what happens when an object is partly in front of another one? Is it possible to just let the coder take care of all this by having there code draw the wire frames which take all this into account and have my hardware just do a simple filling in of the appropriate area (much like the fill on a paint program) or would this be completely useless? |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
Here's some ideas to implement, in increasing complexity:
Fill a horizontal (or vertical, whichever is easier for you to implement) segment with a solid color. Even adding just this will speed up a C64ish 3d program tremendously vs software, you can draw any shape with a software loop of these, and having this would eliminate the programmer having to convert x,y coordinates into pixel memory addresses all the time.
Fill a segment as above, but with clipping done in hardware.
Add a z-buffer, and do depth testing for each pixel on the segment. :)
Try putting a gradient or fill pattern on the segment (depends on your color depth)
Fill a triangle, by drawing (clipped) horizontal segments.
Fill a polygon, given a sorted list of vertices for both the left & right side.
You'd also want rectangle fill & screen clearing in there. Don't know if you want to bother with bitblit and stretchblit, but those are something to consider as well. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Here is a stupid question. Does the vic II chip already have buffering in a sense? I mean in that you can change the bitmap postition (or the character memory position)with just writing to one register as long as you don't have to change whats in the color ram. |
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
Offcourse. Hires bitmap and charset position in memory are controlled via few memory locations. Bitmap can ocupy anyone of 8 blocks of 8Kb of memory (sounds bad :)) charset is the same thing, just the step is 2Kb.
|
| |
PopMilo
Registered: Mar 2004
Posts: 146 |
P.S. And Char screen memory can be set in 1Kb steps...
By the way I like what you are trying to do, keep up the good work!
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
UPDATE ON 3D CCT.
I've settled of the final specs of the cct.
Columns with 256 byte offset
Memory fill (clear)
EOR fill (on screen draw)
2 buffers
16 colors (normal c64 palette, normal 4*8 cell limitations)
The cct has completely changed. I want to make the cct as simple and cheap as possible while including the main features that ppl want. There seemed to be three main features that kept coming up in the discussions, the column formatting, fast memory clear and EOR fill. I want the cct to be simple enough that anyone can buy the parts from an electronics shop and put it together. When the cct is finished I will release the schematic so that anyone who wants to build one (not for profit) can. Also if anyone wants to write some code for the cct might want to have a look at the schematic.
I have given my video ctt the flick, the cct now just uses the vic II and the RAM already inside the C64. In fact the cct will just be a bit of logic between the address and data buss of the C64 and the VIC II. This is a lot simpler. Basically when the VIC goes to get character data from xxxx location the cct jumps in and puts a different address on the buss corresponding to the column address. The memory fill will need address and data placed on the busses and a write signal during the Vic's part of the clock cycle. The EOR fill will use forty bytes and some EOR logic to put the appropriate byte on the data buss to VIC while drawing the screen. The If commodore where thinking about 3D graphics when they designed VIC II they probably would have added these simple features to the vic II but off course Commodore where not thinking about 3D graphics for the C64 back in 1982.
The column address formatting part of the cct is 90% finished.
Anyway, I would be interested to know what anyone thinks of those specs.
|
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
it would have been nice to have line drawing, segment fill...
on the fly eor fill is hardcore :) wont it steal cycles from the cpu ? I mean if the cct fills the screen at each refresh, it would be nice if it wont steal each time cycles. If the case is so I would vote for only once fill in memory, then it wont again steal cycles in each frame. (leaving more time for the cpu to calc the next frame)
it would be also nice to have more than 2 buffers. guess its not much extra work to make it able to use all possible bitmap location. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
yes! EOR-on-the-fly :) that really speeds things up dude! :)
btw, could the cct clear frames in the background? (not stealing cycles from cpu?) if so, the c= only has to give orders to clear the screen, (while the screen clears it can do 3d rotations), when screen is cleared the cpu draws the lines, swaps the buffers and enables EOR-display mode..
real fast. cpu only has to do rotations and line drawing.. neat. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
The memory fill (Screen clear) doesn't use any cpu cycles (except a few to set it up). The VIC has about 10 000 wasted cycles per screen (a bit less with sprites) which will be used by the cct to write to memory. The VIC II doesn't have a W/R output so there are still a couple of things Ive got to work around for this but it should be very doable.
Also there will be a control bit that you can set to make the memory fill only fill the screen memory. In other words it will only fill 200 bytes of each column. So this way if you are clearing a screen there is no time wasted filling the none viewable portions of memory which exist due to the 256 offset of each column (so you can easily clear one buffer per frame). But if you just want to fill a large continuous chunk of memory this will also be possible. But no window fills.
The EOR on the fly (which will also have a control bit to enable it) should be very easy to implement in hardware (that's easy for me to say now, because I havent started designing it yet). It should just be a case of having 40 bytes. At the start of each new screen the forty bytes get cleared. As each byte of character data gets fetched by VIC the cct will intercept it and EOR the data with the corresponding byte for that column, draw that byte on the screen and leave the result in the corresponding byte waiting for the next line. Does that make any sense? will that do what you all mean by EOR fill?
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | ... | 20 - Next |
