| |
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 |
Sorry Martin, I thought you were refering to the sprite data fetches.
It's a good question. As the Sprite pointers are loaded in to the VIC the same way the sprite data is, the VIC will fetch the sprite pointers from the same location as usual (the last 8 bytes of the selected video matrix).
The color data pointer, bitmap data pointer and the Character data pointer used by the Magic Box (I really need a name for this circuit, how about "Vic Enhancer" for the moment?) are 16bit pointers that are independent of video banks and the Video Matrix pointer etc., so you could have Video Matrix at $0400 and the character data pointer at $8000 or whatever.
I will just point out that at the moment I only have this addressing scheme implemented and working for color data. I will also point out that you will not be stuck with a linear screen formatting. |
| |
Martin Piper
Registered: Nov 2007
Posts: 718 |
Cheers. That makes sense.
As for a name "VIC-X"? :)
|
| |
WVL
Registered: Mar 2002
Posts: 899 |
How does it work?
I'm imagining that the VIC is asking for bytes from $d800, and that your circuitry changes this address and asks for bytes from colorpointer+adressasked-$d800 instead. And sends the value read back to the VIC.
So a kind of man-in-the-middle attack, where the VIC requests are being modified and 'false' data is being sent back to the VIC..
Is that how it works? |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Martin, VIC-X as in VIC eXpander?
WVL, perfect analogy, the "MAN IN THE MIDDLE ATTACK"!
yeah, pretty much. The VIC-X or Vic Enhancer just sits between the Motherboard and the VIC. VIC puts out the address it wants, but the VIC-X / Vic Enhancer intercepts it and puts it's own address on the bus, allowing allot of freedom in how the C64 uses the VIC.
So with the use of forced badlines, it is now possible to have a unique COLOR nybble for EVERY 8*1 cell on the screen.
My C64 is currently putting a different nybble on the color bus for ever 8*1 cell, pretty cool! That's 8k (nybbles not bytes) of just color data! I have not written any code that takes advantage of this (that's well above my coding skill and I'm trying and convince Oswald to write an editer).
WVL, If you want me to, I can go more in depth with how the address pointer increments. |
| |
WVL
Registered: Mar 2002
Posts: 899 |
Oh, that's OK. But now I understand how you plan to do a linear bitmap (by modifying the adress) and EOR-on-the-fly (by modifiying the data).
It's nice that you're still using the VIC, but now with a smart adress-modifier between the VIC and the bus. Much better idea than creating a video chip by yourself. |
| |
Martin Piper
Registered: Nov 2007
Posts: 718 |
Quoting stingrayMartin, VIC-X as in VIC eXpander?
Exactly my thinking. |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Regarding 3D-graphics and EOR-filling and what you would need.
1) Ways of setting up A^B = C (i.e. place A, B and C in memory and EOR-fill it).
2) Width, Height and Stride (bytes per line) for A, B and C.
3) Vertically EOR-fill that memory.
4) Clearing
With the above it would then be possible to HW-accelerate normal filled vectors and more over it would support the dithered EOR-filling used in f.e. Edge of Disgrace, Natural Wonders and Andropolis.
If you implement that, I can gladly "accellerate" my portal engine for you if you wanna test it.
Example:
* Set width & height to 256x128, horizontal linear mode
* Set stride of A to $20
* Set stirde of B and C to $28
* Point A to $2000 (line buffer)
* Point B to $6000 (bitmap)
* Point C to $6028 (bitmap, one row down)
* Start EOR-fill
* Clear A
This is actually exactly what you would do on an Amiga using the blitter...
For dithered mode you would do:
* Set width & height to 256x64, horizontal linear mode
* Set stride of A to $40
* Set stirde of B and C to $50
* Point A to $2000 (line buffer)
* Point B to $6000 (bitmap)
* Point C to $6050 (bitmap, two rows down)
* Start EOR-fill pass 1
* Point A to $2020 (line buffer, one row down)
* Point B to $6028 (bitmap, one row down)
* Point C to $6078 (bitmap, three rows down)
* Start EOR-fill pass 2
* Clear A
/JackAsser
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
@Martin
What about for VIC eXtreme?
or even VIC UNLEASHED for names?
@WVL
From what I understand (in regards to FLI bug) the color port and data port on the VIC are actually open to receive data on the VIC? The only reason why you get undesired data is just because VIC isn't seeing the data that you would want it to, but VIC is actually display what it see's on the bus during the FLI bug area?
If my understanding is correct, that means that with this circuit (intercepting the data and address bus), ppl will no longer have to worry about FLI bug. Plus you get to FLI the COLOR RAM. |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Quoting JackAsserRegarding 3D-graphics and EOR-filling and what you would need.
1) Ways of setting up A^B = C (i.e. place A, B and C in memory and EOR-fill it).
2) Width, Height and Stride (bytes per line) for A, B and C.
3) Vertically EOR-fill that memory.
4) Clearing
With the above it would then be possible to HW-accelerate normal filled vectors and more over it would support the dithered EOR-filling used in f.e. Edge of Disgrace, Natural Wonders and Andropolis.
If you implement that, I can gladly "accellerate" my portal engine for you if you wanna test it.
I checked out the demo's you referenced. The Doom maze is very very impressive.
*EOR-fill (on the fly)
*memory fill
*memory clear
*memory copy
*column based screens (256 byte column offsets)
*row based screen (40 or 256 byte row offsets)
*COLOR RAM anywhere (allows FLI of COLOR RAM)
*Removal of 16k bank limitation
*Plus a couple of extra little tricks i may include as a suprise
This is pretty much the spec I'm working to, so it sounds like it will a least do part of what you need.
BTW, in regards to memory fill/clear/copy circuit, do you think this function is enough to be classed as a simple Blitter?
I have read your post several times, I almost understand it I think.
Are you using 4k at $2000 (representing 256*128) to draw the lines?
You are then EOR filling a bitmap $6000?
what is A^B=C all about? is that A to the power of B = C?
I think I kinda get it, kinda don't, could you please break it down for me a bit more?
As I said, that Doom maze was very very impressive, I would love to make this project help accelerate that kind of thing or even same speed but larger window. Is that maze using your portal engine? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Quoting JackAsserRegarding 3D-graphics and EOR-filling and what you would need.
1) Ways of setting up A^B = C (i.e. place A, B and C in memory and EOR-fill it).
2) Width, Height and Stride (bytes per line) for A, B and C.
3) Vertically EOR-fill that memory.
4) Clearing
With the above it would then be possible to HW-accelerate normal filled vectors and more over it would support the dithered EOR-filling used in f.e. Edge of Disgrace, Natural Wonders and Andropolis.
If you implement that, I can gladly "accellerate" my portal engine for you if you wanna test it.
I checked out the demo's you referenced. The Doom maze is very very impressive.
*EOR-fill (on the fly)
*memory fill
*memory clear
*memory copy
*column based screens (256 byte column offsets)
*row based screen (40 or 256 byte row offsets)
*COLOR RAM anywhere (allows FLI of COLOR RAM)
*Removal of 16k bank limitation
*Plus a couple of extra little tricks i may include as a suprise
This is pretty much the spec I'm working to, so it sounds like it will a least do part of what you need.
BTW, in regards to memory fill/clear/copy circuit, do you think this function is enough to be classed as a simple Blitter?
I have read your post several times, I almost understand it I think.
Are you using 4k at $2000 (representing 256*128) to draw the lines?
You are then EOR filling a bitmap $6000?
what is A^B=C all about? is that A to the power of B = C?
I think I kinda get it, kinda don't, could you please break it down for me a bit more?
As I said, that Doom maze was very very impressive, I would love to make this project help accelerate that kind of thing or even same speed but larger window. Is that maze using your portal engine?
It could indeed be called a simple blitter.
At $2000 is the line buffer yes. Typically y-linear, or column based. That simplifies line drawing alot.
A,B and C are simply the two input sources and the destination. A^B=C means: At C store A[j] eor B[k].
The maze is using the portal engine yes.
Typically an unrolled eor-filler on the C64 is something like (which converts column based buffers to bitmap based direcly aswell):
.repeat 32,column
.repeat 128,row
lda linebuffer+column*128 + row ;column based
eor bitmap+column+(row&$f8)*320+row&7 ;bitmap based
sta bitmap+column+((row+1)&$f8)*320+(row+1)&7 ;bitmap based one row down
.endrep
.endrep
Now, for dithering you'd need to loop this twice, but every second row. Even rows in the first pass, then odd rows in the second pass.
|
| Previous - 1 | ... | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | ... | 20 - Next |
