Messages

Darn, I knew that from the first screenshot, but was not on forums to answer .

Um, does it mean I won? :p.
Sorry, I give away my turn.

I don't know why, but it has a feel of Mumintrolls...

Probably because it is the only fantasy world I know where atmosphere is so serene that random small creatures rest at the road side like that.

[AGS 3.2.1 and higher]

DOWNLOAD DragDrop 1.1.0 MODULE
DOWNLOAD DragDropCommon 1.1.0 MODULE
DOWNLOAD Demo game (needs AGS 3.2.1 or higher)

Additionally, latest sources of both the script module and the demo game may be found in this repository:
https://github.com/ivan-mogilko/ags-script-modules

Full documentation for this module is now available here:
https://github.com/ivan-mogilko/ags-script-modules/wiki/Drag-&-Drop-module

Module supports AGS 3.2.1 and higher.


DragDrop and DragDropCommon are two modules that make it possible to drag things around in AGS. What is the difference between these two?

DragDrop module implements an abstract drag-and-drop functionality. This means that the module does not drag any actual game object on its own, but rather calculates the dragging and dropping action, and tells you what and how happens, so that you could script the actual object movement. You might say, this module provides an idea of dragging, rather than dragging itself .

The upside of such approach is that you may script dragging of anything, both standard AGS objects and your own custom things, even non-ordinary pseudo-objects. For example, you may use this module to script dragging a line from point A to B, or draw a rectangle by dragging one of it's corners. The downside is that you have to be ready to do some extra work, and understand scripting well.

When you need to just make normal ordinary game objects dragged around in your game, this is what DragDropCommon module is for. DragDropCommon supports drag-and-drop for Characters, Room Objects, GUIs and GUI controls, and inventory items, right out of the box, only with a minimal setup.

NOTE: DragDropCommon module actually depends on DragDrop module, so you will have to add both to your game if you want to use DragDropCommon.

[E:]

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.

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.
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

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.
Since I do not own Mac, I can only rely on user description of the problem, so the more details you can provide (game config, logs, etc) the better. Also, the situation may be different with the latest code in the "develop-3.3.5" branch, which does not have the release tag yet.

- 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:
https://github.com/JanetGilbert/ags/blob/humble-ports/Engine/platform/osx/acplmac.cpp#L132

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().

Looks russian. or at least like a production from the former USSR

I was thinking about North-European ; Baltic countries, or Scandinavian maybe. Or Poland, not really sure.

I question the decision to give "basic" names to float variants, and specific names to integer ones.
I know this may sound naive, but I think AGSers use integers more often than floats, even in calculations; therefore it might be more natural for them to have simplier function names for integer variants. Float variants could be distinguished by F prefix or postfix (MaxF, MinF, AbsF, -- or -- FMax, FMin, FAbs, etc).

[imgzoom]http://i.imgur.com/Z1ctHQy.png[/imgzoom]

This game was created in Russia under one name (also in english), but later distributed in the western countries under another title. I suppose either of the titles will count.

Zombieland?

Supaplex. I played it on my first DX 486.

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.

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.

*nevermind*

I think it's the game where woman looks for her kid in the fun park. "The Park"?

(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.
Although Mac OS and iOS are both Apple .
Our repository currently supports iOS, but only for jailbroken devices.

[Editor]

What's the long and short of it? Is there a version of the editor that I can use on Yosemite currently?

This particular thread never touched Editor; it is dedicated to porting AGS engine to OSX (as stated in the title).

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.

Editor status: there were talks about moving to Mono (as Editor is a C# program), but number of Editor parts still have dependencies on Windows runtime libraries, and it is unknown if anyone works on this.

I also heard that you may run Editor on Mac using some wrapper, but I am not a Mac person, so cannot help you here.

Sooo.... should I post another hint?

Okay. I will post one this time.

Fallout 4, character creation screen.
Also, sorry, I was busy and completely forgot to post game last time.