I have never seen that in any build of SheepShaver, but possibly it depends on what application and what version of Mac OS you are running under SheepShaver. I see different cursors just fine, including animated cursors, with no anomalies.


From my limited inspection of the code, I believe that SheepShaver is using the hardware Mac OS X cursor for better performance, while Basilisk II is laboriously erasing and redrawing the cursor under software control. No doubt the differences in behavior derive from the different approaches to cursor management.

There is a comment in the source implying that the developer of the SheepShaver cursor management code was considering changing Basilisk II to use it as well. I guess you're glad that hasn't happened!

Personally I've never used Basilisk II, but think I prefer having a single cursor on the screen.

It does not feel like having two cursors. The MacOSX cursor only appears when you move out of the BasiliskII window. It looks as if the MacOS cursor splits in two, one remaining inside the window and the MacOSX cursor continuing outside the window. The MacOS cursor follows the MacOSX cursor along the sides of the BasiliskII window and when you enter again the window it looks as if the MacOSX cursor merges with the MacOS cursor that continues inside the window. It feels very natural.

Anyway, none of the SheepShaver cursor problems and I have not noticed any performance problems. Maybe it was not such a good idea to use the hardware MacOSX cursor in SheepShaver.

Thanks for this build, this will make SS a lot more usable.
It seems like you only fixed the misaligned cursor problem for the text cursor, though. Drawing tools in HyperCard are still misaligned. There are probably a few hundred, if not thousand, different cursors in all classic Mac apps, so the proper fix is to align the cursor to its "hot spot" defined in the CURS resource.

Ronald and Cat_7, as a long-time WordPerfect user, I am grateful to you as well as to Gwenolé for your development and upkeep of SheepShaver. Having lurked in the forum for a long time, I finally registered to venture a suggestion regarding the cursor issue. Most of what I do in SS is word processing, so am grateful for the fix to the text entry cursor. Dr Lex is undoubtedly correct in pointing out that



Given that fixing this with the ,

seems likely to take some time, the earlier workaround, of replacing all app-specific or task-specific cursors with a generic arrow cursor, has the merit of at least allowing precise placement.

Might it not be possible to allow a preference to be set, or toggled, between that old solution and the current one? That way one could use the varied cursors as they are in your new build when word processing, and switch to an always-arrow cursor mode for doing other work.

Just a thought. Thank you again. Despite the few glitches, SS has made using older apps like WordPerfect and even ClarisWorks 4 a pleasure again. Classic wasn't very much fun somehow. Tom.

Indeed, as you will know from reading my web page, I was not attempting a general fix; in fact, I was not even attempting something that could or should be generalized. This was strictly a kludge to address the problem for the one alternate cursor that I care about, because it was irritating me daily. I do hope the developers will someday address the problem in a general way.

However, be aware that the CURS resource is not accessible in the code involved, and in fact, there appears to be no way (at that point in the code) to determine what the hot-spot should be. The API being used to set the cursor apparently supplies only a bitmap and a mask, and does not specify the hot-spot. The "solution" in the official source tree is to get the hot-spot from certain low-memory global variables (in the emulated Mac memory image) where it is expected to be stored; but as you know, that's not working.

I think I know why that is and what one would have to do about it as part of a general solution, but I lack the time and motivation to work on that right now.

I do agree that for most purposes a generic arrow cursor is preferable to a "correct" cursor with the wrong hot-spot. I'm not sure what earlier workaround you're referring to, though. Were there earlier builds that behaved that way? If so, I suspect it was not as the result of a deliberate workaround, but more of a felicitous defect.

My build does not change the shape or behavior of the cursor; it only changes the hot-spot, and does that only for the I-beam cursor. Its cursor behavior is otherwise identical to the current official source tree builds.

The July (Intel) and August (UB) 2007 builds were, as I understand it, deliberately programmed to replace custom cursors with an arrow cursor whose tip would thus always be at the hot spot. My information about this may come from the WordPerfect Mac list on Yahoo rather than from Emaculation, I don't recall now.

I have yet to try out your new build, kelvin31415, but am looking forward to doing so soon.

I see. That's before my time, and I've not visited the Yahoo discussion, but from looking at the change history of the three source trees involved (Basilisk II, SheepShaver and the SDL library) there are two explanations that seem plausible.

First, someone might have made a build with such a change in their own private source tree (similar to what I've recently done).

Second, someone might have made a build with a version of SDL more recent than SDL1.2.10. My observation is that any such build behaves as you describe, although from my examination of the source code, this appears to be unintentional (i.e., a bug in the interaction between BII, SS and recent versions of SDL).

There is no mention in the change history for the BII or SS source trees of any changes regarding cursor management since 2004. However, there were cursor-related things going on in the SDL source tree since then.

The Fink installation of SDL that people generally seem to use when building SheepShaver is SDL1.2.9.

I posted my latest snapshot, SheepShaver_KD_01_May_2008, at http://www.nomicro.com/SheepShaver.html. As noted earlier, this is not an "official" build; see details at my web page.

There is only one significant difference between this build and the one I posted earlier. After more investigation of the cursor hotspot issue, I still have not come up with a good way to fix the problem, but I have had reason to want other cursors to work correctly. Therefore, as a stopgap measure, I extended my cursor hack so that it will get the hotspot right not just for the i-beam, but for all of the cursors that I care about.

The code to do this is generated mechanically from a resource file containing a collection of CURS resources, which I extracted from the Mac OS 9 System file, ResEdit, MacWrite, Photoshop 3, and other sources. Apologies if I overlooked your favorite cursor.

No, this is not a general solution; it is a stopgap measure. It will never be incorporated into the official source tree, because, one hopes, an appropriate general solution will be devised eventually.

Thanks, I will use your build for now.

I still can't run BattleGirl, the best game ever. And sound still doesn't work.

Is there a chance sound will start working at some point in SheepShaver? And that games will be able to run without crashing the whole thing?

Thanks!

SheepShaver does not run all applications as on real hardware. That is especially true for many games that need hardware that SheepShaver does not emulate.

SheepShaver does support sound. You may need to select built-in sound output in Sound control panel. (In MacOS 8.5/8.6 the Sound control panel is installed in the Apple Extras folder, in MacOS 9 you will find the Sound control panel with the other control panels.)

I posted my latest snapshot, SheepShaver_KD_17_May_2008, at http://www.nomicro.com/SheepShaver.html. As noted earlier, this is not an "official" build; see details at my web page.

There are two significant differences between this build and the 01_May version I posted previously: first, I've implemented a general solution for the cursor hot-spot issue that works for all cursors; second, I've enabled cursor-hiding, so (for example) the cursor will hide while you are typing in a text-field, as it is supposed to.

This has received limited testing, and there is no guarantee that my changes will work properly with all ROMs and all versions of emulated Mac OS. Please respond here if you observe any anomalies.

Interesting! Would this be a solution that is worth to add to cvs?

I think it's worth considering. Being a heuristic approach, it is not ideal, but a better solution would probably have to involve devising a ROM patch. That would require a great deal more effort, by a developer with access to all of the supported ROM images, and sufficient knowledge of Mac OS internals. My approach has the virtue of simplicity, and involves changing only the SheepShaver video driver.

By the way, while researching this I came across an interesting function in the SDL library. If you type control-F5, you will toggle a cursor mode that resembles the Basilisk behavior that you have mentioned previously. I do not know the purpose of that mode, and it appears to be buggy, but it is certainly interesting.

Indeed interesting, but the BasiliskII behavior is very different. You really should try BasiliskII to see how it works and feels. Because it draws its own cursor inside BasiliskII, it does not need cursor corrections. All cursor images in all applications are drawn as they should be. And while each time the other cursor takes over at the edge of the window, it does not feel like having two cursors. I still think that the behavior in SheepShaver should be reversed to the BasiliskII behavior.

OK, I decided to try Basilisk II. What I observe is that when I move the cursor outside the BII window, the "real" cursor appears; the BII cursor continues to track around the outside edge of the BII window as I move the mouse around, as long as BII is in the foreground. When some other app is in the foreground, the BII cursor stays wherever it was.

I don't feel any strong preference for either approach, but the BII way certainly would have spared all of us the cursor bugs in SheepShaver. Perhaps the software cursor performance was poor in SheepShaver back when the developers were working on the new approach, but on modern machines it seems acceptable.

There is one thing I don't like about the software cursor approach, and that is the "cursor trails", which are flickery and somewhat annoying. I suspect there must be a way to turn those off.

It might be worth petitioning the developers to implement a selectable option for software vs. hardware cursor, but I don't know how much effort would be involved. Nor have I had any luck getting a response from the developers.

Hi,

Thanks for the effort to make life with SheepShaver more bearable
Contacting the developer can be difficult sometimes, as he seems to "forget" about the emulators for months in a row. I guess he has a life too and might be less interested after all those years. I can understand that.

Best wishes,
Cat_7

Yes, none of the cursor bugs in SheepShaver, that is exactly what I meant.


Maybe that is what is meant with performance problems? It is least obvious with the 'Window Refresh Rate' set to "60" or to "Dynamic" in the GUI app. (These settings equal to frameskip 1 and frameskip 0 respectively in the prefs file.)

I posted my latest snapshot, SheepShaver_KD_31_May_2008, at http://www.nomicro.com/SheepShaver.html.

The zip file linked at that web page now includes two different builds of SheepShaver: one uses a "hardware cursor", and the other a "software cursor". For details, see the last three paragraphs of the web page. As noted earlier, these are not "official" builds; please read the web page before downloading.

Alas, despite some efforts, I've been unable to work around certain behaviors of the SDL library that prevent me from making the choice of hardware vs. software cursor a runtime option.

If you are happy with the previous build (17 May) there is no reason to update, as the current "hardware cursor" version is essentially identical to that.

Hi,

Great to see you are putting effort into SheepShaver, it is missing that for a long time now

Both version work well on my 10.5.3 Hackintosh.

It might be some wishful thinking, but it seems the hardware cursor version looks (is) a bit snappier.

Best wishes,
Cat_7

Thanks a lot indeed for putting time into this! I'm not going to try the software cursor version, because the previous build works good enough for me. But it's probably a good idea future-wise that you're trying to make it work with more recent versions of SDL.

Thank you, thank you, thank you!

The software cursor version finally provides the correct cursor images and cursor behavior in all my applications!

For best software cursor performance, I need to manually edit ".sheepshaver_prefs" to set "frameskip 0". That value for frameskip can not be set with SheepShaverGUI or SheepShaverPrefs, but SheepShaver apparently uses it. In BasiliskIIGUI the setting for frameskip 0 is the Window Refresh Rate "Dynamic".

I thought you'd like it.


Thanks for the tip! I had been using frameskip 4, and setting it to 0 makes a real difference.

Thanks for the positive feedback from you other folks as well. I'm glad to be able to contribute something to the SheepShaver community.

I posted my latest snapshot, SheepShaver_KD_14_June_2008, at http://www.nomicro.com/SheepShaver.html.

Only one change has been made: an environment variable is now set in the application's Info.plist file to restore normal behavior of command-clicks and option-clicks. If you're happy with the version you're currently using and have not missed the ability to use command/option-click, then there's no reason to upgrade.

As always, details are explained at my SheepShaver web page.