Foxie wrote:Also it works in all wakestates. Isn't that unusual for 1990? Are they just using a very conservative sync scroll that works every time? I don't think they knew how to detect all four wakestates in 1990?
troed wrote:It's _very_ conservative. It needs 20 scanlines, and uses only right overscan, right+left overscan and normal line (i.e, 3 combinations). They left out left overscan completely, likely because they couldn't stabilize the Shifter for the following non-overscan screen.
troed wrote:A modern sync scroll, which needs to know about wakestates, has 12 possible line lengths and only needs 4 scanlines to reach all scroll positions.
mlynn1974 wrote:I never quite understood sync scroller.
alien wrote:An amusing fact for Troed: If I recall correctly, they actually had adaptive code to vary the timing of the the resolution/frequency switches around, just in case there was an Atari out there that had different timings. They read the video counter to see whether the desired line lengths had been obtained.
joska wrote:I had a look at the intro now, and from what I can see only about 1/3 of the screen is parallax scolling. And the background looks like 2 bitplanes only. I believe they're syncscrolling the screen and redrawing the background. I'm not very familiar with syncscrolling - can you sync-scroll only parts of the screen?
fenarinarsa wrote:Syncscroll is mostly used to achieve vertical scrolling of the whole screen, you can't use it mid screen without displaying distorted or black lines. In addition as troed said, in EL it needs 20 scanlines to achieve the effect, so you would have 20 distorted or black lines in the middle of the screen. It's useless for the intro screen.
fenarinarsa wrote:The background seems to be written on the displayed buffer, and it's indeed 2 bitplanes, as are the credits & sprite, using generated code.
fenarinarsa wrote:The buffers go higher and higher in memory because of the scrolling, so I guess that's why the intro stops after a while
fenarinarsa wrote:Okay I'm no syncscroll master like you troed or others great people, but I did a quick check of the intro with Steem SSE debug and from what I could see the foreground is indeed achieved with syncscroll (that was an easy find by modifying the colors or by tracing the hbl interrupt).
Since the 4-bit syncscroll technique is certainly not used here, my guess is that it's doing an 16-bit horizontal syncscroll with 4 buffers in which the foreground is written, shifted by 0,4,8,12 pixels. You can actually see this by removing the movep at address $3964 and setting for instance $ff8201=$06 and $ff8203=$10.
thomas3 wrote:In terms of drawing the foreground efficiently - as I understand it, Nic/TCB was somewhat of an innovator in using self-modifying/generated code, so I would guess that this would provide part of the solution - I would bet that the draw routines are optimised to only handle transparency when necessary.
Foxie wrote:That kind of thing blows my mind. But as far as I understand, it's difficult to get huge speed gains by self-modifying sprite code because of the planar display?
fenarinarsa wrote: Sometimes the code is so optimized it won't change anything, like in Wings of Death in which the blitter option does nothing except messing with the player inputs
Users browsing this forum: Facebook [Bot] and 8 guests