At 25 fps, that demo seems to require 35% (loading) + 17% (decompression+playback) = 52% of SGC resources as a rough estimate.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.
What's the equivalent QL speed of that emulator? I'm guessing not stock 7.5MHzQLvsJAGUAR 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
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.stephen_usher wrote:That's absolutely amazing!mk79 wrote:Now off to bed. Enjoy, Marcel
What sort of algorithm are you using for that?
I let FFMPEG do all of the dithering and resizing in one step, I guess that can be improved a lot, too.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.
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.P.S. With my compression algorithm I was getting 150 frames (full screen) down to 1MB, so maybe that would be useful to use?
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.Peter wrote:At 25 fps, that demo seems to require 35% (loading) + 17% (decompression+playback) = 52% of SGC resources as a rough estimate.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.
So the QL would have to be 1/2 the speed of the SGC, not 1/6. Or the demo 3x faster
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 scenariostephen_usher wrote:What's the equivalent QL speed of that emulator? I'm guessing not stock 7.5MHz
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. Thanks Urs, I thought about doing that, too, but it's basically cheatingQLvsJAGUAR wrote:Had some spare minutes after work, here‘s my little contribution:
https://youtu.be/LMbZZe4UWA0
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.stephen_usher wrote:What's the equivalent QL speed of that emulator? I'm guessing not stock 7.5MHz
Well, as you've said, not cheating on the software side, but on the hardware side.mk79 wrote:Thanks Urs, I thought about doing that, too, but it's basically cheating
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:QLvsJAGUAR wrote: Had some spare minutes after work, here‘s my little contribution:
https://youtu.be/LMbZZe4UWA0
