The OSX port is currently only interesting for developers.
Main reason for this is that it only runs on OSX versions 10.6 (Snow Leopard) or lower. Important frameworks used by Allegro 4 were removed in later releases.
@JanetC, also, a small note, seeing as you (https://github.com/JanetGilbert/ is your repository, right?) are merging our refactored code from time to time:
current 'ags/master' branch, while having more potential due to rewritten script interpreter (it is more compatible with 64-bit builds), is still considered a bit unstable (well, for the same reason ;)), and had new bugs in recent past. So if you are using your branch for shortly upcoming releases, I'd recommend not to update from our repository for some time.
Do you mean not to update from Refactory or master? Because I haven't updated in a while, but when I do, I use Refactory.I mean both. There was a big change made in refactory branch (script interpreter). Then we created master branch and now working in there.
Thanks for the info on Mac, guys. Sounds like quite a task!Well, I do not want to overestimate things or scare people off. I don't think it is a year-long of work, maybe 2-3 months of work. There just should be dedicated someone who would do that fairly.
I mean both. There was a big change made in refactory branch (script interpreter). Then we created master branch and now working in there.
I hope it will become safe in a while, people are using it to play games, so these changes will be tested.
If you have a will to help, you are most welcome :)
When was the unsafe change made? I have a beta of Gemini Rue on iOS running on the Wadjet Eye boards at the moment, and we are getting a lot of crash reports.
When was the unsafe change made? I have a beta of Gemini Rue on iOS running on the Wadjet Eye boards at the moment, and we are getting a lot of crash reports.Doesn't sound so good. If you have something that seems to be a general port problem please forward it to me. The most likely cause of crashes is still the multithreaded audio. If so I would expect it to mostly affect devices with multiple processor cores.
Not much interest here... is it worth pointing out that Wadjet Eye would be willing to pay someone to do this port?On a practical note, maybe not many coders here have access to Mac OS X and/or XCode? Maybe you should try to advertise this on a freelancer site, maybe one orientated towards Mac programming.
On a practical note, maybe not many coders here have access to Mac OS X and/or XCode? Maybe you should try to advertise this on a freelancer site, maybe one orientated towards Mac programming.
What is its status? Why was it discontinued?I guess it's much less polished than the the 3.3 engine.
Also, he mentions a reasonable argument about using SDL instead of Allegro 5. May anyone on comment that?He just said Allegro 5 is lacking pixel drawing and palette manipulation features. Is pixel drawing really a problem? Do you think SDL provides everything, so that it would require less code to be moved to AGS itself?
He just said Allegro 5 is lacking pixel drawing and palette manipulation features. Is pixel drawing really a problem? Do you think SDL provides everything, so that it would require less code to be moved to AGS itself?I know nothing of SDL, so don't know if it's less coding... I just see there's already a Mac port that probably could be used to make few releases, like Wadget Eye wanted to.
Well, I am doing a preliminary convert to Allegro 5 now. I think I forgot to mention this on forums... I told this to Janet Gilbert and JJS & BigMC via emails.
Well, I am doing a preliminary convert to Allegro 5 now. I think I forgot to mention this on forums... I told this to Janet Gilbert and JJS & BigMC via emails.
Well, I am doing a preliminary convert to Allegro 5 now. I think I forgot to mention this on forums... I told this to Janet Gilbert and JJS & BigMC via emails.
Is this a one-person job, or are there specific areas we can help with?Well, I have wrote graphic classes, and now trying to make the "Common" part of the source at least compile; then I will move to the "Engine" part.
I'd be very glad if someone could do the audio part, it's something I almost haven't investigated.
If you would have any suggestion on other parts and what I do, I will use them too of course.
I am doing the work in a separate branch in my private repository, but since we will have to share the code, I guess, I'd better pull that to central repo.
I just need couple of days more to finish the changes I am doing right now.
But that's what I propose to do. Aren't we mean same thing?I am doing the work in a separate branch in my private repository, but since we will have to share the code, I guess, I'd better pull that to central repo.
I just need couple of days more to finish the changes I am doing right now.
Ok, although I would be fine working with you in a shared branch, like you guys did with refactory. Git is practically made for that sort of thing :)
Ah, OK. I read "pull to central repo" to mean that you'll send a pull request to master, and then merge your changes into it, having us all collaborate on master. You're meaning that you will pull to a new central repo for sharing work? Sorry to misunderstand!No, I mean making a new branch in the central repository, like "develop_allegro5" or "feature_allegro5".
No, I mean making a new branch in the central repository, like "develop_allegro5" or "feature_allegro5".
...
Also, I learnt one may add contributors to personal repository. We may use that too.
Is JJS doing that or are the Allegro people going to do that?Wadjet Eye people do that.
Also, what remains to be done in the way of abstracting Allegro code from the main source?I remember palette & colors, and path operations, slightly different way to access bitmap data directly, also controllers (mouse, keyboard).
8-bit image loading for Allegro 5 is happening here:Yes, I saw that. If I understood that right, it is about converting 8-bit image on disk to some other format in memory (AFAIK Allegro5 uses OpenGL textures?). But what about palette manipulations, like color changing? The only information I found on this was one guy's suggestion to use shaders. I have no idea how difficult/effective that would be.
https://www.allegro.cc/forums/thread/610190 (https://www.allegro.cc/forums/thread/610190)
The only information I found on this was one guy's suggestion to use shaders. I have no idea how difficult/effective that would be.
dunno what that means in time terms. I asked for a bit more information.I'd assume "not going to happen" as those sort of projects get no time usually.
Well, I am concerned about palette cycling, which means that all the screen should have colors replaced. Does this mean applying same shader to every sprite, or some filter over final image?The only information I found on this was one guy's suggestion to use shaders. I have no idea how difficult/effective that would be.
This is probably the most forward thinking - and the fastest solution. A shader based solution would be GPU accelerated and very fast. It would however be more initial work.
Question - would not the best start to be to just move all the Allegro 4 calls into an abstracted class/lib so that they are centralized for porting to 5 at a later date?Well, certainly.
Hi, HumbleBundle ported the AGS engine to Mac so that we could have Gemini Rue on the Humble Bundle With Android (it's up now! So exciting!)
This means we now have a working port to Mac, and it's still Open Source, of course!
Where do you guys want it put?
Hi, HumbleBundle ported the AGS engine to Mac so that we could have Gemini Rue on the Humble Bundle With Android (it's up now! So exciting!)Regarding this new port, we would need to see the code to compare changes and learn what needs to be done to make a merge. Is the code still originate from ags repository you have? In this case you could probably submit it as a separate branch to your personal repository on github.
This means we now have a working port to Mac, and it's still Open Source, of course!
Where do you guys want it put?
It is not related to my AGS repository, which is heavily mucked about with to make mobile games. It is derived from the main AGS port at:
https://github.com/adventuregamestudio/ags
Is there a way that the porting engineer (Edward) could push his changes back there to a separate branch? I assume we want to use his changes if we can, to make the port native Mac compatible from now onward. I'm not an expert on Git. Is this a good idea? Would he need permissions to do this?
3. Copy his new code over and make a one big commit.
Then, continue with pull request as usual.
Aye, that's true. In fact one can split changes in one file into separate commits: http://stackoverflow.com/questions/1085162/how-can-i-commit-only-part-of-a-file-in-git (does not work 100% time though).3. Copy his new code over and make a one big commit.
Then, continue with pull request as usual.
Even if there's no history it can be useful to commit the changes in multiple steps, which may be doable to some extend if unrelated changes are in different files.
This is really a git question, I suppose, but is it possible to get the repository exactly as Edward left it so I can compile Wadjet Eye's other games for Mac and Linux? I have my own fork of the repository which is not really compatible with anyone elses (for iOS) and I don't want to overwrite or merge it.First (and fastest) you can just clone Edwards repository (https://github.com/humble/ags-geminirue.git).
! [rejected] humble-ports -> humble-ports (non-fast-forward)Error like this indicates that there were changes to remote that are not found in your local branch. Don't know how it happened to be. Maybe you have two local repositories, or something like that?
error: failed to push some refs to 'git@github.com:JanetGilbert/ags.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.
If I instead try using the terminal, I get a different error after using git push:Which address do you use in git command? It should be just "https://github.com/humble/ags-geminirue.git" instead.
error: The requested URL returned error: 403 while accessing https://github.com/humble/ags-geminirue.git/info/refs
fatal: HTTP request failed
! [rejected] humble-ports -> humble-ports (non-fast-forward)Error like this indicates that there were changes to remote that are not found in your local branch. Don't know how it happened to be. Maybe you have two local repositories, or something like that?
error: failed to push some refs to 'git@github.com:JanetGilbert/ags.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart.
On usual occasion this is solved by making a "git pull" before doing anything else.
If I instead try using the terminal, I get a different error after using git push:Which address do you use in git command? It should be just "https://github.com/humble/ags-geminirue.git" instead.
error: The requested URL returned error: 403 while accessing https://github.com/humble/ags-geminirue.git/info/refs
fatal: HTTP request failed
If I instead try using the terminal, I get a different error after using git push:
error: The requested URL returned error: 403 while accessing https://github.com/humble/ags-geminirue.git/info/refs
fatal: HTTP request failed
I thought SDL2 is just used for audio there and their port of Allegro 4 to OS X would still be useful?No, I just mean that their latest additions does not give us much benefit. I am speaking of the changes made last week to Janet's repository. I see Edward is making more SDL2 "injections" in allegro.
Is any news for MAC port? Is it in WIP ?
It works up to Mac OS X 10.6 and Allegro 4.4 was released before Mac OS X 10.7, so that information is probably outdated.
The pull request will never be meant for actual merging (at least not until removing precompiled binaries), but it could serve for automatic building working OSX port.First step is to have the automation server produce osx builds :) Sooon!
What's the long and short of it? Is there a version of the editor that I can use on Yosemite currently?
Engine status: there is a Mac port by Wadjet Eye that can play games made with AGS 3.2.1 and lower. It is practically possible to update it to more contemporary version of engine, but it will take some work. Last time I heard about this, Janet Gilbert from WE wanted to hire programmer again to do this; also Nick Sonneveld mentioned plans to help them, but I do not personally track the progress in that area at the moment.Alos Janet's post has been converted to a Wiki article, with added screenshots and some on-screen stuff clarified : http://www.adventuregamestudio.co.uk/wiki/Releasing_a_game_on_iOS
(PS: I apologize if I'm confusing MacOS and iOS; I'm not sure if it's the same realm or not)No, these are different ports.
Isn't any news for Mac OS port? Is it in progress or not? Mac OS is more important of Linux I think so.We do not work on Mac OS port right now, our work in that direction was not started properly yet. But I think Janet Gilbert might have something since they were hiring programmer.
So Does Janet Gilbert will put here or github source or method of this port ?AFAIK she keeps it open source and available for public use in her repository, but I do not really track her progress right now, so it is up to her to explain where you get the latest version and how you use it. I guess the fastest way is to contact her directly for this kind of info.
So Does Janet Gilbert will put here or github source or method of this port ?AFAIK she keeps it open source and available for public use in her repository, but I do not really track her progress right now, so it is up to her to explain where you get the latest version and how you use it. I guess the fastest way is to contact her directly for this kind of info.
It will always be open source. We literally *can't* make it closed source as AGS is open source - we'd be breaking the terms of agreement!
Besides, we don't want to :)
I contacted Janet about her/their OS X port last june and she directed me here (https://github.com/JanetGilbert/ags/tree/humble-ports). It was open source then and it probably still is.
That was as far as I got, since I don't know anything about compiling source. It would be great if you could post about your progress.
The result looked promising at a first glance. I was able to run a game. I think some of the more advanced animations seemed slow compared to the windows version.What renderer does OSX build use? If it has only software one supported (like on Linux) then it will be generally slower (and more slow the higher scaling filter is used).
- The entire mouse handler has been rewritten; the way to get the mouse position is very different. This definitely causes some major cursor problem in full screen, and the mouse does not move correctly at all. In windowed mode, I saw the mouse reset to 0,0 when moving the cursor to the top outside the window.We have some mouse issues in latest code, which hopefully be resolved soon. Although the particular ones you describe are different from ones we know.
https://github.com/JanetGilbert/ags/blob/humble-ports/Engine/device/mousew32.cpp#L99
https://github.com/adventuregamestudio/ags/blob/v.3.3.5.1/Engine/device/mousew32.cpp#L103
The window mode issue can be fixed by switching this variable to 1, but the full screen problems still prevail.
https://github.com/adventuregamestudio/ags/blob/v.3.3.5.1/Engine/device/mousew32.cpp#L62
- There's some hack involving reading the config file in the AGSMac. The way the INI file is loaded has changed as well, but may not be too much of a hard fix. I am not sure why was added:This hack is no longer needed after you make this merge, because there is a similar option our engine supports, just implemented differently (category "override", item "os", for details refer to the recently added readme (https://github.com/adventuregamestudio/ags/blob/master/OPTIONS.md) ). It may be safe to completely remove this INI reading from AGSMac::GetSystemOSID().
https://github.com/JanetGilbert/ags/blob/humble-ports/Engine/platform/osx/acplmac.cpp#L132
E: Since we now have an automation server, one of the options could be making a pull request that combines Janet's Humble Bundle port (not their pull request, but the most up-to-date version, I think this: https://github.com/JanetGilbert/ags/commits/humble-ports) and our current master.
The pull request will never be meant for actual merging (at least not until removing precompiled binaries), but it could serve for automatic building working OSX port.
Please, we had this discussion many times. I am against putting this branch into our main repository. Two main reasons are:
1) it adds precompiled library binaries to repository, and we are against that (also, are these modified and are there sources of these?).
2) AFAIK it hacks SDL code into Allegro to make it run on mac, thus increasing general mess.
It makes it work and so serves its purpose, but it is not a clean way to do things.
Of course, separating OSX changes into a clean branch would make things easier to analyse. Also, so far it is the only up-to-date OSX version that actually works, so it would be silly to reject one. But I would suggest to keep this version in a separate repository for now until the issues I mentioned are resolved.
I also found my own suggestion made several months ago:E: Since we now have an automation server, one of the options could be making a pull request that combines Janet's Humble Bundle port (not their pull request, but the most up-to-date version, I think this: https://github.com/JanetGilbert/ags/commits/humble-ports) and our current master.
The pull request will never be meant for actual merging (at least not until removing precompiled binaries), but it could serve for automatic building working OSX port.
I've really let this go (busy on other stuff), but we at Wadjet Eye are interested in releasing our games on OSX. Our old port by Edward Rudd of Humble Bundle isn't up to commercial standards anymore. It would be fantastic if OSX compatibility was part of the standard project. If anyone knows of any OSX developers who would be interested in working on this project, let us know. Otherwise I might try and muddle through (but I'm not experienced on Mac.)
Isn't any news for Mac OS port? Is it in progress or not? Mac OS is more important of Linux I think so.
I've really let this go (busy on other stuff), but we at Wadjet Eye are interested in releasing our games on OSX. Our old port by Edward Rudd of Humble Bundle isn't up to commercial standards anymore. It would be fantastic if OSX compatibility was part of the standard project. If anyone knows of any OSX developers who would be interested in working on this project, let us know. Otherwise I might try and muddle through (but I'm not experienced on Mac.)
I'm keen to look at this again.. Just need to find time/energy.
Nick.
I'm interested in checking this out, but before delving in the complexities of OSX development I'd really like to see an AGS executable at work.
I've found that the Engine OSX branch on the AGS Team City successfully compiles but produces no artifacts. I'm not sure why that is, perhaps someone could enable it?
Conversely the code in Janet's repo is somewhat newer but doesn't include a build.
But can you tell me why artifacts are disabled for OSX on Teamcity? That would be an easy place to get a sample executable, otherwise.Um... no idea. Also it was built 3 months ago last time, which makes me think that it was excluded from work at some point.
Could we switch it on and try?It was scheduled to run on machine that is no longer available. That could be one the Nick Sonneveld's private computer, or some server he owned.
Anyone who wants to build for Mac, check out the port Nick Sonneveld did for Wadjet Eye!
Anyone who wants to build for Mac, check out the port Nick Sonneveld did for Wadjet Eye!
Thank you, I have found the git branch but I'm wondering if a compiled executable is on the web somewhere.
Hi
Isn't any manual step by step for compile to Mac OS ? I haven't knowledge for use from Github .
Much appreciate for any help
I'm now getting a file not found on alplatf.h; looking through the folder there's an alplatf.h.cmake file which appears to be a proper C header; I'm not sure where the .cmake part comes from, maybe allegro didn't properly build?
Ok, I'm trying this out now. But neither the AGS repo nor Janet's has a branch named osx-nick...
Seems as the 2 possible options for supporting mac long term are either metal or vulcan using moltenvk (https://arstechnica.com/gadgets/2018/02/vulkan-is-coming-to-macos-ios-but-no-thanks-to-apple/) (and of course supporting vulcan should give performance benefits on all platforms whereas metal is apple platforms only).
~/Build/ags-osx-nick/OSX/buildlibs/build/allegro-4.4.2/build ~/Build/ags-osx-nick/OSX/buildlibs/build/allegro-4.4.2
- The C compiler identification is AppleClang 10.0.0.10001145
- The CXX compiler identification is unknown
- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang
- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang - broken
CMake Error at /opt/pkg/share/cmake-3.12/Modules/CMakeTestCCompiler.cmake:52 (message):
The C compiler
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
is not able to compile a simple test program.
It fails with the following output:
Change Dir: /Users/mwillcock/Build/ags-osx-nick/OSX/buildlibs/build/allegro-4.4.2/build/CMakeFiles/CMakeTmp
Run Build Command:"/usr/bin/xcodebuild" "-project" "CMAKE_TRY_COMPILE.xcodeproj" "build" "-target" "cmTC_c3c50" "-configuration" "Debug"
Prepare build
note: Using legacy build system
=== BUILD TARGET cmTC_c3c50 OF PROJECT CMAKE_TRY_COMPILE WITH CONFIGURATION Debug ===
Check dependencies
error: The i386 architecture is deprecated. You should update your ARCHS build setting to remove the i386 architecture.
** BUILD FAILED **
The following build commands failed:
Check dependencies
(1 failure)
CMake will not be able to correctly generate this project.