| |
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 |
That's what buffering the frame is, correct. Double buffering is the name given to using two buffers. Triple uses three, and so on. Front buffer is the one that's being displayed on screen, back buffer is the one that's being written to.
Your best bet is to go with what you got. It sounds like you've thought the system through. You can build it and start to see some drawbacks, things you would like to have done better. If you could model the system in C (write a software representation of what you're doing), then you could simulate the graphics engine to see if it will behave the way you think it will.
Using the SRAM has the benifit that you don't have to consider refresh cycles. Timing will be a bit more friendly as well. They are going to be more expensive, but you're just doing this as a project and not something you're going to sell millions of, so that's OK.
Good luck! |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Hey, thanks Death,
A Question about solid filling, I was discussing this with someone on CBM Hackers and I asked about objects that are only partly on the screen and they suggested having larger area in memory then the area actually being displayed e.g. screen in memory could by 512x256 and the actual screen displayed would only 320x200. Allowing the hardware to fill the objects that only appear partly on screen. What do you think of this idea? and is method commonly used? I dont know much about how 3D images a calculated and drawn but there does seem to be demand for hardware filling.
|
| |
White Flame
Registered: Sep 2002
Posts: 136 |
No matter what virtual bitmap size you use (assuming you're not having 8GB of framebuffer RAM), you'll always hit cases where it's too small to include what you want to draw especially with perspective 3d renderers. You either need to clip before rasterizing, or have full-precision signed coords in the rasterizer that don't do writes when offscreen (slow but simpler). |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
You got a good point there. Can you explain to me what coords are? I'm guessing that there some kind of marker for where to start and stop filling? |
| |
White Flame
Registered: Sep 2002
Posts: 136 |
coords = coordinates, (x,y) values, etc
So instead of the rasterizer calculating screen ram addresses to fill between, it would keep x,y coordinates of the segments it needs to fill. As it draws the raster line segments that make up the polygons, it needs to check what parts of that segment of the polygon is actually onscreen, and only draw that.
This would require that the video processor have larger registers in the rasterizer, and that it would loop through and try to draw every segment of a polygon even if it's fully offscreen. But like I said, this could be easy to implement in hardware, and you wouldn't have to write a software clipper. But another 'but' would be that you still have to do near-plane clipping for 3d, so if you're already doing that, you might as well just do full view frustum clipping, and have the simpler onscreen-only rasterizer in hardware. |
| |
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.
|
| Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | ... | 20 - Next |
