The Sinclair QL Forum

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

Hi folks, summer is over, Urs is back.

Had some spare minutes after work, here‘s my little contribution:
https://youtu.be/LMbZZe4UWA0

QL forever!


Gesendet von iPhone mit Tapatalk

QLvsJAGUAR wrote:Hi folks, summer is over, Urs is back.

Had some spare minutes after work, here‘s my little contribution:
https://youtu.be/LMbZZe4UWA0

QL forever!


Gesendet von iPhone mit Tapatalk

What's the equivalent QL speed of that emulator? I'm guessing not stock 7.5MHz

stephen_usher wrote:

mk79 wrote:Now off to bed. Enjoy, Marcel

That's absolutely amazing!

What sort of algorithm are you using for that?

Thanks! Well, the design constraints were to minimize development time and maximize execution speed at the expense of code size. So I basically wrote a bitmap to 68k-code compiler. The differences between the frames are translated into code that enact these changes. The code is pretty simplistic, basically it emits a lot of "adda.w #1234,a0" and "move.w #$1212,(a0)+", at which point it becomes a classic compiler optimizer problem to improve upon it, so there is still a lot of room for optimization. But when targeting a CPU without code cache and memory bandwidth as the bottleneck you can't get much better than this approach.

By the way those speckles in the images are probably from diffusion dithering on too small an image, I got that once and had to swap to a different dithering algorithm for the small version of the video.

I let FFMPEG do all of the dithering and resizing in one step, I guess that can be improved a lot, too.

P.S. With my compression algorithm I was getting 150 frames (full screen) down to 1MB, so maybe that would be useful to use?

Well, I too was thinking about some sort of differential RLE approach, but wanted to see how far I could push the speed for now. On the SGC the RLE approach might even have benefits due to the code cache, when targeting the original machine it will always lose. I did some optimizations today and got the 470 or so frames down to 2MB. Still a lot when considering that there are 5500 frames, but when streaming from SD size is not a huge issue anymore.

Cheers, Marcel

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. Especially if you stream with raw sector access there is a lot of speed to gain. Likewise you don't need 25 fps for it to look good, or you could do interlacing or... there are a lot of options for further optimizations.

Cheers, Marcel

stephen_usher wrote:What's the equivalent QL speed of that emulator? I'm guessing not stock 7.5MHz

As somebody who wrote both the emulator and the movie player in question I'd venture a guess of a 200-1000x speedup, depending on the exact scenario The movie player displays RLE compressed full sprites, so no differential encoding as it was meant for "real" movies where pretty much every pixel is always different. But it even has support for seeking within the file, play is not strictly one way. The interesting thing is that from a software perspective it is a very well-behaved application, it doesn't even draw directly into the screen memory, it exclusively uses standard QDOS and PE APIs to do its work! So it could work in theory on any QL platform, but of course it won't be as much fun there.

QLvsJAGUAR wrote:Had some spare minutes after work, here‘s my little contribution:
https://youtu.be/LMbZZe4UWA0

Thanks Urs, I thought about doing that, too, but it's basically cheating

Cheers, Marcel

stephen_usher wrote:What's the equivalent QL speed of that emulator? I'm guessing not stock 7.5MHz

Well, QTop-Index reports 633.601, hence this system running QPC2 with QL/E is weighed 633 times faster than a BBQL. In other words it behaves like a 4.7GHz QL.

mk79 wrote:Thanks Urs, I thought about doing that, too, but it's basically cheating

Well, as you've said, not cheating on the software side, but on the hardware side.

QLvsJAGUAR wrote: Had some spare minutes after work, here‘s my little contribution:
https://youtu.be/LMbZZe4UWA0

For those of you who like to try playing this video on their system with the QMovie player, here's the download link to the video file:
http://sinclairql.net/repository.html#BadApple

Enjoy, have a great day, a funny Halloween and QL forever!
Urs