The Sinclair QL Forum

Ah, Dilwyn, now I gotit!

That's a reindeer on the flag you use as avatar!
(I can see it's got a red nose too, so must be Rudolph, I guess)

Tobias
(who just risks a 10 years non-admittance to welsh grounds)

tofro wrote:Ah, Dilwyn, now I gotit!

That's a reindeer on the flag you use as avatar!
(I can see it's got a red nose too, so must be Rudolph, I guess)

Correct

tofro wrote: Tobias
(who just risks a 10 years non-admittance to welsh grounds)

As soon as Brexit allows...

dilwyn wrote: (who just risks a 10 years non-admittance to welsh grounds)...
As soon as Brexit allows...

Is that not waexit or even weexit !

Animated Christmas card (from the "unofficial forum animation competition")
Since on Qemulator it runs much faster than the original QL, as usual you may set the speed by changing the "p" parameter at line 200 (for Qemulator I suggest a numeric value of 5 or 6).
Enjoy!
https://dl.dropboxusercontent.com/u/397 ... /MERRY.zip

Cristian wrote:Animated Christmas card (from the "unofficial forum animation competition")
Since on Qemulator it runs much faster than the original QL, as usual you may set the speed by changing the "p" parameter at line 200 (for Qemulator I suggest a numeric value of 5 or 6).
Enjoy!
https://dl.dropboxusercontent.com/u/397 ... /MERRY.zip

Very nicely done! I hope you don't mind that I included a "movie" version in my QMovie v2 distribution as an example of a low-colour no-sound variant.

Marcel

QLvsJAGUAR wrote:

mk79 wrote:Source is included. Have fun.

Great stuff (both the band and your work), Marcel!

Thanks!

Amazing how little code is needed (EXE size is 336 Bytes) to let SMSQ/E play videos! Windows and even Linux are so bloated those days, to get a tiny task done, almost everything goes in the hundreds if not thousands (references, declarations, files, megabytes) nowadays. The simplicity of our OS is what keeps me sticking with the QL.

Yeah, but then programming for SMSQ/E is a pain compared to Windows or other modern systems, it's light-years behind regarding the developer tools.

Integration of QMovie into QL/E or any other distribution or personal environment is simple. To have QMovie_exe handier I would like two changes:
1. Input parameter should be either a channel or a filename
2. Additional parameter to pass the desired output, e.g. CON_480x270a16x36

I have released v2 in another thread, I think you will like it

Marcel

pjw wrote:

mk79 wrote:OK, I couldn't help myself. I wrote a quick&dirty movie player including sound: https://www.kilgus.net/2016/12/05/qmovi ... ie-player/

I know the feeling, but Im manfully resisting the urge I hope someone will pick up the baton, though, as it looks really hopeful

The movie file is some 320MB and contains 2 minutes of concert footage shot by me, so the player has to stream 2,6MB per second. I can now say with certainty that the system is not fast enough to decompress this amount of data on-the-fly, neither bzip2 nor gzip worked without major delays.

Surely that would depend on things like size and resolution? In my second test Im actually EXing unzip on the whole clip for each frame, and QPC still manages to keep up! In your clip you appear to be using the largest sprite size and resolution, not to mention sound, so that might be a tough act to keep up.

It's also possible that the synchronization between the data-producing UNZIP and the consuming QMovie is the problem, but decompresssion has to be done on-the-fly. I removed this feature for v2.0 because it didn't work anyway. Maybe you could reduce the resolution, but then files will get smaller pretty quickly anyway.

As Urs says, Great music (and nice girls (not sure Id like to find myself alone with them, without my dog.. ))

Then you will probably enjoy the same video at 25fps using v2 They don't come over often to Germany, but when they do I try to be there, it's always quite a party

Cheers, Marcel

mk79 wrote:I hope you don't mind that I included a "movie" version in my QMovie v2 distribution as an example of a low-colour no-sound variant.

You're welcome!

Hi,

Trying to catch up with this thread.

I have not tried the animations as yet on the real QL, but I was wondering if the screen images could be compressed?
I remember on ZX there were programs de/compressing screens.

I thought of a simple logic that would be fast enough not to spoil animation effects, as a trade off for a lower compression rate.

I read this article, https://en.wikipedia.org/wiki/Run-length_encoding, not sure if applicable here.
I believe this `'RLE' so to speak, is a basis for ATARI MSA floppy format.

Tomas

tcat wrote:Hi,

Trying to catch up with this thread.

I have not tried the animations as yet on the real QL, but I was wondering if the screen images could be compressed?
I remember on ZX there were programs de/compressing screens.

I thought of a simple logic that would be fast enough not to spoil animation effects, as a trade off for a lower compression rate.

I read this article, https://en.wikipedia.org/wiki/Run-length_encoding, not sure if applicable here.
I believe this `'RLE' so to speak, is a basis for ATARI MSA floppy format.

Tomas

While it would certainly be an interesting exercice doing this, do bear in mind that it's already possible to use RLE compression in the context of sprites, and Per Witte showed how easy it is to make sprites from screens. That specific example used uncompressed sprites, but GD2 sprites can use RLE compression already, and the format adapts readily to using byte length (e.g. for Aurora 256 colour), word length (for 16-bit colour modes) and so on. GD2 sprites can do a degree of conversion from screen mode to screen mode too, and it's easier to write a sprite to a given position on the screen on hires displays.
All that's needed is a quick and easy to use routine to convert 32k screens and pic files to RLE compressed GD2 sprites and you're away!

But implementing a 'standard' simple compression routine such as RLE for 32k screens and PIC files might be quite interesting in itself.