ChanServ changed the topic of ##yamahasynths to: Channel dedicated to questions and discussion of Yamaha FM Synthesizer internals and corresponding REing. Discussion of synthesis methods similar to the Yamaha line of chips, Sound Blasters + clones, PCM chips like RF5C68, and CD theory of operation are also on-topic. Channel logs: https://freenode.irclog.whitequark.org/~h~yamahasynths
_whitelogger has joined ##yamahasynths
TD-Linux has quit [Ping timeout: 264 seconds]
Lord_Nightmare has quit [*.net *.split]
epsdelphi has quit [*.net *.split]
TD--Linux has joined ##yamahasynths
epsdelphi has joined ##yamahasynths
Lord_Nightmare has joined ##yamahasynths
TD--Linux has quit [Changing host]
TD--Linux has joined ##yamahasynths
TD--Linux is now known as TD-Linux
_whitelogger has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
futarisIRCcloud has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
bofh_ has joined ##yamahasynths
bofh_ is now known as mofh
futarisIRCcloud has joined ##yamahasynths
andlabs has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
andlabs has joined ##yamahasynths
andlabs has quit [Ping timeout: 268 seconds]
l_oliveira has joined ##yamahasynths
_whitelogger has joined ##yamahasynths
<Sarayan> whitequark: I don't see a workaround to apply to groupxiv from that discussion
<whitequark> no other changes
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
andlabs has joined ##yamahasynths
<Sarayan> that's gross, but it seems to work extremely well
<whitequark> Sarayan: that's the only reasonable way i can see to support non-power-of-2 differences in scale between layers
<whitequark> Sarayan: should that viewer have some kind of a transparent overlay? or maybe a hotkey to switch between layers
<Sarayan> wq: I don't know what the smartest way would be
<Lord_Nightmare> ej5: P7 phosphor I think is used in the canon cat monitor. I'm not sure WHY, but it is, i recognize the bluish color, fading to yellow
<Lord_Nightmare> and the very long persistence
<Lord_Nightmare> unless theres another phosphor which has a similar color fade/profile
<Sarayan> LN: Did you ever study fade profiles of phosphors in vector monitors?
<Lord_Nightmare> no
<Lord_Nightmare> the most recent vector monitor i saw was one on a tempest machine at agdq, and i'm not even sure that was a real vector monitor, it may have been a raster crt with a rare vectorvga fpga board on it
<Lord_Nightmare> those vectorvga devices were sold around 2006-2008 and are very sought after, though are actually not a very good implementation of an fpga-and-framebuffer-based vector simulation
<Lord_Nightmare> i was discussing that problem with kevtris and we came up with a much better scheme than vectorvga used using a framebuffer with a countdown per pixel (maybe 32 bits per pixel?) for rgb888 and a 256 or maybe 65536 (if 40 bits per pixel) value countdown from when it was written, in frames, which applies a transformation per pixel to the r, g and b value (or yuv/yiq, whatver color space works best) to implement persistence fading
<Lord_Nightmare> properly
<Lord_Nightmare> done up on the fpga as a sort of fixed function shader
<Lord_Nightmare> I think the way the vectorvga worked was by optimizing the adc input reads down into what it assumed were single line segments and adding them to a display list which it then trimmed the tail end off of after a certain point or time countdown
<Lord_Nightmare> which works, but can have artifacting issues, and doesn't emulate true persistence fade
<Lord_Nightmare> since the vectorvga is literally reading the analog x and y deflection from the board, it had to guess what a line segment was, assuming my guess of how it works is right
<Lord_Nightmare> i could be wrong, and maybe vectorvga did implement a discrete 1024x1024 or so framebuffer and some sort of crude persistence system too
<Lord_Nightmare> but it didn't work super well
<Lord_Nightmare> it also did VGA (640x480 i or p? or is it 800x600 i or p? i'm not sure...) output
<Lord_Nightmare> it may have been 1024x768
<Lord_Nightmare> whatever the case the vectorvga has been discontinued for years
<Lord_Nightmare> and making a device that can do extremely fast rasterization of a vector input plus rgb into something that can be displayed on either a crt or hdmi would be very nice
<Lord_Nightmare> would be even better if it does proper bloom
<Lord_Nightmare> i.e. each pixel has not just a persistence countdown but a 'saturation' field which goes up the longer the beam points at it
<Lord_Nightmare> and if it overflows the saturation/luma bleeds to the 4 adjacent pixels (this can be done as 2 shader passess i guess for propagation to upper right and lower left?)
<Lord_Nightmare> this would allow the 'super bright' dot for the shots in asteroids and asteroids deluxe to be emulated
<Lord_Nightmare> another thing that needs doing is detecting when the vector beam is pointing outside the screen border
<Lord_Nightmare> for star wars vector arcade
<Lord_Nightmare> since that reflects off the sides of the vector crt tube and splashes luma across the entire screen
<Lord_Nightmare> used in big explosions
<Lord_Nightmare> a proper fpga device could do all of this
<Lord_Nightmare> the vectorvga was a good but flawed attempt
<Lord_Nightmare> what an fpga cannot do (and no non-vector crt can) is super bright dots like the astreroids games did
<Lord_Nightmare> since that requires setting the crt contrast/brightness on a raster crt SUPER HIGH and displaying the game at very low brightness except for those shots
<Lord_Nightmare> again, it could be handled in a calibration menu displayed to screen on the fpga thing
<Lord_Nightmare> and it won't ever work right on an lcd (might work on a plasma)
<Lord_Nightmare> Sarayan: i hope that answered your question, but tl/dr: No.
<Sarayan> huhu. I think on modern hardware it should be done in HDR with a good luma mapping
<Sarayan> so you can dynamically darken everything when there are super bright dots somewhere
<Lord_Nightmare> hdr sounds like the right solution, though i don't know the specifics of how it works
<Lord_Nightmare> does it have a 'local brightness' for each pixel, which scales the RGB values and hence can put them 'out of gamut'?
Xyz39808 has quit [Ping timeout: 252 seconds]
<ej5> i'd be fascinated to see a modern emulation using a GPU
<ej5> you could nail the blooming effect when the brightness goes high enough that the focus pulls
<ej5> seems to me it wouldn't be all that hard, the 3d hardware could handle the wireframes easily enough, and the phosphor effects would be entirely pixel shaders
<Sarayan> LN: essentially it means rgb is floating-point, not 0-255
<Sarayan> ej5: Yeah, you can gaussianize the blur analytically
Xyz_39808 has joined ##yamahasynths
<Lord_Nightmare> ej5 the trouble is you can't get the raw wireframes out of the atari vector hardware unless you do some creative tapping of the vector drawing state machine. what you do get is analog x/y deflection voltages, and an r, g and b signal (or just a luma signal for non-color games)
<Lord_Nightmare> some games may have a brightness signal separate from r, g, b?
<Lord_Nightmare> so its up to the fpga to filter the incoming signal to figure the wireframes out from that
<Lord_Nightmare> and the faster the beam moves the dimmer the beam is