Lynx Noob

[ThomH]

Can you disable rendering of a line? Blank it out somehow?

 

In principle you could disable video DMA via bit 0 of $FD92, but as far as I'm aware nobody has ever tested whether that takes effect instantly, or is merely latched until end of frame. If you test it out, let somebody know!

 

Then in 16 colour mode being able to offset the Buffer by 4 gives you a VSP scroller. If you drop to 30fps you can do erase plots on 1 frame, new draws on 2nd frame, flip. Depending upon the LCD blur it might not be too jerky... or that speed could just be a mess...

 

It took me twenty minutes, but eventually I learnt that 'VSP' is a C64-community term meaning 'variable screen position'. There seems to be an implication of wraparound addressing, so it's scrolling in much the same way as you might on something like a Master System where crossing an 8-pixel boundary means updating only a single row or column of tile indices, not shifting the entire set.

 

So knee-jerk comments:

 

The Lynx is ahead of its time; it's usually treated like a machine a couple of generations or so after the C64 in that the expectation is that every frame is drawn completely afresh into a plain frame buffer using the blitter. No hardware tilemap and usually no partial display updates.

 

Total memory bandwidth is only somewhere between 60% and 100% greater than the C64, but the blitter makes up for the difference as it lets you do those graphics manipulations without also having to pay for an instruction stream. The main hassle is that there are diminishing returns in terms of graphics size; because Suzy has to read a complete SCB for each displayed item, and the graphics data pointed to by SCBs needs to include end-of-line markers and usually a per-line padding byte to avoid hardware bugs, drawing a lot of small things is disproportionately more expensive than drawing fewer large things. If you wanted 8x8 tiles, that might actually be problematic. There's definitely more than enough time to draw and redraw large graphics though.

 

Therefore I guess that if you really wanted a perpetually-scrolling view into a buffer where you had to pay for redrawing only the column/row that comes into view, you'd probably just want an uncompressed buffer somewhere in memory that you draw to the display two (for 1d scrolling) or four (for 2d scrolling) times, and which you declare as the drawing destination for Suzy when updating. It's just going to have to be at most 156 pixels wide. So add an obscuring side bar on output?

[oziphantom]

It seems the blitter does make a solid dent into the CPU time though. In that Lynx games to me see slow, and I'm playing on Handy which it seems it significantly faster than real hardware To which I guess is because the games are tuned for hardware, so the game only goes as fast as real hardware can.

 

On paper the Lynx should melt a C64, it should be pushing an Amiga with its smaller screen.

To build a vertical strip of 8 pixels at 16colour = 12 * 8 * 2 bytes = 192 bytes (assuming a 96 pixel high screen) to form and move, that's is a trivial amount of data to move with the CPU. You then have 20 frames to prep the next buffer, so you move 192 bytes + draw a single 96x8 sprite on the main buffer, then you draw the same sprite on the back buffer at a different position per frame, and that for the scroll. This then gives you the rest of the frame to clean up and draw things that move/shouldn't move. At some point this will not save you more time than doing the whole frame draw. But something like Rygar/rastan where you only have a couple of enemies on screen at one time, skate or die where you are basically the only moving thing on the screen etc

 

As the machine can draw the whole frame in a frame, you could set the buffers at 4px offsets from each other to get a half step and then you have 2 bad frames every 20 frames as they do a full redraw as the VSP resets. But you can probably easily predict when they are going to happen and prep your AI/collision etc for them.

 

The Amiga also kind of does something like this, its called a Cylinder scroller. But the Amiga has pixel scrolling as well.

[ThomH]

It seems the blitter does make a solid dent into the CPU time though. In that Lynx games to me see slow, and I'm playing on Handy which it seems it significantly faster than real hardware To which I guess is because the games are tuned for hardware, so the game only goes as fast as real hardware can.

 

Yeah, the CPU has to surrender the bus to the blitter so you're potentially losing quite a lot, especially when you consider the mechanism of clipping given the requirements: must work for RLE compressed data, must work for scaled data.

 

So actually, I would dare imagine that the optimal horizontal scroller would do something like keep a set of pre-rendered columns, e.g. each of 32 pixels wide to contain four or two columns of your source tile map. Fill those columns on demand using Suzy, draw whichever of those columns is at least partially visible to the display. Composite your sprites directly in the display, don't worry about updating and maintaining your 32-or-whatever-width cache columns. Just fill them once, then keep them until you discard them.

 

For an eight-way scroller you'd probably do that with macroblocks being squares rather than columns.

 

My personal theory on why so many Lynx games are fairly slow-paced is that they're just optimised for the blurry LCD. Indeed, the fastest scroller I can think of is probably the BMX event from California Games, which was likely written long before the exact screen was selected.

 

EDIT: my top demo-esque programming tip though: don't overlook the ability of using the blitter to allow you to be more lazy with the 6502. E.g. you can assemble a 160-width one-byte-per-pixel scan line on the 6502 stack, then use Suzy to stretch blit that into 4bpp form at wherever the frame buffer really is.

Edited September 28, 2018 by ThomH

[enthusi]

EDIT: my top demo-esque programming tip though: don't overlook the ability of using the blitter to allow you to be more lazy with the 6502. E.g. you can assemble a 160-width one-byte-per-pixel scan line on the 6502 stack, then use Suzy to stretch blit that into 4bpp form at wherever the frame buffer really is.

Or write several lines into a literal sprite (not at ZP) and then stretch it to x 50%. I wonder what would be faster.

I am using that in my ISO RPG game.