| |
Shadow
Account closed
Registered: Apr 2002
Posts: 355 |
Are the C64 pixels supposed to be square?
So I was trying out a little vector effect, and while it looks normal in emulator, on my C64 with a 1084-monitor I get a distinct impression that it gets a bit stretched vertically.
Is this simply my monitor that is not correctly adjusted, or are C64 pixels non-square? |
|
... 12 posts hidden. Click here to view all posts....
|
| |
chatGPZ
Registered: Dec 2001
Posts: 11360 |
its not the reason for sprites beeing 21 pixel high... thats simply because 64/3=21 (+1) |
| |
WVL
Registered: Mar 2002
Posts: 899 |
Quote: I have the theory that the pixels are not only not square but that because of this the sprites have such an odd size. I mean, what? 24x21 pixels? Why not 24x24? Also it seems that 24x21 is pretty much square on a not totally fudged with c64 monitor if you keep the aspect ratio 4:3. Also measured this on a few TVs where it was. Bigger stuff within this ratio as well.
24*21 is because of the way the vic works and the maximum # of cycles on each line.. With sprites being 3 bytes wide, the VIC can _just_ manage to read all the data from memory in a badline. That explains the 24 pixels.
The 21 pixels high simply comes because this is closest to 64 bytes (a power of 2), so they can be adressed nicely. |
| |
ptoing
Registered: Sep 2005
Posts: 271 |
24x21 still is pretty much spot on square on TVs and such, so if anything it's a nice coincidence.
Also LOTS of systems, for example arcadeboards, have nonsquare pixels. It's not that uncommon. |
| |
Oswald
Registered: Apr 2002
Posts: 5086 |
al charpentier the designer about it:
"I was going to use memory running just under 2 mhz meaning only 114 memory fetches per line .. I figured the processor would need atleast 40 of those fetches. 40 was a nice architectural number because there are also 40 pieces of background information so the background information and cpu slices could be easily interleaved. So 114 minus 40 fetches for the cpu and 40 for the background left me with 34 fetches. I needed 8 fetches to pick up the sprite pointers that left 26 fetches if I had 8 sprites that gave me 3 fetches for each sprite
...
Charpentier then looked for a mutiple of 3 that would approach a power of 2 so that sprites could be stored efficiently "it happened that 24 by 21 bits gave 63 bytes of information he said"
http://www.commodore.ca/gallery/magazines/c64_design/5.jpg |
| |
Cruzer
Registered: Dec 2001
Posts: 1048 |
I noticed this already back in the days when I was doing C64 gfx on Amiga, and after porting it to C64 it looked a bit narrower. I think the aspect ratio is about 9:10.
|
| |
Graham
Account closed
Registered: Dec 2002
Posts: 990 |
None of the old 8 bit machines has square pixels. On C64 the pixels are about 5% taller than wide, on Atari 8 bit machines it's the other way round: Pixels are about 5% wider than tall.
Square pixels on PAL require a pixel clock of 14.75 MHz, but that's for interlace resolution so for non-interlace this makes it 7.375 MHz. A PAL C64 has a pixel clock of 7.882 MHz, a PAL Atari has a clock of 7.094 MHz.
Then there is also the non-standard frequencies used for those machines, I am not sure if rasterlines get scaled because of this, and if yes, how.
|
| |
Zagon
Account closed
Registered: Apr 2002
Posts: 14 |
First, sorry to revive an old topic but I must have missed it when it
was current.
I believe that the vertical and horizontal speed speed of the electron
beam of a CRT television set is constant. The video signal doesn't
control the speed of the beam but only when it should be reset to the top
and to the left.
If this holds true then the pixel width is determined by the dot clock
and the pixel height by the scan line frequency.
This means that we can calulate the teoretical pixel aspect ratio of a
given system if we know the scan line frequency and the dot clock of
that system.
standard dot clock MHz scan line kHz
square PAL 7.37500000 15.62500000
square NTSC 135/22 15.73426573
c64 PAL 7.88198756 15.63886420
c64 NTSC 7.88198756 15.73426484
c64 oldNTSC 7.88198756 15.98011272
c64 PAL
x-ratio = 7.37500000 / 7.88198756
y-ratio = 15.62500000 / 15.63886420
pixel AR = x-ratio / y-ratio = 0.93650794
(the following are calculated in the same way)
c64 NTSC pixel AR = 0.75000000
c64 oldNTSC pixel AR = 0.76171875
I'm sorry to say that I have no way to control these numbers at the
moment. I remember that a 24x21 sprite seemed quite square on a PAL
system. The calculated PAL AR would have a 24 pixel wide square about
22.5 pixels high so at least the numbers are not totally off.
|
| |
AmiDog
Registered: Mar 2003
Posts: 97 |
Might just be me, but when I set up a 1084, I usually set it up so that all borders (left/right/top/bottom) are more or less equally thick. The 1084 being a 4:3 monitor would make the 320x200 pixels cover an area with a 4:3 aspect ratio and thus give a pixel aspect ratio of (200/3)/(320/4)=0.833...
I think I once measured the non-border area of the C64 display on the 29" Sony CRT I was using at that time, but don't remember the result... |
| |
Mace
Registered: May 2002
Posts: 1799 |
AmiDog, setting the border equally thick by hand on a 1084 is hardly a scientific approach :-) |
| |
Wile Coyote
Account closed
Registered: Mar 2004
Posts: 646 |
My Commodore monitor has an option to adjust the screen height, which came in handy for PAL Snes games, which featured black upper and lower borders, with the resultings image have a slightly squashed look. I used to adjust the screen to remove the upper and lower borders. It improved the look Street Fighter II Turbo, lots.
|
| Previous - 1 | 2 | 3 - Next |
