Difference between revisions of "User talk:Francis"

From Emulation General Wiki
Jump to navigation Jump to search
m
Line 6: Line 6:
  
 
:::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. --[[User:Syboxez|Syboxez]] ([[User talk:Syboxez|talk]]) 14:55, 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. --[[User:Syboxez|Syboxez]] ([[User talk: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.
 
::::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.

Revision as of 04:30, 7 March 2018

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)