Dynamic screen resolution for portrait/landscape? about minivmac4ios

[zydeco]

Unfortunately this is not possible with Mini vMac (without a lot of hacking I think – even in Macintosh II emulation the resolution is set at compile time).

You can try my iOS port of BasiliskII, which lets you switch the resolution at runtime (in the emulated Mac's control strip, or Monitors control panel), and adds landscape/portrait resolutions based on the device it's running on.

[zydeco]

Since the keyboard system is the same on both emulators, it's ok to talk about it here. I never got around to making a graphical editor, but to create the layouts I put together a small app with the keyboard classes and ran it on the simulator, and it had a reload button to see the changes quickly, I'll see if I find it.

When I was looking into the pencil support, I didn't find a satisfactory way to decide when to ignore non-pencil touch events, checking if the pencil is connected through Bluetooth seems error prone (what if it's connected but you're not using it?). But maybe an option in settings would be enough to solve this. I'll give it a look again this weekend (I have a pencil now).

[gingerbeardman]

Yes, I managed to get it building on Xcode 12 by deleting the VERSION file. Maybe a bit too severe a solution? Then a few more errors regarding spinlock I simply commented out the related lines.

Did you think about putting this on AltStore like you did with minivmac? I have a private ad-hoc build I share with a couple of friends but it's not ideal.

[gingerbeardman]

Thanks! I'll try that.

[gingerbeardman]

Sadly @zydeco I'm unable to build your iOS port of BasiliskII to either the Simulator or device.

I get three errors regarding pointerInteraction.

I see that's used with #ifdef __IPHONE_13_4 in various places, but I'm at a loss how things need to be setup. I've just loaded and immediately built the project with no changes other than Signing Team ID.

I'm using Xcode 11.3.1 on Mojave 10.14.6, highest iOS I can target is 13.3 but I am leaving it as it came targeting iOS 8.0.

Any pointers?

[zydeco]

What version of Xcode are you using?

[gingerbeardman]

I'm using Xcode 11.3.1 on Mojave 10.14.6, highest iOS I can target is 13.3 but I am leaving it as it came targeting iOS 8.0.

Anyway, I just commented out the follow lines:

if (@available(iOS 13.4, *)) {
    pointerInteraction = [[UIPointerInteraction alloc] initWithDelegate:self];
    [pointingDeviceView addInteraction:pointerInteraction];
}

And it's building 👍

[gingerbeardman]

It seems that code is to enable mouse support. I'm OK to miss that until I upgrade.

BasiliskII is working great!

I only had to switch from 7.1 to 7.5.5 to be able to access Monitors with resolution change.

[gingerbeardman]

Just to say thanks once again.

I did a custom build adding on two more resolutions:

    [videoModes addObject:[NSValue valueWithCGSize:CGSizeMake(512, 342)]];
    [videoModes addObject:[NSValue valueWithCGSize:CGSizeMake(512, 683)]];

And made it so that nearest neighbour scaling is always on

    NSString *filter = kCAFilterNearest;
    videoLayer.magnificationFilter = filter;
    videoLayer.minificationFilter = filter;

so that I can have a more chunky "half-resolution" display. useful because drawing single pixels is easier if they're bigger.

[gingerbeardman]

@zydeco I've noticed that when doing the above to get half-size extra-chunky graphics, there is an irregularity every so many pixels resulting in some rows/columns being less tall/wide than others even though the total pixel width is correct (512 into 2048 leaves no remainder). These irregularities stay fixed as I move windows resulting in those columns/rows resulting in a sort of pixel shimmer.

Could this be a tile rendering issue?

Any thoughts @zydeco?

Screenshot:
Simulator Screen Shot - iPad Pro (12 9-inch) (3rd generation)

[gingerbeardman]

Ah, it seems that 512x683 isn't filling the screen when it ought to be. I'll look into this.

[gingerbeardman]

I have no idea why that's not filling the screen, but I ended up at these resolutions to work around the problem.

[videoModes addObject:[NSValue valueWithCGSize:CGSizeMake(512, 672)]];
[videoModes addObject:[NSValue valueWithCGSize:CGSizeMake(683, 502)]];

edit: maybe something to do with the home indicator?

[gingerbeardman]

Let me know if there's a better place for me to ask BasiliskII for iOS questions.

I'd like to create/edit a custom keyboard, is there a visual app to manage the JSON or were they generated by hand or some other way?

https://github.com/zydeco/macemu/tree/ios/BasiliskII/src/iOS/Keyboard%20Layouts

I'm currently looking at Apple Pencil mode as well as this.

Thanks! @zydeco

[gingerbeardman]

@zydeco I've set up discussion thread here: https://www.emaculation.com/forum/viewtopic.php?f=6&t=11149

I'm trying to add some features (Apple Pencil, mostly) but I am very rusty with Objective-C so please let me know if they are unrealistic for a born-again-noob (me). Thank you!

I created a modified keyboard for my particular use case (Deneba artWORKS) by renaming and remapping some keys in the function key cluster.

[gingerbeardman]

Thanks!

I've been looking at SpeedSketch (Apple example code, Swift) and that uses two StrokeGestureRecognizers: one for Finger and one for Pencil. It tracks the time of the last Pencil interaction and times out after a while or when the pencil is docked. If Pencil is being used to draw then one finger can be used to pan the view, if finger is being used to draw then two fingers can pan. It's quite elegant.

I believe palm-rejection comes for free when using pencil to draw? I'm not sure of the technical details.

Here's my custom keyboard for the drawing app I use, artWORKS/UltraPaint, most common keys start top left and work their way across. Right edge are utility functions that trigger KeyQuencer macros to change screen resolution, etc. Behind the scenes there are all the function keys plus space and enter and modifiers. I operate with my left thumb whilst drawing right-handed.

Holding space in most art apps enters pan mode, allowing you to drag the canvas, so it's a useful key to repeat here. A single finger touch when using Pencil would be good as equivalent to holding down the space bar.

Oh, I also removed "sticky" from all modifier keys as I personally find it more frustrating than helpful. That could be a user toggle.

[gingerbeardman]

It would be very useful to have custom resolutions - for both landscape and portrait - that exclude the area needed for the keyboard, so it can be left up at all times and not overlap the working screen area.

Let me know if you want me to have a go at that? Currently I hard code them for my device, so would need to write proper code to calculate this.

I mostly use my iPad Pro in Portrait, with chunky pixels, and a screen height that stops just before the keyboard, which gives an almost square display in portrait and a very wide display in landscape.

[gingerbeardman]

When I was looking into the pencil support, I didn't find a satisfactory way to decide when to ignore non-pencil touch events, checking if the pencil is connected through Bluetooth seems error prone (what if it's connected but you're not using it?). But maybe an option in settings would be enough to solve this. I'll give it a look again this weekend (I have a pencil now).

@zydeco did you have a chance to take a look?

[gingerbeardman]

Hi @zydeco I upgraded to Big Sur 11.3.1 these past few days. The macemu code as it is won't build on Xcode 12, some errors regarding qemu(?) and more. But good news is that you can still use Xcode 11.7 to build it.

I'll take a look at the changes required. Cheers!

[zydeco]

When I was looking into the pencil support, I didn't find a satisfactory way to decide when to ignore non-pencil touch events, checking if the pencil is connected through Bluetooth seems error prone (what if it's connected but you're not using it?). But maybe an option in settings would be enough to solve this. I'll give it a look again this weekend (I have a pencil now).

@zydeco did you have a chance to take a look?

Sorry, I haven't had time to look into this yet.

Hi @zydeco I upgraded to Big Sur 11.3.1 these past few days. The macemu code as it is won't build on Xcode 12, some errors regarding qemu(?) and more. But good news is that you can still use Xcode 11.7 to build it.

I'll take a look at the changes required. Cheers!

It seems this is caused by the C++ header search order and case-insensitive file system, it now picks slirp's VERSION file for #include <version>, a workaround is to rename the file 🤷

I haven't implemented "portrait with space for keyboard" resolution yet, since it depends on the chosen keyboard layout, and the keyboard is not created yet, but I've fixed the custom resolution option which wasn't having any effect.