AGS engine Mac OS X port

Started by JanetC, Mon 10/12/2012 19:12:16

Previous topic - Next topic

monkey0506

I'm also quite interested in this. I know almost nothing about code portability, but I want to learn. It's been said here that Mac OS removed some things which Allegro 4 depended on, but later it seems that WEG had someone working on it who was quite optimistic that this could be resolved. What exactly changed, and what would need to be done to fix it?

Also, what remains to be done in the way of abstracting Allegro code from the main source?

Crimson Wizard

#41
I did not have any news for a long time now, we probably should ask Janet about this.
Last time I heard of them, the developer's idea was to upgrade Allegro 4 code to make it compatible with newer OSX.

Quote from: monkey_05_06 on Fri 01/11/2013 06:31:02
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).
There is a research made by BigMC: http://www.adventuregamestudio.co.uk/forums/index.php?issue=355.0


Quote from: subspark on Fri 01/11/2013 03:11:50
8-bit image loading for Allegro 5 is happening here:
https://www.allegro.cc/forums/thread/610190
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.
I suggest to very seriously consider the 8-bit aspect here, if we want to keep 8-bit compatibility (this was feature of AGS for years, and some people still use it in their projects).
I heard that SDL2 supports 8-bit natively. I am not an expert here, so I'd rather not make this decision (at least not alone).



UPDATE: I emailed Janet Gilbert, and what she sais basically is that the people still working on that, but this work is not their first priority, so... dunno what that means in time terms. I asked for a bit more information.

redspark

I'm very interested in this as well.  The only thing preventing me from using AGS is not having an OSX engine that works on modern versions.  Thanks for following up on it.

abritinthebay

Quote from: Crimson Wizard on Fri 01/11/2013 07:28:01
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.

Quote from: Crimson Wizard on Fri 01/11/2013 07:28:01dunno 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.

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?

That would probably allow the community to help too.

Crimson Wizard

#44
Quote from: abritinthebay on Mon 02/12/2013 23:52:11
Quote from: Crimson Wizard on Fri 01/11/2013 07:28:01
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.
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?
Maybe someone can make a test program that shows how this can be done? I'd suggest we be sure that will work before starting this change.

Quote from: abritinthebay on Mon 02/12/2013 23:52:11
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.
When I tried to do this, the biggest problem I met was color type: A4 uses integer (which meaning depends on  color depth mode), but A5 uses a struct of four floats. This color type is referenced everywhere in the code, so you can't "hide" this easily.
But the internals of the engine is not the only thing; we should take plugin API into account too. Changing to different library means breaking plugin API, which means we should plan to write a new one. One thing pulls another here.

JanetC

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?

Crimson Wizard

Quote from: JanetC on Fri 20/12/2013 00:15:20
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?

Haha, great to hear! I was suspecting something about this since I've seen your news mail. I am sure alot of people will be happy :D.

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.

JanetC

Quote from: Crimson Wizard on Fri 20/12/2013 00:39:30
Quote from: JanetC on Fri 20/12/2013 00:15:20
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?
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.

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?

The port also contains fixes to Linux which were made for the commercial release of Gemini Rue on that platform.

Crimson Wizard

#48
Quote from: JanetC on Fri 20/12/2013 14:50:45
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?

Oh, I see.
He should not push his changes directly in our main branch, because we need to check the code difference first to make sure that merging won't break our own version of the code.
Sharing code between repositories on GitHub is done using "pull requests". This is when a person has his own repository and he creates a request to merge one of his branches into one of the other people's branches (not necessarily matching ones).
If Edward used git to maintain changes history all the way, then it should not be a problem for him to create his personal GitHub repository, put the changes there, then make a pull request from his to ours.
I don't know how much has changed, maybe we will need to keep the code in a separate branch at first. We are preparing a 3.3.0 release now, and it will be not good to mess the code up. On other hand, if the changes are mostly in Mac-specific code (not the engine core), then things will be simplier.


In the worst case, if he did not maintain changes history but just has the code as-is, the steps may be:
1. Clone our ags repository to create his personal one.
2. Create a new branch (like "mac-port", etc), forking from the point at which he started his work back then.
3. Copy his new code over and make a one big commit.
Then, continue with pull request as usual.

selmiak

Wow, Christmas came early this year! Thanks Wadjet Eyes for bribing the nice folks at humblebundle into doing this ;) ;-D

BigMc

Quote from: Crimson Wizard on Fri 20/12/2013 16:43:19
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. But let's hope history exists.

Joseph DiPerla

Already purchased Gemini Rue a second time for Android(Always try to do my the best I can to support AGS'ers that create commercial games) and gave Gemini Rue 5 star rating and review. More than any of the code that is available, I would love to see the full Android port seeing as you got past the Obb issues and even some user interface hickups. Great Job!
Joseph DiPerla--- http://www.adventurestockpile.com
Play my Star Wars MMORPG: http://sw-bfs.com
See my Fiverr page for translation and other services: https://www.fiverr.com/josephdiperla
Google Plus Adventure Community: https://plus.google.com/communities/116504865864458899575

Crimson Wizard

Quote from: BigMc on Fri 20/12/2013 20:32:48
Quote from: Crimson Wizard on Fri 20/12/2013 16:43:19
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.
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).
This all depends on whether the author is going to bother doing this ;).

Adeel

Good guy HumbleBundle. Now I've found another reason to love it. ;-D

Crimson Wizard

Edward just made a pull request so we could finally see the code.
https://github.com/adventuregamestudio/ags/pull/109

It is not 100% compatible with current engine, there are few differences and at least one feature duplication, but I am sure we will sort everything out in time and merge it.

JanetC

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.

Crimson Wizard

#56
Quote from: JanetC on Sun 29/12/2013 15:56:19
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).

If you want to have that as another branch in your current repository, go to your "master" branch, find commit (f021439669696b3f94d194e2317108b56059ff4a), fork new branch from exactly that commit and then ask Edward to make a pull request on top of that branch. This will guarantee that you'll have exactly the code that Edward has.

There's an alternative way to do this without asking Edward and arranging pull request. Unfortunately I do not know how to do this in git generally, I always used "GitExtensions" UI program for this (but I may find out).
Idea is to add another one remote source for the local repository on your computer. You will need to "register" Edward's repository as a known code source, this will let you to "see" his branches. Then you just merge his "humble" branch into your "master", or another new branch, if you like to keep that separate.

I will probably be able to give more explanations, but only after you clarify how do you work with git: do you work with git's command line (git bash), or use any program with GUI? or else?

BigMc

If you want to add someone elses branch to your repository asking him for a pull request is a very complicated way of doing it. In your repo add his repository as remote (git remote add), check out the branch and push it to your remote repoostory. That's it.

Crimson Wizard

#58
Yes, right. Something like this, I recon:

(Go to your local repository folder and type those commands to command line; alternatively run git bash in that folder)

1) this registers Edward's repo at your local repo:
Code: bash
git remote add humble-geminirue https://github.com/humble/ags-geminirue.git


2) this adds information about Edward's branches current state to your local repo:
Code: bash
git remote update humble-geminirue


3) this copies his remote branch into yours local one (new branch named "humble-ports" will be created):
Code: bash
git checkout -b humble-ports humble-geminirue/humble


Now you have a local branch, which is a copy of Edward's, in your local repository and can push to your remote repository, or do what you like.

Depending on whichever git UI application you are using (if you do) those steps can be performed by using menus, but without knowing which program do you use, I can't tell more.

JanetC

Thanks guys. I'll do this as soon as my baby takes a good, solid nap tomorrow!

I use a simple GUI but it can't do anything complicated, so I use the command line for most things more complicated than committing or branching.

SMF spam blocked by CleanTalk