mirror of https://github.com/bsnes-emu/bsnes.git
Update to bsnes v038r03? release.
I haven't posted the new WIP, just updating on the status of it. First, I noticed that Xorg changed the keycodes, at least for Kubuntu 8.10. belegdol, the other person at RPM fusion was mentioning that he was getting weird key mappings like page_down for left, etc -- this would be why. Didn't realize they were variable like that. I went back and made a lookup table to convert the official keysyms to keycodes, so this issue should now be fixed. Anyone packaging bsnes is free to update to the latest WIPs to fix this if they like. Second, I added "adjust" to brightness/contrast/gamma, and they all start at 0% centered, go to -95% and +95%. Still not sure what to name "Frequency adjust", so I left that alone for now. Third, I updated the ~400 or so %0.nx sprintf statements to %.x, so that GCC 4.2+ will shut the hell up. Lastly, I can't come up with a good double->string conversion routine (causes subtle rounding errors with the obvious approach), so I wrapped strdouble() around snprintf. bsnes doesn't even use it yet, but at least it can now ... > How would dropdowns be better than what ZSNES is currently using? The WIP link on Rapidshare is dead ... what are they using? If it doesn't involve tab panels, then I can do that. > Wouldn't these just be hardware filters like NTSC that simulate the > lossy characteristics of certain type of analog output? These are settings _for_ the NTSC filter to affect its quality. They don't affect any other filters. > There's no fundamental difference between a coprocessor and central > processor in the scheme of emulation. That the coprocessor happened > to be located on what we would physically categorize as the > "cartridge" is immaterial. There's quite a large distinction between something inside the SNES and outside. I understand where you're coming from, but we shouldn't pretend as though the SNES contains all these chips, either. Sheesh, I don't even know what we're discussing here anymore :P > You'd be crazy to externalize all your code just to allow people to > create imaginary 10ft boards with 2ghz GPUs. What I wouldn't give for just one person to make such a board ... :D > The only invaluable option in that entire section is overload's > gamma curve, everything else about the image can be destroyed in my > video driver or monitor settings. Haven't we covered this in the past? SNES games were played with gamma, etc settings calibrated to NTSC / PAL televisions. Monitors are calibrated very differently. I doubt anyone wants to go into their driver control panels to adjust these settings every time they start and close the emulator. And cheaper drivers (especially on Linux) may not have these options at all. Not saying we have to go crazy here ... I'm happy to leave out hue/saturation settings. > I am aware that any changes made to WIP releases are posted here on > this forum, but maybe it's an idea to start including those as well > on the WIP download page? I _could_ ... but it's easier to type things up here later on at my convenience :/ [No archive available]
This commit is contained in:
parent
9a8203b3c3
commit
6cacb2517a