My C64 YouTube links for demos etc. are rejected with the words: no :: 60hz crap
category: general [glöplog]
But, I know what you mean. I thought also sometimes to me, wow, this 640 blocks demo is now 700 MB big, when I finished the recording of a C64 demo... :D
Maybe demos should have more randomised elements such that no two watchings (or recordings, for that matter) show exactly the same stuff.
@Krill: Yeah, and it would get noticed by you, perhaps me, and other 7 people. It’s a battle lost. Also, interactivity never quite took root in demos. Even the press space is gone. These days, not only is hardware not mandatory, but you can also fast-forward in Vice. Not only that, but we also had that github page that took files from CSDb and played them in browser, oblivious to the host hardware platform. So, you could emulate on iPad, directly from the database. But even that is not enough I guess. So, are we hijacking this subject further or we stop? ;)
OP is done for, so no prob hijacking. :)
When will we stop rejecting 50 Hz captures and only accept 50.12?
(Also, I'd gladly stop watching YouTube videos of C64 prods once someone makes an online emulator where you can seek)
(Also, I'd gladly stop watching YouTube videos of C64 prods once someone makes an online emulator where you can seek)
Is 50.12 Hz an option for any current codec/container at all? :)
But then... even with perfectly appropriate original frame rate... it still looks a lot smoother on a CRT.
But then... even with perfectly appropriate original frame rate... it still looks a lot smoother on a CRT.
What kb said. twice :)
ZMBV supports it, i don't know if the encoder dll supports fractional fps though (still looking for that source for that matter...)
Indeed - even after all those years it always surprises me how much of a difference it is
Quote:
Is 50.12 Hz an option for any current codec/container at all? :)
ZMBV supports it, i don't know if the encoder dll supports fractional fps though (still looking for that source for that matter...)
Quote:
But then... even with perfectly appropriate original frame rate... it still looks a lot smoother on a CRT.
Indeed - even after all those years it always surprises me how much of a difference it is
if yt and the capture chain supports it one could probably also capture in 100hz/fps to avoid the stuttering?
Quote:
if yt and the capture chain supports it one could probably also capture in 100hz/fps to avoid the stuttering?
Mostly you can change the refresh rate in your OS.
its about having a constant framerate in the capture. if the machine outputs 50 frames a second and you capture/play it with anything that is not 50 or a multiple of it you will get non constant framing in your video. which is why scrollers etc look like they are stuttering even if they are not.
Maybe someone need to code a multi-frame-support codec.
Any rational is acceptable as timebase (except of course for stuff like MPEG-TS, which has its own very high timebase), and nearly all containers will allow you to place frames on non-successive time points anyway. Most DVDs/Blu-rays are 24000/1001 (approx. 23.976), for instance. So encoding it is absolutely not a problem.
Multi-hz-display-support-software, every hz of a video, get automatically supported, that is currently enabled on your OS!? Is that even possible?
As said, you can add pretty much any display mode in the OS nowadays but you‘d have to do so for every refresh rate you want to play back. From then on it’s hoping that the screen actually supports the rate and doesn’t resample to its native one. I‘ve seen both in monitors big and small, expensive and cheap, so it’s mostly luck at that point.
As for format support and playback software, what Sesse said. No problems there (in theory).
Remains the question if there’s any equipment that is able to capture with the original signal timing (51.12Hz 288p with 312 actual lines per frame). Might be possible with a retro upscaler followed by some PCI HDMI capture card that comes with its own SDK. Someone find out :)
As for format support and playback software, what Sesse said. No problems there (in theory).
Remains the question if there’s any equipment that is able to capture with the original signal timing (51.12Hz 288p with 312 actual lines per frame). Might be possible with a retro upscaler followed by some PCI HDMI capture card that comes with its own SDK. Someone find out :)
50.12, sorry :) (17.7MHz PAL clock / 18 / 63 cycles/line / 312 lines/frame)
kb_: I'm moderately sure I have equipment that could do it in theory, but I never got to the point of actually trying it when I still did demoparty streaming :-)
(We managed to convert into a 720p50.12 Hz SDI signal; a Decimator would normalize it and framedrop, but the SDI capture card refused the non-Decimator signal. However, said capture card could run with a custom FPGA bitstream…)
As for playback, G-Sync/FreeSync would be pretty much the best bet I can imagine.
(We managed to convert into a 720p50.12 Hz SDI signal; a Decimator would normalize it and framedrop, but the SDI capture card refused the non-Decimator signal. However, said capture card could run with a custom FPGA bitstream…)
As for playback, G-Sync/FreeSync would be pretty much the best bet I can imagine.
Sorry, make that a 576p50.12 signal (IIRC).
Ah, right, VFR. I Always forget about that.
(note to self: check the BMD SDK for any hints their HDMI cards may be able to pull this off)
(note to self: check the BMD SDK for any hints their HDMI cards may be able to pull this off)
BMD cannot, we tried.
Damnit. Ok, Deltacast and Aja then (though I don’t think the chances are very high from the glimpses I had at the SDKs)
How about capturing the raw signal and using vhsdecode? Useless for live, of course…
Quote:
@Krill: Yeah, and it would get noticed by you, perhaps me, and other 7 people. It’s a battle lost. Also, interactivity never quite took root in demos. Even the press space is gone.
This might be a bit off-topic, but many early Amiga demos had multiple parts that would be accessed by pressing the left mouse button when you were ready to move on, and I saw a few Atari ST demos that had multiple parts accessed by a platform game (of all things), although I never saw the same on Amiga.
In the past nearly all demos had “press space” or “press LMB” to advance from part to part afaik. They were called “megademos” on Atari ST. This all ended with the invent of “trackmo”, when demos went into this “music video” audio/video sync direction with precisely timed editing, where they are now. And it’s a good thing they did imho.
Quote:
Quote:@Krill: Yeah, and it would get noticed by you, perhaps me, and other 7 people. It’s a battle lost. Also, interactivity never quite took root in demos. Even the press space is gone.
This might be a bit off-topic, but many early Amiga demos had multiple parts that would be accessed by pressing the left mouse button when you were ready to move on, and I saw a few Atari ST demos that had multiple parts accessed by a platform game (of all things), although I never saw the same on Amiga.
Here, an Amiga megademo with a platform "game" https://www.pouet.net/prod.php?which=19118 for your very own edification.
Quote:
Here, an Amiga megademo with a platform "game" https://www.pouet.net/prod.php?which=19118 for your very own edification.
Thanks, hitchhikr! I'm glad the Amiga has these kind of "game" megademos, I just didn't know how to search for them.