Bad Apple demos

A place to discuss general QL issues.
Derek_Stewart
QL Wafer Drive
Posts: 1906
Joined: Mon Dec 20, 2010 11:40 am
Location: Runcorn, Cheshire, UK

Re: Bad Apple demos

Postby Derek_Stewart » Tue Nov 26, 2019 9:01 pm

Hi Stephen,

Really excellent work, getting the demo to run on a QL.

Could an API be written to load in video files?


Regards,

Derek
stephen_usher
Trump Card
Posts: 248
Joined: Tue Mar 11, 2014 8:00 pm

Re: Bad Apple demos

Postby stephen_usher » Tue Nov 26, 2019 10:04 pm

Derek_Stewart wrote:Hi Stephen,

Really excellent work, getting the demo to run on a QL.

Could an API be written to load in video files?


Well, the code is written with the idea of being more flexible. The encoder program is actually a generic encoding function with a debugging main() calling it with specific parameters. I had originally expected to write a full program which took a set of QL MODE4 screen files and output the m4v format file. Adding sound is more tricky, of course, which is why I had to hard code it in a modified version of the encoder.

As for the decoder side, it's trivial to change it so that it reads the name of the file from the command line as an argument. Everything else comes from the video file.

Now, generating the QL MODE4 screen files isn't *THAT* difficult. FFMPEG can break a video into individual JPEG files which the scripts I've created can make into xbm files, which a program (included) can, with the help of an included Perl script, convert into QL MODE4 screen dumps.

It would take a little effort but any video could be processed. You'd just need a large enough and fast enough storage medium on the QL to play it. (I'm limited by the size of a floppy image and RAM disk.)


User avatar
mk79
Super Gold Card
Posts: 642
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Bad Apple demos

Postby mk79 » Wed Nov 27, 2019 9:51 am

Cristian wrote:
mk79 wrote: an area where I am completely clue and talent-less: music!
So, after all, your planet-sized brain is more similar to Mars than to Jupiter :-)
Well, in German there is the word "Fachidiot" (literally "subject idiot", somebody who is very good at one thing and not so good most others). I prefer the loose English translation "nerd" because in my brain at least it doesn't sound so harsh, but the point stands :-P

Cheers, Marcel


User avatar
Pr0f
Super Gold Card
Posts: 652
Joined: Thu Oct 12, 2017 9:54 am

Re: Bad Apple demos

Postby Pr0f » Wed Nov 27, 2019 11:01 am

mk79 wrote:
Cristian wrote:
mk79 wrote: an area where I am completely clue and talent-less: music!
So, after all, your planet-sized brain is more similar to Mars than to Jupiter :-)
Well, in German there is the word "Fachidiot" (literally "subject idiot", somebody who is very good at one thing and not so good most others). I prefer the loose English translation "nerd" because in my brain at least it doesn't sound so harsh, but the point stands :-P

Cheers, Marcel



There is also "Idiot savant", altough that implies mental impairment with the exception of one area - and that's not the case here.


Silvester
Trump Card
Posts: 220
Joined: Thu Dec 12, 2013 10:14 am
Location: UK

Re: Bad Apple demos

Postby Silvester » Mon Dec 09, 2019 12:49 pm

mk79 wrote:One of the huge advantages that I used compared to your C code is that I fetch the data through low level raw sector access, I don't go through the file system layer.

Aha!

My attempts failed back in 2002 when trying to implement some sort of virtual memory swap file using normal driver access. Decoding progressive JPEGs can take a great deal of memory (each successive scan builds up the spectral and/or resolution, which requires storing the whole image at 24 bits per pixel). Although the scheme worked OK (shunting chunks of memory in/out); QPC2 / SMSQmulator only about 3 times slower than if whole image held in memory, it failed miserably on real QL hardware. I gave up after 15 minutes of constant drive access on a SGC/Qubide system.

I did consider the faster direct sector access route, but it needs to be done through some driver manipulation. I'm guessing that is what you did with QL-SD ? Is it worth considering it as a future SMSQ/E filing system feature?


I'm not plugged into the Matrix so my responses may be delayed.
User avatar
mk79
Super Gold Card
Posts: 642
Joined: Sun Feb 02, 2014 10:54 am
Location: Esslingen/Germany
Contact:

Re: Bad Apple demos

Postby mk79 » Mon Dec 09, 2019 1:05 pm

Silvester wrote:I gave up after 15 minutes of constant drive access on a SGC/Qubide system.
Yeah, the emulators fill the buffers with the speed of the host system, which is a thousand times faster.
I did consider the faster direct sector access route, but it needs to be done through some driver manipulation. I'm guessing that is what you did with QL-SD ?
QL-SD has a low level API for direct access so different file system drivers can be implemented on top of them without interfering with each other.
Is it worth considering it as a future SMSQ/E filing system feature?
Well, generic direct sector access through OS calls already exist. The point of the low level API is not to have an OS stack on top of it.



Who is online

Users browsing this forum: No registered users and 2 guests