Great demo, I remember Bonzai. Started coding on C64 in 1986! One suggestion, your PAL 50fps video was containered into 1080p60. If possible, if you can, please upload your PAL demo recordings at 1080p50 🙏🙏🙏 because all currently-sold modern 1080p and 4K TVs support 50Hz even in North America. My RUclips for Amazon Fire TV 4K Max automatically switches to 50Hz when playing 50Hz content, so 🙏 dejudder for us motion-fluidity videophiles. Also the VRR Apple devices (Apple ProMotion on the new expensive iPad Pros) support 50Hz too. The stutter of playing 50fps on 60Hz-only devices are the same regardless of whether you play "50fps-baked-in-60fps-video-file" and "50fps-in-native-50fps-video-file" so there is no downgrade for doing 50fps this way for 60Hz devices, but massively makes it perfect silk smooooooth on auto-50Hz-capable modern devices. So no downside to uploading 1080p50 native recording for 60Hz RUclips viewers. Also, most ordinary cheap PC monitors support 50Hz undocumentedly, just create the mode via Custom Resolution Utility, and verify perfect motion fluidity in your favourite emulator, before beginning screen-recording, makes it easier to create a 1080p50 H.264/H.EVC file) Just to be clear, there's zero downside, no worsened stutters on 60Hz-only devices (it's just a choice of fps-vs-Hz mismatch stutter baked into file, versus the stutters created at playback time), and only massive upside in playback quality to 50Hz-capable devices. It's apparently a little known part of the set of HDTV standards to support 50Hz even in 60Hz North America, very few creators know about how widespread 50Hz support is in all new 1080p & 4K televisions and computer monitors even in NTSC countries. Amendments to HDTV standardization ensured defacto multi format support. Try it on your favourite auto-Hz capable television streaming device (like the latest Amazon Fire TV 4K streaming stick) or via PC to your computer monitor (all of them support undocumented 50Hz) on the other demo recorders who did the 50 trick and watch your jaw drop how silky ultra smooth the PAL demos are when played this way. Hope this PSA has been educational! - Founder of TestUFO / Blur Busters - Creator of "Tearline Jedi Demo" (WIP)
Thanks for curating all these demoes! Incredible, what can be done on the C64. I always wonder what would have happened if these guys would have been in game development instead.
Not v many demo effects are practical in a game; bear in mind that to pull off most of these effects you require the CPU to be doing only that effect for most of each screen frame, leaving no time for game logic, etc.
Thank you for making this recording of our return to the scene. Brings back great memories. However, you really need to sort out the sound side of things. It sounds like you are playing the 8580 version on a 6581 SID? Other than that, awesome recording
I'm pretty sure they're using an emulator. I don't think you can get analog video digitised this clean. If I may ask, how many kB was this demo? It looks and sounds amazing!
@@firefly618 Thank you :) This demo fits on 2 disk sides. Each side has 174kb of free space, so 348kb :) The source code for this demo is a different beast though - 44mb in 1660 files.
maybe this question sounds clueless but has there been a new discovery recently on c64 coding? I know that it was always possible to render graphics onto the borders but recent demos do it so casually that you could think the 64 os a true 320x224 machine.
I don't know, they find new tricks all the time. I coded on Atari 8 bit and ST, to do full screen required knowing the exact machine cycles of intructions to replace the starting array of nops lol I imagine it would be similar...
Кино
Great demo, I remember Bonzai. Started coding on C64 in 1986! One suggestion, your PAL 50fps video was containered into 1080p60. If possible, if you can, please upload your PAL demo recordings at 1080p50 🙏🙏🙏 because all currently-sold modern 1080p and 4K TVs support 50Hz even in North America. My RUclips for Amazon Fire TV 4K Max automatically switches to 50Hz when playing 50Hz content, so 🙏 dejudder for us motion-fluidity videophiles. Also the VRR Apple devices (Apple ProMotion on the new expensive iPad Pros) support 50Hz too.
The stutter of playing 50fps on 60Hz-only devices are the same regardless of whether you play "50fps-baked-in-60fps-video-file" and "50fps-in-native-50fps-video-file" so there is no downgrade for doing 50fps this way for 60Hz devices, but massively makes it perfect silk smooooooth on auto-50Hz-capable modern devices.
So no downside to uploading 1080p50 native recording for 60Hz RUclips viewers.
Also, most ordinary cheap PC monitors support 50Hz undocumentedly, just create the mode via Custom Resolution Utility, and verify perfect motion fluidity in your favourite emulator, before beginning screen-recording, makes it easier to create a 1080p50 H.264/H.EVC file)
Just to be clear, there's zero downside, no worsened stutters on 60Hz-only devices (it's just a choice of fps-vs-Hz mismatch stutter baked into file, versus the stutters created at playback time), and only massive upside in playback quality to 50Hz-capable devices. It's apparently a little known part of the set of HDTV standards to support 50Hz even in 60Hz North America, very few creators know about how widespread 50Hz support is in all new 1080p & 4K televisions and computer monitors even in NTSC countries.
Amendments to HDTV standardization ensured defacto multi format support. Try it on your favourite auto-Hz capable television streaming device (like the latest Amazon Fire TV 4K streaming stick) or via PC to your computer monitor (all of them support undocumented 50Hz) on the other demo recorders who did the 50 trick and watch your jaw drop how silky ultra smooth the PAL demos are when played this way. Hope this PSA has been educational!
- Founder of TestUFO / Blur Busters
- Creator of "Tearline Jedi Demo" (WIP)
Thanks for curating all these demoes! Incredible, what can be done on the C64. I always wonder what would have happened if these guys would have been in game development instead.
Many demomakers went in game development indeed.
Not v many demo effects are practical in a game; bear in mind that to pull off most of these effects you require the CPU to be doing only that effect for most of each screen frame, leaving no time for game logic, etc.
@@kodiak64Ah yes, I didn't realize that. That's an important point. But nevertheless very impressive to see what the C64 can do!
Nice to see your videos doing well man. You should make a playlist with all the C64 videos so that your viewers can batch watch them :)
yea good idea, ty
@@gazzaka ❤️
while that demo was running I had to check the label on my machine but it is indeed a C64 and not an Amiga...
lol
yeah back in the day some of this stuff would be impressive even on an Amiga, absolutely amazing.
That was impressive. I am not entirely convinced it was a C64. Maybe Amiga...
Definitely C64 graphics and sound.
Thank you for making this recording of our return to the scene. Brings back great memories. However, you really need to sort out the sound side of things. It sounds like you are playing the 8580 version on a 6581 SID? Other than that, awesome recording
I'm pretty sure they're using an emulator. I don't think you can get analog video digitised this clean.
If I may ask, how many kB was this demo? It looks and sounds amazing!
@@firefly618 Thank you :) This demo fits on 2 disk sides. Each side has 174kb of free space, so 348kb :) The source code for this demo is a different beast though - 44mb in 1660 files.
@@TrapBonzai 44mb?? Or 4,4? 44 seems a lot for a c64's source code demo.
@@jimbotron70 44mb. Depends I guess. This includes assembler files, graphics, converted graphics, music, data files, scripts and tools. It adds up :)
Our latest demo, Mojo, is 268mb ;)
maybe this question sounds clueless but has there been a new discovery recently on c64 coding? I know that it was always possible to render graphics onto the borders but recent demos do it so casually that you could think the 64 os a true 320x224 machine.
I don't know, they find new tricks all the time. I coded on Atari 8 bit and ST, to do full screen required knowing the exact machine cycles of intructions to replace the starting array of nops lol
I imagine it would be similar...
ผมเห็นภาษาไทย