Hi Stephen,
Really excellent work, getting the demo to run on a QL.
Could an API be written to load in video files?
Bad Apple demos
-
- Font of All Knowledge
- Posts: 4693
- Joined: Mon Dec 20, 2010 11:40 am
- Location: Sunny Runcorn, Cheshire, UK
-
- Super Gold Card
- Posts: 528
- Joined: Tue Mar 11, 2014 8:00 pm
- Location: Oxford, UK.
- Contact:
Re: Bad Apple demos
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.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?
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.)
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: Bad Apple demos
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 standsCristian wrote:So, after all, your planet-sized brain is more similar to Mars than to Jupitermk79 wrote: an area where I am completely clue and talent-less: music!

Cheers, Marcel
Re: Bad Apple demos
mk79 wrote: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 standsCristian wrote:So, after all, your planet-sized brain is more similar to Mars than to Jupitermk79 wrote: an area where I am completely clue and talent-less: music!
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.
Re: Bad Apple demos
Aha!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.
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?
David
- mk79
- QL Wafer Drive
- Posts: 1349
- Joined: Sun Feb 02, 2014 10:54 am
- Location: Esslingen/Germany
- Contact:
Re: Bad Apple demos
Yeah, the emulators fill the buffers with the speed of the host system, which is a thousand times faster.Silvester wrote:I gave up after 15 minutes of constant drive access on a SGC/Qubide system.
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.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 ?
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.Is it worth considering it as a future SMSQ/E filing system feature?