| |
Parody
Registered: Jul 2013
Posts: 7 |
Leftmost sprite position and opening borders
I just noticed that x=0 for a sprite doesn't cover the "start" of the left side border, Is there any way to achieve this? |
|
... 37 posts hidden. Click here to view all posts....
|
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
@Oswald: There are 63 cycles on a raster line, thus 63*8 = 504 pixels available, not 512. It's easy as that. Somewhere it has to wrap. |
| |
WVL
Registered: Mar 2002
Posts: 902 |
Never did anything with ntsc machines, but will there be a gap with these machines (since they have 65 cycles) where you can't put any sprites? |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
Quote: @Oswald: There are 63 cycles on a raster line, thus 63*8 = 504 pixels available, not 512. It's easy as that. Somewhere it has to wrap.
thanks, that makes some sense.
tho the inner xcoo should still be 9 bits, right, there can not be a 8.95 bits counter so it wraps at 504 ? :)
or is it just the misalignment, that x =0 is not on the leftmost position...
not trying to be an ass here, just wondering :) |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
Quote:or is it just the misalignment, that x =0 is not on the leftmost position...
its an arbitrary position that was chosen so when sprite x position is 0, the sprite is hidden behind the left border.
and of course, the counter is 9 bits :) |
| |
Oswald
Registered: Apr 2002
Posts: 5094 |
that makes sense again, tho it seems they forgot about x stretched sprites :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quoting GroepazQuote:or is it just the misalignment, that x =0 is not on the leftmost position...
its an arbitrary position that was chosen so when sprite x position is 0, the sprite is hidden behind the left border.
and of course, the counter is 9 bits :)
It's not a counter, it's a compare register. If raster x>compare x then shift pixels from shift register. |
| |
chatGPZ
Registered: Dec 2001
Posts: 11386 |
of course, raster X is the counter :) |
| |
JackAsser
Registered: Jun 2002
Posts: 2014 |
Quote: of course, raster X is the counter :)
That's right! ;) |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting WVLNever did anything with ntsc machines, but will there be a gap with these machines (since they have 65 cycles) where you can't put any sprites?
Hmm, did not do anything on an NTSC machines myself but I don't think that these extra cycles should be different compared to other '-'-cycles in the right sb. My guess is that sprites will show up at these positions.
It would be interesting to know wether the right NTSC-sb is 2 chars wider than the PAL-sb or if it also 'ends' after approx. 4 chars. If so, the 9-sprites-on-one-rasterline-routine would not be possbile on NTSC;)
Maybe some cracker/NTSC-fixer knows the answer. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting WVLNever did anything with ntsc machines, but will there be a gap with these machines (since they have 65 cycles) where you can't put any sprites? There must be a gap. However, it's quite likely in the horizontal blank area, such that the sprite is entirely inside the invisible part of the sideborders when it "jumps" over that gap.
According to http://sourceforge.net/p/vice-emu/code/HEAD/tree/trunk/vice/src.. , the visible part of the left border on 65-cycle NTSC is 56 pixels wide, and 44 pixels on the right border. This makes the visible area 56+320+44=420 pixels wide. Add 48 on the left side to scroll the sprite in, and you have 468 pixels. This is still less than 512.
According to http://unusedino.de/ec64/technical/misc/vic656x/pal-ntsc.html , the gap is at X=412=$19c. With above assumptions, the sprite is just outside the visible left border at coordinate $1b0 (=-$50), and just outside the visible right border at $184. $50+$184=$1d4=468.
As $184 < $19c < $1b0, the gap (which should be 8 pixels wide, less than the gap's distance to either side) should not be relevant, and you can scroll the sprite smoothly in and out the visible area. |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
