I’m unable to create a project or open any examples because of an “Access violation.” When creating a project it does dump a bunch of files into the project directory, but ultimately fails to go any further because of “EAccessViolation.” When trying to open an example (I specifically tried the platformer one) I simply get “Access violation.”
I’m not sure if this is a bug or user error that’s why I’m posting here. castle-editor.app has full disk read-write access but maybe there are other permissions I need to grant? I’m on an iMac 20,2 and have have Castle Engine 7.0, Lazarus 3.2, & FPC 3.2.2 installed. Any help would be appreciated, thank you.
Thank you for the report!
I tested today our latest Castle Game Engine download on a mac machine (macOS Monterey, 12.7.2, Intel-based) and indeed I can reproduce the problem.
This is 100% a bug on our side, not on you, and I’ll see how to fix it today/tomorrow. After a quick experiments now, it seems related to some Lazarus 3.2 change – the crash is at instantiating the list view that we do when we display initial project form. It’s inside LCL code dealing with list view using Cocoa. But regardless of whether it’s in Castle Game Engine or Lazarus, I’ll want to solve it / workaround somehow.
Note: Experimenting, I also saw new warnings that castle-engine command-line tool is untrusted. I thought initially that maybe this is responsible for EAccessViolation, but it was unrelated. I however extended the advise on macOS | Manual | Castle Game Engine to
So before using the engine please run all the binaries in bin subdirectory once, by right-clicking on them, and accept the warning that they are unsigned applications. Do this at least for castle-editor, castle-engine and castle-model-viewer to use the engine comfortably. Note that castle-engine is command-line, and running it like this will just print the help message — that’s fine, it’s just to make macOS remember that you trust this application.
Anyhow, this seems unrelated to the EAccessViolation problem.
Thanks again for reporting! This is critical problem on macOS. Sorry, sometimes such macOS-specific problems can slip in, due to most engine devs testing on Linux or Windows. Will fix ASAP 
1 Like
Sorry it takes while, this is still on my TODO to look at ASAP (I just have too many such TODOs ) But I really have to look at it this week.
Note that Lazarus 3.4 was just released, Lazarus Release 3.4 , this may also help – since the bug seems to be a regression in Lazarus 3.0 / 3.2. Maybe the fix will be as simple as upgrading to Lazarus 3.4 to build CGE editor.
1 Like
It’s okay I know you are very busy, I understand it will take some time. I tried what you said, upgraded to Lazarus 3.4 and build castle engine from source but it unfortunately has the same issue.
Thank you for keeping me up to date on the status 
Fixed!
-
A simple fix to Lazarus code was necessary. I made it, and submitted to Lazarus developers on Tolerate AValue = nil in TCocoaWSCustomListView.SetImageList (!291) · Merge requests · FPC / Lazarus / Lazarus · GitLab
Hopefully they will apply this to the next release.
-
The next CGE downloads on macOS, available on Download | Castle Game Engine in a ~few hours will be made using the Lazarus 3.2 + with this fix applied. (I will make sure they are done and post a note in this forum thread.)
I did some testing today with this Lazarus, everything seems to work OK. Creating new project, opening existing project, compiling and running the project works.
Note: I also updated Supported compilers and IDEs | Manual | Castle Game Engine to mention this (“A special requirement is on macOS users …”) , for people who compile CGE manually (including our editor) from sources following Compiling from source | Manual | Castle Game Engine . I will keep updating this, as (hopefully) the fix will be applied fast, and new stable Lazarus version with this fix will appear too – maybe Lazarus 3.6 soon? For now, macOS developers will have to be aware of this (unless you download engine from official downloads Download | Castle Game Engine , then you can forget about this problem). I wasn’t able to “workaround” the problem with unmodified Lazarus 3.2.
2 Likes
In short: the latest macOS build on Download | Castle Game Engine has the problem fixed Tests welcome!
Details:
- A version of my fix was merged to Lazarus, so it’s all good and fixed in Lazarus now.
- We switched to build CGE releases on macOS with latest Lazarus version from
fixes_3_0 branch (this is 3.5 now, and it will be eventually released as 3.6).
- I also added checks (to both Pascal code and packing scripts) to make sure we never by accident build editor with Lazarus < 3.5 for macOS, since we know it would result in a broken editor.
- Note that this requirement applies to CGE editor, not to applications made by CGE – if you use Lazarus yourself, you can happily use any Lazarus version (like 3.2 or 3.4) that works for you. The applications made using CGE use our
TCastleWindow by default and do not depend on LCL, so they are not affected by LCL Cocoa issues.
- The downloads on Download | Castle Game Engine are already good, made with Lazarus 3.5 with fix included. So you test them right now
- I also updated Supported compilers and IDEs | Manual | Castle Game Engine .
Note: I noticed other (unrelated) macOS-specific issues I’d like to fix soon in CGE,
- AWSD in editor, on macOS only, doesn’t seem to move camera? Weird, arrows work OK.
- I have sometimes crash at
menuitems.inc when creating new project – was not able to pinpoint the exact reproduction now. I can create new projects… usually, only sometimes I get crash at some menu processing in LCL Cocoa.
I’ll try to investigate them soon.
More testing and feedback about Castle Game Engine editor, specifically on macOS, is very much appreciated! Please don’t hesitate to report anything that feels weird / buggy.
( Even things that may be mentioned as “known issues” somewhere, like the fact that CGE binaries are unsigned. It is known issue, documented on macOS | Manual | Castle Game Engine and it would cost 100 USD / year to solve it. I still appreciate if people mention how much this bothers them – becuse we have to get to solving this at some point and I need your feedback to know if this is “very bothersome” or “only slightly bothersome” Thanks! )
Sorry for taking a few days to get back I had been sick, but the fixes you made work perfectly thank you.
There is an issue with multi-monitor set-ups where the game is zoomed in to the bottom-left corner. It’s seems to me that it’s only a graphical issue because the buttons react to the mouse as if they were in the correct spot. It is easily fixed by moving the window to the secondary monitor and resizing it, then you can move it back to the primary monitor.
However, if you then resize the window on the primary monitor again, it will break again. Sometimes it also causes things in the game to flash as well. I will attach a short video at the bottom demonstrating the issue.
As for unsigned binaries, for me it doesn’t personally bother me at all. A lot of apps I run on MacOS are unsigned so I’m used to it. I actually would like to donate sometime, but right now I don’t have work so I unfortunately can’t.
Sorry for long delay – I understand the error, but to investigate and reliably fix I need an access to macOS with different screen settings. I’m looking how to organize it, it takes a while
For what it’s worth, it works correctly for me with my current (and single) monitor OK. But I cannot test with second monitor, or a different monitor – because the macOS I use is a remote machine provided by https://www.macstadium.com/ . It’s a great way to use mac (and share it with a team, see old blog post about it ), it has served us well… but the limitation is that I don’t really have a physical mac, I cannot swap monitors to which it is connected.
Below is a screenshot how it – correctly – looks for me.
I will get back to this thread once I managed to reproduce and fix the scaling problem, have patience with me please (And if you’d like to help, the hint is that the bug is most likely inside Cocoa + TCastleWindow code, in file castle-engine/src/window/castlewindow_cocoa.inc at master · castle-engine/castle-engine · GitHub . We most likely miss scaling there by some per-monitor value.)
@sophia @Mojomajor With big thanks to Jan Adamec, this (wrong window resolution on Retina monitors) is now fixed!
We have pursued the proper fix to this for some time, and now it is done, and all should be perfect The window on Retina screen will display properly, and CGE renders will proper resolution (all the scaling is controlled using CGE, like CGE UIScaling feature, so the rendering is “crisp”, not artificially upscaled by macOS), dragging windows between monitors will also work cool. Details in PR: Cocoa backend fixes by janadamec1 · Pull Request #624 · castle-engine/castle-engine · GitHub .
The fix is now merged to Castle Game Engine master, and it will be automatically available in a few hours in our downloads on Download | Castle Game Engine . You can observe this page, when it will no longer show the commit titled “Fix the issue with missing retina resolution on macOS Cocoa backend” then it means this commit is now part of the release.
All the testing is naturally most welcome!
