User talk:Francis

From Emulation General Wiki
Revision as of 02:27, 8 March 2018 by Tommy (talk | contribs)
Jump to navigation Jump to search

Stupid question, probably, but I'm the author of CLK and thereby noticed your addition to Sinclair ZX81 emulators, for which I am very grateful — especially as I was unaware of this resource. I was curious though as to why it isn't recommended. Is it just through obscurity, or is there a known issue with it? As may be implied, I'm interested in harvesting bug reports if any are known. — Tommy (talk) 15:02, 5 March 2018 (EST)


Alas, that's a shame. I thought maybe I might just get an actionable bug report out of this. Regardless, thanks for noticing my little effort and considering it worthy of inclusion. — Tommy (talk) 10:40, 6 March 2018 (EST)


I could give some advice if you would like CLK to be recommended for the consoles that it emulates very well that shouldn't be too difficult to implement. For one, add an easy to use frontend for all platforms (Linux included, and sadly Windows support is a must, but you could have a universal Qt or GTK based UI for example). Second, add an option to disable CRT emulation and/or certain aspects of the CRT emulation. I, for one, play all my games on CRTs anyway, and I also like to play my games from real hardware at the highest possible quality, even if that requires mods. Many people like the sharp pixel look, and others like the CRT emulation (TL;DR options are good). Almost all emulators start out as being not recommended until it has been in use for a while and proven to be good and ready to recommend over (or in addition to) other popular emulators. If CLK is highly accurate, but the other emulators are as well, the UI and features would be the differentiating features. Another neat thing would be to support libretro, as many people (me included) like to have all their emulators be available from one common UI. This is not required to be recommended. --Syboxez (talk) 14:55, 6 March 2018 (EST)


Then I think being recommended isn't an achievable goal. A completely non-negotiable part of the CRT are the phase-locked-loops tracking sync as those are what produces a 2d image rather than a 1d one, especially from the Atari and ZX8x where sync is programmatic.
Phosphor decay simulation is why I can produce frames at 1/120th of a second latency on a 120Hz monitor without the perception of tearing, and don't suffer from the same juddering presentation of PAL on 60Hz computers as every other emulator I'm aware of. So I'd be wary of eliminating that as it'd make things worse for the 90% use case.
Composite colour is already optional on all machines where the real hardware has any concept of RGB (or no concept of colour whatsoever), so it's only the Atari and Vic-20 on which it's non-optional. In both cases because I'm so idiotically obsessed with modelling the real hardware that I'm generating the composite signal like the originals do. Not from an RGB intermediate. There is no clean RGB buffer, anywhere, at any point. You would be justified in calling it accurate to a fault. So I'm shooting myself in the foot there re: any hope of being 'recommended', but at least now consciously.
(footnote: the CPC is RGB only, the ZX80/81 don't even produce a colour burst anyway, and the Electron, Oric and MSX all had real-life RGB outputs.)
Libretro is not an easy option because it obstructs too much GPU functionality by requiring OpenGL 2.0 and/or ES 2.0 as a target. Specifically, both predate GPU support for integers and I'm doing quite a lot of byte unpacking over there. It also seems to want to box you in to a single thread, which is less troublesome but would make the program unsuitable for modern processors and introduce a big loss would in audio processing, which is currently on a separate thread because it allows me to buy a further latency reduction: it allows me to do audio on demand decoupled from frame generation with the OS dealing with the net scheduling. Doing it myself would probably put me back into classic emulator territory of always having at least a frame's worth queued; at the minute I get an average 7.5ms latency (i.e. less than half a 60Hz frame) regardless of frame rate.
Oh well. As a result of what I'd have to forego, I really think that not being 'recommended' is producing a better piece of software. — Tommy (talk) 23:30, 6 March 2018 (EST)
I didn't realize how deeply entrenched the CRT video rendering is. In this case, I'd think that you would just need to add a nice UI, and we can recommend it for the systems that it emulates well with an added note that CRT emulation is forced due to the way the emulator works. I know for a fact that the Atari VCS generates a separate Luma and Chroma signal since I made a circuit for mine to convert that to standard S-Video. I'm not sure about the VIC-20, but I know the C64 also has separate Luma and Chroma lines). I think if real hardware can generate better video with mods, then an emulator should be able to as well, but that's just my personal opinion.
Also a question, if the display I'm using matches the refresh rate of the original console exactly, is the CRT blur essentially disabled? As mentioned before, I already use a CRT, even for emulators, and having that effect doubled is undesirable. I also don't think that forced flicker is necessary. I'd like your opinion on this. --Syboxez (talk) 17:12, 7 March 2018 (EST)
I agree; lack of a GUI on Linux and lack of anything whatsoever on Windows is problematic. And lack of S-Video support is very lazy. Must work harder. The 6560 in the Vic-20 does indeed offer separate chroma and luma, so that's no excuse.
I have a ticketed item on when refresh rate matches the original console either exactly or close enough but have not yet carried it out. I agree with the Analogue NT-type approach that nudging the speed of emulation a little this way or that if it causes it to agree with the output device is what most people would want.
I hadn't seriously considered the proper thing to do when the output screen is already a CRT. I'll have to think about that. — Tommy (talk) 21:27, 7 March 2018 (EST)