Messages

Memochi

I switched branches to properly work to merge the work in AGS main repository here: https://github.com/ericoporto/ags/tree/emscripten

and here: https://github.com/adventuregamestudio/ags/pull/1346

But current Emscripten upstream introduced a lot of incompatibilities and I couldn't yet figure out how to navigate it... Changes necessary include

• Upgrade to at least SDL2 2.0.16 and build from source instead of relying on Emscripten port - fixes audio bugs due to Emscripten upstream port removal of sdl2 internal libc.
• Need to patch Emscripten OpenAL or there will be a crash due to null buffer - need to materialise a test that convinces Emscripten upstream to merge my one line change or fix bug in AGS audio if one exists.
• Newer binaryen produces assembly that breaks chrome mobile, but code appears valid, reported to chrome upstream
• Emscripten current upstream can't run compiler tests through CMake that ran in older versions

If someone is familiar and could tackle these problems upstream it would be great.

I restored previous work linked above. I removed it a long with a lot of things in a time I was having all code I wrote constantly being attacked by a specific person on GitHub.

Isn't it possible to generate something like a .pdb instead of reusing the compiler at runtime? Like a symbol map or a DWARF file.

What I meant is if it's possible to be aware in the script of what are the types of struct members, well, it would be possible to traverse them and get each member to workout the serialization, in script - Google's protobuf does this in it's C# implementation, but uses access to the  Marshall Memory after picking the references and sizeof to figure things out.

Generics are the proper way to ensure type safety - among other things, auto-complete is a lot easier to make it work with them.

RTTI means reflection

Reflection would be huge but this would mean storing variable names too? I think this would be information that is not needed to store. I think Java does by only storing public members of classes (not sure though), see http://openjdk.java.net/jeps/118

Hey, could this give some C# like serialization capabilities? (imagining once generics are a thing)

[MacOS/]

Can you place the plugins where ags Engine is located instead? It should then load them. I think the name of the directory is MacOS/ .

[@Dualnames]

@Dualnames, which wrapper? I think your game will only work in the Allegro4 version of the Engine - the SDL engine for now has conflicts with plugins that also use SDL.

There was a change how the Mac port find games (it will look in the place it was passed on command line and where the engine is), so how EXACTLY is the structure of your .app directory? And what is the entry point you wrote in your info.plist (it needs the game here) ? I think ags will search for plugins where the engine is and not the game.

Unfortunately the pastebin is not that useful since AGS doesn't print where it's looking for the plugins...

I am still working, I will try to add some fun gifs later - all the story has been written, and the complete draft of game dialogs is done too. Lesson is, do not make gigantic game as first project. _{(there's no need to lock)}

Thanks!

It's been a bit of a slow development, I had lots of things in mind and ended up redoing some stuff a lot of times the more I learned things around... I am in a bit of small hell of forever adding texts, adjusting dialogs and making sure the scenes and actions are working in a cool way. I reaaaaally want to do a update here... I think I will foccus into doing some stuff and figuring something from development to pick and show here.

[@morganw]

@morganw, in the gazillion of possible outputs of CPack (from CMake), dmg is a valid one. It needs appropriate install() commands in the cmake file to tell the files that needs to be packaged though.

Just to give some update. It appears even though the CI system we use is Intel based, turns out there are new Big Sur images there. With Big Sur, I can at least cross compile to arm. I don't promise anything right now (there's a few other things), but at least it's possible to generate pre-built binaries of the engine that would be compatible with arm and x86.

About the extended attributes, on Windows/Linux the lazy way to remove them is to move the file to a pen-drive that is formatted to FAT and moving them back to disk. FAT filesystem doesn't support extended attributes, so they get cut. Never verified if it works on MacOS too. Obviously not a real solution, just workaround.

This is weird, because if you ARE using the latest CMake you should not have to do this, it sets the variable CMAKE_OSX_ARCHITECTURES from the arch in the uname output from the invoking shell in theory, but you can pass it on the command line.

In AGS source code directory, create a clean build directory, generate files with cmake and try to build with make as this:

Code: bash

cd ags
mkdir cmake-build-release
cd cmake-build-release
cmake -DCMAKE_OSX_ARCHITECTURES=arm64 -DCMAKE_BUILD_TYPE=Release ..
make -j8

I don't have a way to verify this. I also am not sure, but I think you can verify the architecture of a binary. After building, in the same directory, try this

Code: bash

file ./ags

Also, the CMake version would be useful...

Code: bash

cmake --version

(note I am just trying to understand why you are not getting an arm64 build, but I am not familiar with the particular way MacOS works...

But about universal binaries, that is different. If one don't want to deal with them though, just make a bash script that checks the architecture with uname and boots the specific ags_arm64 or ags_amd64 binary with the game, and set this script as the entry point of the app in info.plist)

About M1, the command line terminal that's native, what output you get from uname -a ?

There's a GUI?

I am not familiar with M1 (too expensive for me), but the way CMake is currently set up is there's no architecture information at all in the files, the idea is you pass a toolchain and it will follow along, if you don't it follows what's default for your system. So, say you are on a raspberry pi, you get raspberry pi binary compatible with your model's arm. Or say you want to crosscompile to arm like it's done on Android or to wasm (web builds), you pass the compatible toolchain.

Apple usually doesn't play well with cross-platform solutions so maybe things are different, but if there is nothing weird on their side it should simply build to the host architecture.

The thing mentioned on that forums is NOT about building for M1 alone, afaict it's focused on building "universal binaries" meaning, it builds twice, once for each arch, and them glues them somehow, and the system can then boot up the selected binary. It appears to be tied to Xcode (would not be just "make" after and building, it would require using Xcode).

Edit: ah, additionally, the CI system we use currently don't have M1 compatible hardware, so we can't provide binaries for it yet.

I asked in January but the situation still holds: https://github.com/cirruslabs/cirrus-ci-docs/issues/762

It would require maintaining persistent m1 workers.

Edit2: just read CMake git history and there has been a change of behavior for m1 from launch to now. On the latest version of CMake available, from what I understand, it should just build for arm if you launch an arm terminal and build for amd64 if you launch from a Rosetta terminal. In theory you should be able to build to each architecture separately already - or use the Xcode generator, and set it to use universal binaries in it's interface. Again, in theory, with the latest CMake.

WoaM and Kathy Rain use a different code that works with the old android port - I actually have the script code because I asked by mail the dev, but I think you should just ask them yourself. If you want to use this module and use the same behavior for mouse and fingers, you need to use the Android SDL Port.

I have a little game that uses this module too here: https://github.com/ericoporto/dungeonhands

It has touch on the webport, but I don't know how well it runs on old devices. :/

There's no click and hold in allegro4 port - you can't check if a "mouse" button is down in the old allegro 4 Android port. This is the main thing I want to change with the new Android port (besides soon adding proper crossplatform multi-touch)

Edit: CW, I will not answer here to avoid complicating the topic, I just mentioned because Amir was asking about Android the other day. But in short we need proper way to support touch devices, including devices that have both, like laptop tablet hybrids. It's possible code wise with SDL, it's more about figuring the right design on how to handle this in AGS, I plan to open a ticket about this when I have at least a sketch of something.

[@Amir]

 @Amir, are you trying to use this module on Android? It doesn't work with the allegro4 based engine with touchscreen devices.

Quick questions - how do I map this to joystick controls? Do I need to use the Joystick module alongside it?

The module API is just that single function, so it's only a matter of passing a true for the direction that is pressed and false on the others (the module supports diagonals if your character has 8 loops).

I usually don't do this directly though, because I want to be able to remap buttons - I have a script for button remapping but I haven't open sourced it basically because it's a bit ingrained in my game menus and a bit hard to pull out...

Unfortunately for now joystick in AGS requires a plugin. So you use either the hat check (for arrows) or the analog stick stuff (for the left analog) and then convert them to a binary like check to pass the resulting boolean. I have been thinking a lot of adding a GamePad API (all joysticks as Xbox360 gamepads) in AGS directly (no plugins) since this would make much easier to support joysticks in Android and WebGL builds. With the new SDL Port I can't think of a reason why not.

My joystick handling is wrapped in a separate module that handles joystick button mapping, so it's not transparent and ends up looking like this:

Code: ags

bool downkeyLA = adventureJoy.isWalkDownPressed() || IsKeyPressed(eKeyS);
bool leftkeyLA = adventureJoy.isWalkLeftPressed() || IsKeyPressed(eKeyA);
bool rightkeyLA = adventureJoy.isWalkRightPressed() || IsKeyPressed(eKeyD);
bool upkeyLA = adventureJoy.isWalkUpPressed() || IsKeyPressed(eKeyW);
        
movement_state = Controlz(player, downkeyLA, leftkeyLA, rightkeyLA, upkeyLA);

Also, when the player reaches the end of a walkable area, is it possible to have the player continue to animate in their walkcycle (while standing in place) rather than coming to a stop mid animation?

I haven't tried but have you tried adding a iddle animation for this? Alternatively, the function is not void, it returns a state bit that may be useful for this. Other than this I am not sure how to handle this for people that want the full stop - aka, me. 

I may not have understood exactly if the full stop you mean is the one I think you are, so a gif/video to show what you mean would be nice.

https://www.youtube.com/watch?v=vkBYkOQrkyM