Log inRegister an accountBrowse CSDbHelp & documentationFacts & StatisticsThe forumsAvailable RSS-feeds on CSDbSupport CSDb Commodore 64 Scene Database
You are not logged in - nap
CSDb User Forums


Forums > C64 Coding > FASTER 3D GRAPHICS
2004-10-26 06:24
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....
 
2004-10-28 10:50
Stingray
Account closed

Registered: Feb 2003
Posts: 117
Thats not a bad idea, it would be almost as easy to make it fill a segment of memory with any byte including #$00, if that would be better? So you think this clear/fill thing would be better for 3D speed then data transfer?
2004-10-28 13:39
Oswald

Registered: Apr 2002
Posts: 5094
yep, awesome idea from wvl. how about adding an eorfiller aswell? thats another bottleneck of 3d gfx, and should be plain ass simple to realize.
2004-10-28 14:55
Stingray
Account closed

Registered: Feb 2003
Posts: 117
OK, data transfer is out and filler is in. I have two options with the filler.

A: Only fill 6K per frame

B: Add 30 badlines and steal about 1500 cpu cycles/frame

I don't plan on having any badlines for normal graphics access (at least not at the moment). If I did go for option B, the badlines would only be switched on for frames when filling was being carried out. Option A is simpler to design but is clearing 6k per frame acceptable?

Oswald, this could be a stupid question (I know next to nothing about 3D graphics) but do you mean for example- EOR 3K of memory with byte #$80? If so this would take 2 cycles per byte meaning 3 frames to EOR 8k using option A or 2 frames using option B. Is this good enough? You wouldn't be able to byte fill on the same frame you EOR fill (that would be pointless anyway, wouldn't it?). Just wondering, what would be more useful if I had to decide between one or the other, Byte fill or EOR fill?

I know I have asked a lot of questions and you fellows have helped me out heaps. I am starting to get an idea of what the spec will be. I must stress that this cct will be VERY low spec (at least for now), no frills at all, just quicker for 3D.
2004-10-28 17:01
WVL

Registered: Mar 2002
Posts: 902
What Oswald means is this :

lda column0

eor column1
sta column1

eor column2
sta column2

etc

eor column199
sta column199

if you run a routine like that, you only have to draw 2 pixels in a column to have it fill the lot.

the first pixel turns the pixel in the accumulator on, the 2nd pixel turns it off again => you filled a column, and pretty fast aswell!

eorfill and simple clearing will MAJOR speed things up.

ofcourse you need at least 2 banks for gfx.

edit :

even better is that it saves heaps of memory ;) a lot of coders have an eorfiller and normal filler like this unlooped in memory! Also note i only once did 3d graphics and very lousy at that.. dont take my word for anything ;)
2004-10-29 08:14
Oswald

Registered: Apr 2002
Posts: 5094
wvl: to be more precise:

lda 0
eor 1
sta 1

eor 2
sta 2

...

eor 199
sta 199

column #2:

lda 200
eor 201
sta 201

...

eor 399
sta 399

IMHO the lda at the top of the columns negligable, and the circuit can do just eor sta eor sta.. if the design is simpler that way. OR the lda might be replaced to load the accu with a fixed value. (preferably a choicable value).

How hard it would be to implement lines ? :)
2004-10-29 10:34
WVL

Registered: Mar 2002
Posts: 902
i think the first lda should be inside the eorfill itself. it makes no sense to have to w8 for the correct cycle the chip finished eorfilling one column, and then do a lda, and give the chip orders to start the next column.

it should be made easier -> the chip just has to do the first lda #0 by itself..

2004-10-29 11:15
Oswald

Registered: Apr 2002
Posts: 5094
the chip could do an lda #xx itself, at the top of each column
2004-10-29 12:58
WVL

Registered: Mar 2002
Posts: 902
yes, but also the chip has to do all columns by itself. it takes too much time to tell the chip to eorfill all columns individually.
2004-10-29 13:48
Stingray
Account closed

Registered: Feb 2003
Posts: 117
Alright, so an EOR filler only does vertical lines? It looks like its only one access per cycle so therefore the cct could EOR one byte per cycle (same as byte filler). This should be pretty easy to design and would probably share a lot of common logic with the byte filler; it could possibly even be a mode for the byte filler to run in with a control bit that turns EOR on or off, how does that sound?

About my previous question of weather to go option A (fill 6k per frame) or option B (add in the 30 bad lines and fill 8k per frame). I'm leaning towards option A simply because it's easier to design. This would mean two frames to clear a screen and another two frames to EOR fill (It's important to remember that these fills are at no expense of cpu cycles since they are all done during the video ctt's memory access part of the clock cycle). I’ve got know idea of what kind of frames per second we should be aiming for or even what typical frames per second are for C64 with full screen 3D. I really want to know is 4 frames to clear and EOR fill (plus all the normal number of cpu cycles per frame to do what ever it is 3D graphic coders do) going to cut it?
2004-10-29 17:52
WVL

Registered: Mar 2002
Posts: 902
idea :

why not do the eor-filling during display of the gfx data? so you can toggle a switch to have a normal display mode, or a eor-type display mode.

i imagine when in eor-display mode, instead of fetching a byte from memory to display it, you eor it with a byte in your internal buffer, and only then draw.

-> saves 2 frames, not? :)

during clearing in the other 2 frames, you should have enough time to calculate and draw nice 3d shapes, so with triple buffering, 25 fps should be possible in that case..
Previous - 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | ... | 20 - Next
RefreshSubscribe to this thread:

You need to be logged in to post in the forum.

Search the forum:
Search   for   in  
All times are CET.
Search CSDb
Advanced
Users Online
BYB/Hokuto Force
Mike
iAN CooG/HVSC
Jazzcat/Onslaught
Guests online: 326
Top Demos
1 Next Level  (9.7)
2 13:37  (9.7)
3 Mojo  (9.7)
4 Coma Light 13  (9.6)
5 Edge of Disgrace  (9.6)
6 What Is The Matrix 2  (9.6)
7 The Demo Coder  (9.6)
8 Uncensored  (9.6)
9 Comaland 100%  (9.6)
10 Wonderland XIV  (9.6)
Top onefile Demos
1 No Listen  (9.6)
2 Layers  (9.6)
3 Cubic Dream  (9.6)
4 Party Elk 2  (9.6)
5 Copper Booze  (9.6)
6 X-Mas Demo 2024  (9.5)
7 Dawnfall V1.1  (9.5)
8 Rainbow Connection  (9.5)
9 Onscreen 5k  (9.5)
10 Morph  (9.5)
Top Groups
1 Performers  (9.3)
2 Booze Design  (9.3)
3 Oxyron  (9.3)
4 Censor Design  (9.3)
5 Triad  (9.3)
Top Coders
1 Axis  (9.8)
2 Graham  (9.8)
3 Lft  (9.8)
4 Crossbow  (9.8)
5 HCL  (9.8)

Home - Disclaimer
Copyright © No Name 2001-2024
Page generated in: 0.065 sec.