| | 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....
|
| | Oswald
Registered: Apr 2002
Posts: 5086 |
stunt car does not use eor filling, it fills only the sky, and even that on a char by char basis, when it hits the road then goes pixel by pixel... |
| | Fresh
Registered: Jan 2005
Posts: 101 |
I followed this thread waiting to see the birth of a new hw but it looks like too much time has passed since last Stingray's post...
It sounded very promising, I really hope this thing still being under development.
... any news about this lil beauty? |
| | WVL
Registered: Mar 2002
Posts: 899 |
Jackasser : how many fps could your 3d engine put out if you'd have had EOR-on-the-fly and clear-memory? |
| | JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: Jackasser : how many fps could your 3d engine put out if you'd have had EOR-on-the-fly and clear-memory?
WVL: dunno to be honest, not that much I think. When the FPS is slow most time is spent in math and line drawing anyway. Using the c128 version u get a frame rate counter. Stand close to a wall so that you only see one complete solid, then u get the EOR+CLEAR fps basically. When the FPS drops it's because of line drawing and math, not filling and clearing. |
| | WVL
Registered: Mar 2002
Posts: 899 |
yesyes, i understand clearing and EOR take the same time always... I can code too, ya know :D
let's calc..
eor+sta takes 6 cycles per byte (if you plot inside the eor-speedcode, that is). 'dumb' clearing takes 4 cycles/byte (storing 0 in the eor-speedcode).
that's 10 cycles per byte. Let's say half of the screen get's updated, then you have 40*200/2 = 4000 bytes = 40.000 cycles saved. So that's about 2 frames.
Now let's do some maths..
fps frames/update VICX frames/update VICX fps speed increase
1 50,0 48,0 1,0 4%
2 25,0 23,0 2,2 9%
3 16,7 14,7 3,4 14%
4 12,5 10,5 4,8 19%
5 10,0 8,0 6,3 25%
6 8,3 6,3 7,9 32%
7 7,1 5,1 9,7 39%
8 6,3 4,3 11,8 47%
9 5,6 3,6 14,1 56%
10 5,0 3,0 16,7 67%
11 4,5 2,5 19,6 79%
12 4,2 2,2 23,1 92%
13 3,8 1,8 27,1 108%
14 3,6 1,6 31,8 127%
15 3,3 1,3 37,5 150%
16 3,1 1,1 44,4 178%
17 2,9 1,0 50,0 194%
18 2,8 1,0 50,0 178%
19 2,6 1,0 50,0 163%
20 2,5 1,0 50,0 150%
21 2,4 1,0 50,0 138%
22 2,3 1,0 50,0 127%
23 2,2 1,0 50,0 117%
24 2,1 1,0 50,0 108%
25 2,0 1,0 50,0 100%
No idea how many fps it can do now though, but this should give a good idea about the increase in speed.
I'd call anything above 10fps good for c64 purposes.. considering that, it's a bit disappointing that only the 7-9 fps get boosted to 10fps.. |
| | chatGPZ
Registered: Dec 2001
Posts: 11360 |
Quote:I followed this thread waiting to see the birth of a new hw but it looks like too much time has passed since last Stingray's post...
It sounded very promising, I really hope this thing still being under development.
... any news about this lil beauty?
i think VICX turned into Alienflash somehow: http://www.lemon64.com/forum/viewtopic.php?t=36830 |
| | JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: yesyes, i understand clearing and EOR take the same time always... I can code too, ya know :D
let's calc..
eor+sta takes 6 cycles per byte (if you plot inside the eor-speedcode, that is). 'dumb' clearing takes 4 cycles/byte (storing 0 in the eor-speedcode).
that's 10 cycles per byte. Let's say half of the screen get's updated, then you have 40*200/2 = 4000 bytes = 40.000 cycles saved. So that's about 2 frames.
Now let's do some maths..
fps frames/update VICX frames/update VICX fps speed increase
1 50,0 48,0 1,0 4%
2 25,0 23,0 2,2 9%
3 16,7 14,7 3,4 14%
4 12,5 10,5 4,8 19%
5 10,0 8,0 6,3 25%
6 8,3 6,3 7,9 32%
7 7,1 5,1 9,7 39%
8 6,3 4,3 11,8 47%
9 5,6 3,6 14,1 56%
10 5,0 3,0 16,7 67%
11 4,5 2,5 19,6 79%
12 4,2 2,2 23,1 92%
13 3,8 1,8 27,1 108%
14 3,6 1,6 31,8 127%
15 3,3 1,3 37,5 150%
16 3,1 1,1 44,4 178%
17 2,9 1,0 50,0 194%
18 2,8 1,0 50,0 178%
19 2,6 1,0 50,0 163%
20 2,5 1,0 50,0 150%
21 2,4 1,0 50,0 138%
22 2,3 1,0 50,0 127%
23 2,2 1,0 50,0 117%
24 2,1 1,0 50,0 108%
25 2,0 1,0 50,0 100%
No idea how many fps it can do now though, but this should give a good idea about the increase in speed.
I'd call anything above 10fps good for c64 purposes.. considering that, it's a bit disappointing that only the 7-9 fps get boosted to 10fps..
The speed up would be greater actually since the C64-version didn't have memory for a fully unrolled filler and clearer. The C128-version have that otoh + relocatable ZP and stack optimizations so I guess with VICX it would be somewhat close to the C128-version except for not using the 2mhz-mode. |
| | Oswald
Registered: Apr 2002
Posts: 5086 |
I guess you could go fullscreen without loosing much speed. |
| Previous - 1 | ... | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 - Next | |
