Re: Bad Apple demos
Posted: Tue Nov 19, 2019 9:02 pm
I have to admit, the title of this thread made me think that it was a piss take on some really bad demos for Apple products. Oops!
Cheers,
Norm.
Cheers,
Norm.
Hi Marcel,mk79 wrote:And finally, here is Bad Apple for the Sinclair QL in full length and with some music: https://vimeo.com/373787028. Enjoy.
Sorry, I misunderstood your meaning.mk79 wrote:What I mean here is that the original video is exactly synchronised to the music, so scene changes happen at specific notes, etc. I have written video software before, I know how to synchronize video and sound that was already in step in the first place. But the music I got from the net does not necessarily correspond in any way to the video, time wise. Just stretching it out so that it roughly correlates to the length of the video might work, but it could also just sound weird and still not match up with the video. In any case more time would be needed that I currently don't have
Not quite, it's more akin to the difference between interpreted code and compiled.Derek_Stewart wrote:Nice video, just shows the difference between C and assembler.
Well, the QL and Macintosh were announced within a week of each other....NormanDunbar wrote:I have to admit, the title of this thread made me think that it was a piss take on some really bad demos for Apple products. Oops!
Cheers,
Norm.
Very nice! Well done!mk79 wrote:And finally, here is Bad Apple for the Sinclair QL in full length and with some music: https://vimeo.com/373787028. Enjoy.
@Stephen, did you continue to work on your project?stephen_usher wrote:Not quite, it's more akin to the difference between interpreted code and compiled.Derek_Stewart wrote:Nice video, just shows the difference between C and assembler.
My code was reading what to put into the bytes onto the screen and doing so one at a time. mk79 wrote a program which interpreted the same sort of differencing and translated the changes into a series of 68000 instructions (compiled) which were then loaded from the file and called (I assume) as a subroutine which then acted upon the memory directly. (This is what I gathered from one of his previous posts.)
The other day I spent some time to run a Bad Apple video on the Q68, see the result: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
Hi Urs,QLvsJAGUAR wrote:The other day I spent some time to run a Bad Apple video on the Q68, see the result: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
https://youtu.be/d7HPuAyHx5A
The two .QMV video files used with QPC2 and Q68 are available under the QL/E section of the SinclairQL.net website.
QL forever!
Well, actually when considering the SuperGoldCard which I used in the end for my video I expect the "interpreter" approach might even be faster than my "compiler" approach. The reason being that the compiler approach essentially executes 33MB of code (that has to come through the 8-bit bus bottleneck), rendering the code cache completely useless. The "interpreter" approach needs to execute MORE code, which on one hand is bad, but with a tight decoder loop (< 256 bytes) the code could be executed entirely from cache, freeing memory bandwidth for the data, which is a huge plus.stephen_usher wrote:Not quite, it's more akin to the difference between interpreted code and compiled.Derek_Stewart wrote:Nice video, just shows the difference between C and assembler.
My code was reading what to put into the bytes onto the screen and doing so one at a time. mk79 wrote a program which interpreted the same sort of differencing and translated the changes into a series of 68000 instructions (compiled) which were then loaded from the file and called (I assume) as a subroutine which then acted upon the memory directly. (This is what I gathered from one of his previous posts.)