dirkwhoffmann / vAmiga

vAmiga is a user-friendly Amiga 500, 1000, 2000 emulator for macOS

Home Page:https://dirkwhoffmann.github.io/vAmiga

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Strange behavior with video effects + 2.1b4 feedback

nicolasbauw opened this issue · comments

Today, I wanted to try the latest beta on the macbook pro I use for work. It's an Intel machine, I use it with the exact same monitor than my M1 mac. Note : I don't know if it's a 2.1b4 issue (I don't think so), I've never tried vAmiga on this machine before.

I noticed that the video effects menu behaves completely different than on my M1 machine:

  • for instance, when I change the dotmask, change is not taken into account unless I reset it to "none". But sometimes, it's taken immediately into account.
  • the masks looks completely different than on my M1 machine, especially the bisected mask. It looks nice and subtle on my M1 machine, and on the Intel one it looks ugly and has a moiré pattern:

image

That seems very strange. I don't even think that's an emulator issue. It's not an important issue for me : I mainly use my M1 machine for vAmiga. I just wanted to report what I noticed.

I can add that on my M1, so far the 2.1b4 works very well, for instance, I do no longer encounter a minor graphics glitch in the dune game. I nearly have the exact same sensations than on a real Amiga, which is the most important aspect for me. One last big thing missing is the vsync : the animations are really not smooth. It's close to perfect.

@nicolasbauw Thanks for your positive feedback!

I've just run vAmiga on both my Intel and my M1 machine with dotmasks enabled, but I didn't notice any difference. The dotmask effect is applied in the fragment shader to avoid Moiré patterns (with the drawback that the dot size varies between machines). The appearance of a Moiré pattern indicates that your Intel machines applies some rescaling at the very end of the graphics pipeline. Could you check that both of your machines are configured to use the native screen resolution in the Mac display settings?

when I change the dotmask, change is not taken into account

I failed to reproduce this issue on both of my machines. I also did a small code review, but didn't find anything (of course there is always the chance that I've overseen something). In theory, changing the dot mask should take effect immediately. The change might be invisible due to rescaling (which seems to happen on your Intel machine) and there is only a subtle difference between the two bisected masks and the two trisected masks (I had problems on my machines to spot the difference without magnifying). However, changing from a bisected to a trisected mask or vice versa should make a visible difference that can be seen with the pure eye.

Could you check that both of your machines are configured to use the native screen resolution in the Mac display settings?

image

That's it. Both machines use a scaled resolution, but a different one, hence a different render. Sorry for that, I didn't even think about it. Note : on a 4k display, using scaled resolution is a must, otherwise everything is so big on the screen. That's why I don't use "default for display" setting.

In theory, changing the dot mask should take effect immediately.

Indeed, this morning it does, both on default or scaled display. I don't know why it behaved differently the other day. What still happens is : at launch, even if the mask is set by default on "bisected", it behaves like it's set on "none". I have to go to the menu, change from bisected and any other option, and then go back to bisected for the display to effectively use the bisected mask.

In fact, it looks like it's this only machine that behaves strangely with this menu item in vAmiga. If you don't notice anything particular, you can close the issue.

What still happens is : at launch, even if the mask is set by default on "bisected"

Confirmed. This was a bug. On launch, vAmiga computed the initial dot mask texture with brightness = 0. Later, when brightness was read from the user default storage, it didn't recompute the texture.

It'll be fixed in the next release.

Fixed in v2.1b5