Messages

You could ask the Allegro Development list [1] how difficult porting Allegro 4 would be.
An alternative would be porting AGS to Allegro 5. [2]

[1] http://alleg.sourceforge.net/maillist.html
[2] http://www.adventuregamestudio.co.uk/forums/index.php?issue=355.0

I just realized that the Windows (Winforms) version of Scintilla would also have to be ported to Mono first. Any thoughts about that?

Once you get the hang of it it always works. But yeah, would be better if physical right mouse buttons would also work.

You have to put one finger down and shortly after that another finger next to it.

I'd sure as heck offer my vote for a Cocoa powered AGS (Editor & Runtime) should any programmer be interested enough in exploring the potential. 

You may not believe it, but your vote alone will not convince any programmer to lift a finger.

That would be great, because it would also mean that it would work on Linux. From what I read here, the Editor should basically work with Mono, but the problem is that AGS.Native is a mixed mode dll and that works only on Windows. Porting requires splitting AGS.Native into managed and unmanaged code. sonneveld started doing that, but he stopped and never uploaded his work in progress.

Even if the old plugin interface has to stay for compatibility, it may be a good idea to deprecate it and (if a plugin interface is still needed) create a new one in addition.

EDIT: One could also remove the old plugin interface and rewrite the plugins that are needed once someone comes across a game using them.

So this Antivirus warns everybody who executes programs which are not widely used. So what?

Would you notify us when you are through with the list you gathered elsewhere (or even publish the list)? Doesn't really make sense to suggest things before that.

It should now also work on Ubuntu 12.04 amd64, because it works natively on 64bit know. The multiarch way is now only required for systems where the native 64bit build crashes all the time (seen on Debian).

He explained it here.

Ok, I just wanted to say what exists first. If you consider providing a game for Mac OS X, that will not work on the most recent versions 10.7 and 10.8, an option, read on.
There's a source code repository where you can get the code, compile it and bundle that with your game. Nobody has ever written down how to do that, so you must wait until someone explains it here if you want to do it. I don't know how to do it.

The engine from https://github.com/adventuregamestudio/ags should work better, but unfortunately only up to Mac OS X 10.6.

Really? The reason why you can work on AGS is because it's open source. And you think about how to make it closed again because of this? Also, what do you want to achieve? Your plans went from improving encryption to writing a decompiler and back in this thread, so why care at all?

With the current solutions the players don't need to jump through any hoops - if the game developers do it for them and bundle their games with the different engine ports.

It works on all platforms that are listed in the README.md Crimson Wizard linked to.

Please create a new thread "AGS engine Mac OS X port" in the engine forum if you want to ask how to compile it.

Nice, one more link for our main README.md.

Spots where differences occur should be easy to find by stepping through the saving code while keeping an eye on the file pointer.

Anyway, I think you meant they have a different size on all platforms, not only 32 bit vs 64 bit right JJS? Are C++ objects stored in the savegames in refactory? I would not be surprized if their size depends on the implementation.

You can start using the refactory branch. But savegames on 64 bit are not compatible between main and refactory. Bigendian code is still broken in the script interpreter.

Would you make refactory the default branch that is active after git clone?

Still the whole savegame issue is a bit of a mess. What I mean is that savegames have a different size on all platforms, which is something that I do not at all understand.

I know at least one reason why it's different between 32 and 64 bit. Look at save_game_data in the main branch and search for sizeof. There are structs stored that contain pointers:
RoomStatus, GameState, GameSetupStructBase, maybe more