My C64 YouTube links for demos etc. are rejected with the words: no :: 60hz crap
category: general [glöplog]
NES is so common/popular to be used with those "retroscalers" (much more than C64s!) that they surely tweaked the device to work with it :)
Yeah its odd the page lists gb/gbc/gba - however it also lists sgb, which basically is this modification you need :)
In any case, all those machines from that time have their videotiming slightly off. And most of them have additional quirks too. (NES is actually a bit of an outlier there).
As for C64 (and likely VIC20/Plus4 too), the biggest problem in our attempts was the slightly too high chroma level - that completely craps out a lot of devices. Adding that magic resistor solved pretty much every problem for us back then (using an ImagePro, which is a bit unfair comparison against OSSC, i guess :))
Yeah its odd the page lists gb/gbc/gba - however it also lists sgb, which basically is this modification you need :)
In any case, all those machines from that time have their videotiming slightly off. And most of them have additional quirks too. (NES is actually a bit of an outlier there).
As for C64 (and likely VIC20/Plus4 too), the biggest problem in our attempts was the slightly too high chroma level - that completely craps out a lot of devices. Adding that magic resistor solved pretty much every problem for us back then (using an ImagePro, which is a bit unfair comparison against OSSC, i guess :))
Well, for those that actually have a framebuffer and can drop frames and such, sure. The OSSC just cannot do that; by design it's just a converter that can buffer a line or so at most, for doubling/tripling (I just saw there's an OSSC Pro, I don't know if it's different).
Anyway, I think that it is technically possible to get a 50.12 Hz capture from a C64. But I certainly wouldn't reject 50 Hz YouTube captures :-) (And TBH, I think that if you chase that level of fidelity, the effort would be better spent at making an online version of VICE where you could seek.)
Anyway, I think that it is technically possible to get a 50.12 Hz capture from a C64. But I certainly wouldn't reject 50 Hz YouTube captures :-) (And TBH, I think that if you chase that level of fidelity, the effort would be better spent at making an online version of VICE where you could seek.)
Anyway, I think that it is technically possible to get a 50.12 Hz capture from a C64.
Code:
Anyway, I think that it is technically possible to get a 50.12 Hz capture from a C64.oh sure. a random analog video card can do it (the infamous bt...something chipset that works with ivtv). It doesnt even need that magic resistor - because of the analog tuner :)
BTW being able to drop frames, or having a framebuffer, is not something you need for this task. All you need is a PAL (or NTSC) decoder that is as generous as the analog counterpart. That so many "retroscalers" have (or had - it is becoming better i heard) problems with this, is because they implement kindof naive - very idealised - decoders, that don't actually sync to the signal they see, but use their own internal reference timing.
Quote:
That would very much amount to pre-rendering the entire demo* ahead of time at full CPU-blast in the background to flatten it out to gigglybytes of temp/RAM/swap storage just for the off-chance of skipping back and forth. (And don't expect much seeking ahead because unthrottled proper emulation with proper native host binary gives you something like 10 times the original speed.)an online version of VICE where you could seek
A plain video seems less wasteful overall.
* demo because interactivity would break seekability... and what about turn-disk.
ppl will always prefer videos anyways
Quote:
Yes, video is like windowshopping. Emulator is like taking a sampling sip. Transferring the prod and actually firing up the old machine... is like opening up that bottle of fine vintage wine for the occasion. Happens rarely, but better be worth it. =)ppl will always prefer videos anyways
Quote:
ppl will always prefer videos anyways
What an iconic sentence. That should be the epitaph on the tomb of our civilization.
The attitude of people like G-Fellow is the exact reason why I include a license regarding captures to my productions.
Understandable. Also, i was shocked and appalled when i learned that Amiga emulator captures are par for the course.
I don't actually mind emulator captures, as long as the emulator is configured properly (which it usually isn't).
Quote:
All you need is a PAL (or NTSC) decoder that is as generous as the analog counterpart.
Well, you also need your capture device to be generous enough to capture the resulting HDMI signal. The OSSC can convert C64 to HDMI just fine (assuming you have something to decode the Y/C signal into RGB before it), but most devices won't like a 50.12 Hz HDMI signal.
Quote:
That would very much amount to pre-rendering the entire demo* ahead of time at full CPU-blast in the background to flatten it out to gigglybytes of temp/RAM/swap storage just for the off-chance of skipping back and forth.
Gigglybytes? A C64 has 64 kB of state, give or take. If you take a snapshot once every second (which gives you fine seekability even if you don't want to warp from the keyframes to get frame-accurate seek), that's 512 kbit/sec before compression. I don't know how much state actually changes between frames in a typical demo, but it sure is possible to compress it further by storing deltas between the key frames. Add a tiny bit for the disk image, of course.
For reference, I checked out a C64 demo capture I did myself a while back, and the YouTube download was about 2025 kbit/sec.
Quote:
ppl will always prefer videos anyways
A seekable emulator capture would be functionally equivalent to a video.
What _kb said. Also, what britelite said.
If you don't capture PAL entries in 50Hz, just "Stop it. Get some help." Sincerely: everyone with a functioning eye. And brain.
If you don't capture PAL entries in 50Hz, just "Stop it. Get some help." Sincerely: everyone with a functioning eye. And brain.
I'm kinda surprised that people are being so harsh about all of this.
Sure, I fully agree that a good C64 capture should be ~50 Hz rather than 60 Hz. But a 60 Hz capture still seems better than no capture, no?
But also, the tone of the rejection is just kinda rude and unhelpful to someone who's (perhaps a bit misguided) trying to help out. Yes yes, we're the demoscene and all that, I get it. Greetings to elites only, fuckings to lamers etc. But like, do we really need to ooze that out of every pore of our bodies all the time, or perhaps we can save it for the scroll texts?
Sure, I fully agree that a good C64 capture should be ~50 Hz rather than 60 Hz. But a 60 Hz capture still seems better than no capture, no?
But also, the tone of the rejection is just kinda rude and unhelpful to someone who's (perhaps a bit misguided) trying to help out. Yes yes, we're the demoscene and all that, I get it. Greetings to elites only, fuckings to lamers etc. But like, do we really need to ooze that out of every pore of our bodies all the time, or perhaps we can save it for the scroll texts?
Quote:
Quote:That would very much amount to pre-rendering the entire demo* ahead of time at full CPU-blast in the background to flatten it out to gigglybytes of temp/RAM/swap storage just for the off-chance of skipping back and forth.
Gigglybytes? A C64 has 64 kB of state, give or take. If you take a snapshot once every second (which gives you fine seekability even if you don't want to warp from the keyframes to get frame-accurate seek), that's 512 kbit/sec before compression. I don't know how much state actually changes between frames in a typical demo, but it sure is possible to compress it further by storing deltas between the key frames. Add a tiny bit for the disk image, of course.
For reference, I checked out a C64 demo capture I did myself a while back, and the YouTube download was about 2025 kbit/sec.
Quote:ppl will always prefer videos anyways
A seekable emulator capture would be functionally equivalent to a video.
Hmm, interesting idea. But why not take the extra step and simply compress the inputs to the VIC, leaving the CPU out of it entirely?
Quote:
Hmm, interesting idea. But why not take the extra step and simply compress the inputs to the VIC, leaving the CPU out of it entirely?
Well, and the SID, including all register timings? I'm not sure if it would make it all that much smaller.
Also, I guess you would really have to include every single frame then (plus subframe information). The nice thing about an emulator playback is that you can have sparse keyframes (all the way down to zero if you don't expect the user to seek).
Why do you need to "seek" inside C64 demos? Is it for viewing convenience or there are some party-orga / pick-demos-for-showing / cataloging & taging purposes?
Viewing convenience. I'm not that interested in viewing ten minutes of scrollers.
Viewing convenience for me. Or for viewing certain parts only. If you have four disk sides and 17 minutes of stuff, I'm gonna watch it exactly once on my real 64 as god intended and then resort to youtube captures.
Quote:
Okay, didn't think of keyframes. State is more like 200 KB (try saving VICE snapshot image), but yeah.A C64 has 64 kB of state, give or take. If you take a snapshot once every second
You're still running a core at 100% CPU to warp under the hood for generating run-ahead snapshots, though.
That or getting ready-made snapshots from the server, which would effectively amount to serving a video at 1600 Kbps... with expensive client-side decoding in software in the browser.
Quote:
If it's a video, you can skip.I'm not that interested in viewing ten minutes of scrollers.
If it's an emulator, you can... skip. By pressing space. Or tactically watch at 10x speed by warping for a bit.
That demo forcing 10 minutes of a single scroller on you in anything but the final part is probably not worth watching anyways.
Quote:
That or getting ready-made snapshots from the server, which would effectively amount to serving a video at 1600 Kbps...
Yes, ready-made snapshots from the server. You don't need to get them except on seek. And the state is almost certainly compressible using lossless compression.
Quote:
If it's an emulator, you can... skip. By pressing space. Or tactically watch at 10x speed by warping for a bit.
It's not nearly the same.
Quote:
Well, and the SID, including all register timings?
I think the audio can just be dumped, it's not that much data.
Quote:
I'm not sure if it would make it all that much smaller.
Smaller than what? Full frame dumps? Or do you mean full-state snapshots?
I mean, it just seems like a more to emulate to have to emulate the full system over just the VIC. And in all likeliness, most of the inputs (screen, character and sprite memory) is either going to be constant between several frames, or only have small updates. Yeah, some diffing and updating would be needed, but even the worst case isn't really a disaster (e.g less than 1000 Kbps, I think?).
Quote:
So is watching via emulator vs. video capture from real hardware.It's not nearly the same.