Scroll fixes

[hcs64]

Here are a few fixes that I needed to get VINL-1 (https://vgmdb.net/album/7659) scrolling correctly, now it looks ok, and at least matches VLC.

Populated demo available on request, not sure if you want a link with a rip here. I also made a number of other changes on the demo side to deal with scaling and loading better in this branch, but it isn't well organized yet.

[bhj]

Hey, thanks for this! Interestingly, I tried using ffmpeg (2023-06-21) to convert track 2 using

ffmpeg -i input.cdg -i input.mp3 -b:v 1M output.mp4

and the output is similarly broken, though not exactly the same. Not sure what to make of that.

I'm all for the changes; just want to make sure we don't regress on other stuff first. Maybe we can start on a proper testing approach (or at least something better than me picking files at random)?

[hcs64]

I only learned about CD+G this week! So I don't have any real advice for a more thorough testing regime. I'm not sure what track 2 you mean, were you able to test VINL-1? This is the only disc I have, though maybe it's unusual. I don't have any appropriate reference hardware for comparison, just expectations and VLC.

Some notes:

The trick for the continuous fine scroll is to only write a new row of tiles into the top border. That way the intermediate state, the XOR update flicker and the partial lines, isn't visible. The scroll can then be nearly continuous, by the time it's a multiple of 12 the line is done, so the scroll copy command cycles the top row around to the bottom where it can be scrolled in next.

I saw that ffmpeg messes it up, but their implementation moves everything with scroll offset, and attempts to compensate by offsetting tile block positions. This doesn't quite work for horizontal scroll, e.g. track 6, I think it might be backward? They tried to fix it for vertical scroll, but when the scroll happens continuously the lines get smeared out. I'd want to rewrite a lot of that, they really need a separate buffer.

I have some expectations of how the hardware would work, based on my work on NES emulation. It seems infeasible that a scroll command would be able to read and write 32KB in a single operation. Also it seems odd for the scroll offset to finely control rendering positions rather than always affecting exactly one 36 byte tile.

So I think there is likely a designated upper left tile pointer for both tile blitting and output rendering. Scroll copy then just has to move that pointer, and scroll preset additionally sets one row/column. (This is equivalent to moving the tile data around as you and VLC do, and probably isn't an important optimization here.) Then scroll offset only controls where the output pixels are pulled from the buffer, which has to happen every frame anyway. The border is partly to prevent having to deal with fetches past the end of the buffer.

[bhj]

I'm not sure what track 2 you mean, were you able to test VINL-1?

Yes, track 2 seems to be a good test for vertical scrolling; haven't tried the others yet. Thanks for the links and notes; I'm not a CDG expert by any means.

There's supposedly a format called CD+EG (extended graphics), but there's very little info out there. A release like VINL-1 strikes me as the kind that might employ that cutting-edge format ;) but either way, will need to do some regression tests. With these changes you are getting more or less comparable output to VLC across the whole album? Thanks again.

[hcs64]

There's supposedly a format called CD+EG (extended graphics), but there's very little info out there. A release like VINL-1 strikes me as the kind that might employ that cutting-edge format ;)

The label has the CD+G logo, wikipedia shows a different logo for CD+EG. I don't know the history CD+EG but I expect 1991 is too early. I think it's all just down to subtleties of scrolling.

but either way, will need to do some regression tests.

You might want to check how the change in setting the border works with detecting content ranges and transparency, I added a commit that backs out initializing bgColor to 0 as I thought it might interfere, but that's something I didn't test at all.

With these changes you are getting more or less comparable output to VLC across the whole album?

Yeah, I just watched through the whole album side by side with VLC and didn't notice any difference.

Thanks again.

Sure thing, glad to help the project!

[bhj]

@hcs64 Made a slight tweak to be more explicit with the border color handling (instead of defaulting to the first color in the LUT) and avoid the display bounds check if possible. Scrolling is apparently pretty rare, at least among my (english) karaoke collection, so VINL-1 makes a nice test. Those crossfades near the end of track 3 are pretty amazing too!

Thanks again for taking the time to fix and let me know if I missed anything.