| |
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....
|
| |
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.
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
row&$f8 => row/8 ofcourse. Silly me... |
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
Ok, I can see the convertersion of column based to bitmap based.
Still don't fully get how the filler is working, you have the lines in the line buffer, you EOR with bitmap and store in the next row, right? Is the bitmap clear when you start the EOR fill? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Ok, I can see the convertersion of column based to bitmap based.
Still don't fully get how the filler is working, you have the lines in the line buffer, you EOR with bitmap and store in the next row, right? Is the bitmap clear when you start the EOR fill?
No, I'm just tired and lost. Here's the proper example:
.repeat 32,column
lda #0
.repeat 128,row
eor linebuffer+column*128 + row ;column based
sta bitmap+column+(row/8)*320+(row&7) ;bitmap based
.endrep
.endrep
:)
|
| |
Stingray
Account closed
Registered: Feb 2003
Posts: 117 |
ok, thanks.
So portal enigine draws the lines in a 256*128 column based format.
The portal engine then EOR fills it onto a bitmap
Is that right? |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: ok, thanks.
So portal enigine draws the lines in a 256*128 column based format.
The portal engine then EOR fills it onto a bitmap
Is that right?
Correct. In two passes for dithering. Even row and odd rows seperatly.
However for a hw-assisted eor-fill I guess you don't have the luxury of having an A-register to use as temp. I.e. each store has to be stateless or?
If that is the case then you must do something similar to
lda linebuffer+row*128+column
eor bitmap+yaddayadda
sta bitmap+yaddayadda+one row down
And the engine must initialize the first row of the bitmap to the init values for the eor-filler (similar to the lda #0).
|
| Previous - 1 | ... | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | ... | 20 - Next |
