| |
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....
|
| |
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! |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: 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!
No, nothing points to this being true. For instance new graphics data is fetched every cycle on the VIC-II, where would it be buffered? |
| |
Flavioweb
Registered: Nov 2011
Posts: 463 |
Quote: No, nothing points to this being true. For instance new graphics data is fetched every cycle on the VIC-II, where would it be buffered?
It should not be buffered.
The VIC would do the same tasks, but instead of finishing after eighth pixels, would end after "7.7538..." pixels.
After 65 cycles we "are" at pixel 504, as we use 8 pixels for 63 cycles...
A difference of a "0.25" pixel every 8, should not be noticeable "by eye" (and could absolutely not exist). |
| |
tlr
Registered: Sep 2003
Posts: 1790 |
Quote: It should not be buffered.
The VIC would do the same tasks, but instead of finishing after eighth pixels, would end after "7.7538..." pixels.
After 65 cycles we "are" at pixel 504, as we use 8 pixels for 63 cycles...
A difference of a "0.25" pixel every 8, should not be noticeable "by eye" (and could absolutely not exist).
That doesn't make sense to me. There are 65 cycles on NTSC. A byte is fetched every cycle (=8 bits) So how could you display that as 7.75 pixels every cycle without having a FIFO buffer?
Sure you could stretch the first seven pixels to make the eigth pixel smaller, but it is still 8 pixels.
You should be reasoning like this: What is the easiest way to make the chip the most similar between PAL/NTSC/PAL-N? |
| Previous - 1 | 2 | 3 | 4 | 5 - Next |
