The Sinclair QL Forum

I wonder if the Bad Apple demo could be extended to run Dragon's Lair on the QL (someone needs to reach out to Jim Bagley)....

mk79 wrote:

Peter wrote:

stephen_usher wrote:At that speed it might just work on a stock QL, which seems to be about 1/6th the speed of the SGC.

At 25 fps, that demo seems to require 35% (loading) + 17% (decompression+playback) = 52% of SGC resources as a rough estimate.
So the QL would have to be 1/2 the speed of the SGC, not 1/6. Or the demo 3x faster

The calculation is flawed as QL-SD is only marginally faster on SGC due to being on the QL side o the bus.

It was not a serious calculation, but a rough estimate meant with a twinkle. Of course it's flawed, and not only because of QL-SD. On the other hand, assuming the SGC only 6x QL speed is also flawed (e.g. consider instruction fetch from 24 MHz 68020 32-bit wide CPU cache vs. 7.5 MHz 68008 8 bit-wide DRAM). While the QL is obviously better than 1/6 SGC speed for SD card read and screen writes, it is worse for decompression calculations. Where the overall factor will end up, can not be predicted without look into more details. It's probably easier to just test.

By the way, I doubt an "only marginally" difference for QL-SD. At least if we talk reading from SD card to a buffer in main memory. I have no time to run tests, but I remember a "much slower" feeling.

mk79 wrote:I'm still not sure how an unmodified QL would keep up, but with some further tricks I guess it's possible.

With the term "unmodified" do you mean a QL without QL-SD, or a QL without Trump/Gold card?
What about the tricks... any general idea?

Cristian wrote:

mk79 wrote:I'm still not sure how an unmodified QL would keep up, but with some further tricks I guess it's possible.

With the term "unmodified" do you mean a QL without QL-SD, or a QL without Trump/Gold card?

You will always need some sort of mass storage, so QL-SD is pretty much a must. Also, you probably need to cache frames, so I guess a memory expansion wouldn't hurt either.

What about the tricks... any general idea?

Anything that minimizes memory bandwidth consumption. It might even make sense to forgo any clever algorithm and directly stream raw data from the SD to the screen as in all other cases you're touching the data twice and the CPU needs to fetch the code that touches the data twice, too. Not sure if this could ever be fast enough, it's just an idea. But if it's not fast enough, reduce frame rate or only draw every second line etc...

And finally, here is Bad Apple for the Sinclair QL in full length and with some music: https://vimeo.com/373787028. Enjoy.

Spectacular, also for the real music (with QL!)
This video merits at least a proper recording (and maybe a little audio synchronization). An audio/video capture via PC would be complicated?
So, finally, also the QL has its deserved place in the Bad Apple demo scene!

Thank you very much Marcel, also for your technical explanations!

Thanks! Well, I have no idea how the music could be better synchronized as this is not my area of expertise. If it were synchronized a real screen grab might make a lot more sense, but as it is it‘s more like a proof of concept than a polished product.

mk79 wrote:Thanks! Well, I have no idea how the music could be better synchronized as this is not my area of expertise. If it were synchronized a real screen grab might make a lot more sense, but as it is it‘s more like a proof of concept than a polished product.

The only way to fully synchronise would be to use timing marks in the video stream to trigger the audio. If you have a known frame rate this can operate as the tempo for the sound generation from the audio data triggering it being sent to the AY chip at the end or beginning of each frame. If you're working on a frame rate of 25 frames per second you would merely make the audio track use time periods per note in 40ms quanta.

stephen_usher wrote:The only way to fully synchronise would be to use timing marks in the video stream to trigger the audio. If you have a known frame rate this can operate as the tempo for the sound generation from the audio data triggering it being sent to the AY chip at the end or beginning of each frame. If you're working on a frame rate of 25 frames per second you would merely make the audio track use time periods per note in 40ms quanta.

What I mean here is that the original video is exactly synchronised to the music, so scene changes happen at specific notes, etc. I have written video software before, I know how to synchronize video and sound that was already in step in the first place. But the music I got from the net does not necessarily correspond in any way to the video, time wise. Just stretching it out so that it roughly correlates to the length of the video might work, but it could also just sound weird and still not match up with the video. In any case more time would be needed that I currently don't have

mk79 wrote:Just stretching it out so that it roughly correlates to the length of the video might work, but it could also just sound weird

I don't know... it would be probably less weird than a piece of video without sound... maybe.

mk79 wrote: In any case more time would be needed that I currently don't have

Once recorded the video, a volunteer might synchronize the audio track via some video editing software. Not exactly a cheat, just a minor trick...
In any case, you made a great piece of work