| |
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 |
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. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
And now i just remembered that the -1 position (1 pixel between sprite and non-border area) is not represented as $1ff, but $1f7 or something. Should still be no problem. |
| |
null
Account closed
Registered: Jun 2006
Posts: 645 |
Quote: Glad to see that people are still trying to open the borders. I'm here to help on your quest with my favorite quote!
"The opened outline is able to capture something of our secret thoughts and its permutative behaviour. We can recognize an item here and there but the line always glides further with unlimited combination of associations. Curves of the consiousness, curves of the subconcious."
You're welcome.
I'm so happy this quote isn't dead yet. |
| |
GH
Registered: Sep 2014
Posts: 77 |
Oh it will live forever because we're just human ;) |
| |
Copyfault
Registered: Dec 2001
Posts: 478 |
Quoting KrillQuoting 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.
...
Now I'm confused... What is actually meant by "gap"?
According to AAY64's timing schemes, the additiional cycles of NTSC machines are inserted at PAL-cycle #57. But this cycle lies within the (optionally) visible part of the right sb. So this should mean that sprites at these "additional" NTSC-cycles are visible if the right sb is opened.
The remaining question is wether the right sb ends @cyc#60 (NTSC) or @cyc#62. So "worst case" would be that the visible area in the right sb is just as wide as on a PAL system, no? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
I think the "additional" gfx is under the right border/horizontal blank...
Otherwise we have a 8/16 pixels misaligment on sprites and screen coords in the left part of the screen...
But i can't see this difference between pal and ntsc. |
| |
Krill
Registered: Apr 2002
Posts: 2980 |
Quoting CopyfaultNow I'm confused... What is actually meant by "gap"? A gap in sprite positioning. 65 cycles equal 520 pixels, but there are only 9 bits to set the sprite X position. Thus, there are 8 positions you cannot put the sprite to. However, i'm pretty sure that you can "display" sprite pixels there, and span that gap, by setting its X position to just before that gap. The shift registers logics and all should work just fine. |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Isn't possible that in ntsc a cycle equates to 7.7538... pixels, so we have always 504 screen dots, but with a little "fast sync", that isn't visible?
Just my thoughts... eh! |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
