August 1, 2009

There is now a Mini vMac 3.1.2 beta. The Mini vMac Variations service has been updated. As usual for Mini vMac, "beta" also means "release candidate". I don´t know of any problems with it, and if no problems are found in a reasonable time, it becomes the official release version. (But it is more likely that there will be another beta or two.)

The Macintosh and Windows versions now match the X version in not initially filling the sound buffer with silence, but instead waiting to accumulate real sound samples before starting to play sound. This may reduce the tendency to stutter as the program starts, mostly by giving the emulation more time to get settled into a regular rhythm before attempting sound. I also changed the X version to match the Macintosh and Windows version in only skipping a single sound block on underrun, rather than stop playing sound until the buffer is refilled.

There is also much more work done on sound, but it is disabled for the time being. A Mac Plus plays sound samples ranging from 0 to 255, but when not playing sound it often doesn´t leave the level at the midpoint 128, but at some other value like 0. This can causes clicks when the emulation is paused. To reduce clicks, Mini vMac currently contains a deliberate inaccuracy in setting the sound to level 128 when sound is disabled instead of 0. I´d thought I´d try a different approach and instead have Mini vMac notice when the emulated computer is outputting a constant sound level, and then gradually shift real sound output to the midpoint. When the the emulated computer begins outputting sound again, the real output is first gradually shifted back to where it was. Unfortunately this approach didn´t seem to work, at least on a Mac OS X 10.5 on Intel. The shift was clearly audible. No matter how gradually Mini vMac shifted the sound level, the operating system seems to think, there´s sound here, but it´s really faint, let´s amplify it so you can hear it clearly. Eventually I found that converting to 16 bit sound avoided this "feature". But this is starting to get too major a change for too subtle a benefit, so soon before release, so I´ve disabled this code for now.

There is now a build system option "-vsync 1" for OS X only, which turns on OpenGL double buffering and sets AGL_SWAP_INTERVAL to 1. This eliminates the "tearing" issues noted Manuel Alfayate. Unfortunately it isn´t yet a real solution. Beside using much more memory, it also reduces the maximum speed of emulation unpredictably and erratically, because it makes aglSwapBuffers block until the vertical retrace, when Mini vMac is expecting to give the emulation extra time, for above "1x" speed. Anyway it helps to illustrate the issue. Now that I´ve seen what it looks like with vsync, I can see the difference in certain games. [update: I´ve added variation 159 to demonstrate this option.]

Control-P now gives some visual feedback, displaying the message "Registration String copied".

A bug is fixed in alternate keyboard mode that could result in the emulated ´;´ key being left stuck down.

Entering full screen mode immediately after launch in OS X 10.5 wasn´t working properly. The title bar would show at the top of the screen. This seems to have broken because I tried avoiding the deprecated call aglSetDrawable. There actually seem to be two bugs of Apple here. aglSetWindowRef didn´t work quite right on a window without a title bar, so I had changed it to use a normal window, but now this problem turned up. So I´ve reverted back to the Mini vMac 3.0.4 method of using aglSetDrawable on a window without a title bar. It´s probably not worth verifying that these actually are Apple bugs, instead I should be moving Mini vMac to the Cocoa API, and then it might be worth reporting bugs.