AGS 3.6.0 WIP (Alpha 21) - SDL2-based engine + Unicode support

Started by Crimson Wizard, Thu 25/03/2021 02:28:54

Previous topic - Next topic

Gilbert

I'm not familiar with these kind of stuff, but my question is, does it matter which version of the dll the user have?
That is, is the AGS engine guaranteed to work with whatever version (or, at least the newest version one can retrieve from the net) of sdl2.dll one has on their hands?
So, if sdl2.dll is not of the same version used when the AGS engine is compiled the games still work?
If the engine works only with specific version of the dll I think it's better to link it statically to the executable. (Or, at least advise people to include the file when they distribute their games).

I have been using some very old programming package and the resultant executables rely on openal32.dll to run. However, they only work with the dll precompiled included with the engine, not every other version you can find on the net.

Crimson Wizard

#21
Quote from: Gilbert on Sun 04/07/2021 03:56:14
I'm not familiar with these kind of stuff, but my question is, does it matter which version of the dll the user have?

Yes of course. The DLL's interface should be matching: function prototypes, but also function adresses in memory I think. So it mostly depends on how the library developers keep backwards compatibility (if they do). It may stay compatible in a small range of updates, or larger range, but I don't know about this particular lib.


Maybe I should not have mentioned this point at all, as being able to swap the DLL is not important. Having DLL may simply mean less maintenance for engine devs.

Quote from: Gilbert on Sun 04/07/2021 03:56:14Or, at least advise people to include the file when they distribute their games

If we have it as DLL we will definitely include it with Editor's distribution, there's no question about that.

Crimson Wizard

Updated to Alpha 5
(use download links in the first post)

Updated to include all changes from v.3.5.1.8.

Updates sound library, this fixes few sound formats not playing in the new engine.



SUPER EXPERIMENTAL, but AGS now supports Unicode translations, if your TRS files are saved as UTF-8 and certain hint is added to the files, engine should correctly interpret the text as unicode, and display unicode texts with appropriate fonts.

Unfortunately texts in the game properties and script cannot contain unicode yet. Hence we call it "partial unicode support".

More explanation on how to use Unicode translations in your game may be found here: https://www.adventuregamestudio.co.uk/forums/index.php?topic=59240.0

In short, you should have following line among the other options in TRS file:
Code: ags

// Text encoding hint
//#Encoding=UTF-8


The translation compiler will add it to TRA data, to let engine know to interpret these translations as unicode.
If there's no such line, or value it empty, - it will be interpreted as ASCII.

And TRS should of course be saved as UTF-8 (plain UTF-8, without BOM!).

Joseph DiPerla

Neat. I am sure there are quite a few who need this feature.
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

Gilbert

Quote from: Crimson Wizard on Sun 04/07/2021 04:16:31
If we have it as DLL we will definitely include it with Editor's distribution, there's no question about that.
Should be okay, but it's still safer to put a note somewhere to remind people to distribute their games with the dll file. Say, if for some stupid reasons (such as errr... saving space?) someone doesn't ZIP the entire Compiled folder of their game for distribution, but decides to remove a few files from it they may receive confusing reports from players, that some could run the game (as long as a compatible dll file is in the path) and some couldn't (can be either missing the file from the path or they have a version sdl2.dll file in the path that is not compatible with that particular AGS engine; an even nastier problem is a player might be able to run the game at one point, but after some updates of their system that somehow updated also the sdl2.dll in the path would suddenly make the game unstartable).

Another problem is when someone wants to run a game in a different version (e.g. drops the engine of say V3.8 onto the folder of a game created with V3.6) and if these two engine versions somehow use different version of the dll this may not work, until they also drops a suitable version of the dll file onto the folder. Swapping engine is considered a more advanced action though, so I think it's less of a problem here.

We're glad that currently the AGS engine only relies on one single external library to work, so either way it's not a very big problem ATM.

eri0o

We could have a directory inside the Editor install directory named platforms (or runtime) and then inside this directory have one for each OS: Windows, Linux, ... And then inside these, one for each Architecture.

Then when picking up the engine, the Editor would just grab everything in the directory specified. So in this way, if the engine was built with static library (which I prefer and think is the best approach) or dynamic library, it will work with both. Of course we still need to figure out default, but at least it could pickup both from it's specific engine directory.

Andrea1992

Hey guys. I opened my game with AGS 3.6.0 alpha 4 and everything has played amazingly. We made the game with AGS 3.5.0.24. I also tried the android launcher.

Quote from: Crimson Wizard on Sun 04/07/2021 02:51:20
This new version currently links SDL2 library dynamically, so you have to additionally have SDL2.dll.

Is this a big deal for people?

I do not think it's a big deal, it's great. The improvements ARE  a big deal. Many many thanks for the hard work.

The performance, animations, interactions, the whole game feels smoother and quicker than previous versions. I love that I can change the audio output device and the game reacts to that!

I'm not getting Potajito nor nightmarer issues. It's all good.

Some small things I noticed and questions:

*maybe i'm doing something wrong or missed something, but I cannot reproduce any video.
  I was using .ogv without problems in the 3.5 version. Now it says "Unable to load theora video 'videoname.ogv' ".
  I tried mp4 but it's not supported as you stated.
  Any recommendation? Thanks

*In full screen, it behaves similar to windows mode, I can move the cursor outside of the game (I have two monitors) and if I click outside, the game minimizes. This happens even if I "auto lock to window" in the mouse options in winsetup.
Something similar happens in AGS 3.5 with openGL only. When the cursor clicks very near the edge, it bounces down to the bottom of the screen and minimizes the game. Is it possible to fix this in AGS 3.5?

*Not important, just to mention, but in debug mode ctrl+X for changing rooms, I cannot write the room number as I used to in previous versions. I use a lot this function because it's faster to write the number than clicking the arrow (i have more than 100 rooms)

*And finally, I don't have much to compare to the android version  since it's the first time I use the launcher. Here I just have two questions.
The process to create a standalone apk is the same as previous versions? I have read about it but never tried. If the process is indeed the same, what libraries should I use?
And second, how can I get the keyboard to appear in the screen using the 3.6 launcher? anyway, sorry if this is answered in some other forums but couldn't find any.
In general, I love it! the game plays nicely on the phone. There are some rooms with big backgrounds, alpha channel or parallax that do not plays well, but It's an easy fix I guess.

We're releasing our game in STEAM in the couple of weeks, therefore we're using the AGS 3.5 version, we don't have the time to do a thorough test. But looking forward to do it and update it in the future.

Thanks again for doing this.
Have a great day.


Manu

I compiled 3.6.0.4 on my Mac from source code (followed the guide I posted some days ago in the Mac thread). My game works perfectly. The only problem that I found is that in windowed mode, there's no way to open the game with the window enlarged. The game always opens in a small window 320x200 in the center of the screen. I can drag the window corner and resize works perfectly, respecting the ratio, but the game always starts small. This is the config.

Code: ags

[graphics]
driver=software
windowed=1
screen_def=max
game_scale_fs=proportional
game_scale_win=max_round
filter=stdscale
vsync=0
render_at_screenres=1
match_device_ratio=1


I tried also with "game_scale_win=3", it doesn't change.


Another thing: how to distribute the game for mac? My game works probably because I have SDL2 installed on my MacBook, but if I want to send the game to someone else how can I embed the library?

eri0o

QuoteI compiled 3.6.0.4 on my Mac from source

How do you do it? CMake is wired to do full static library compilation. It doesn't depend on anything, you can check with ldd on command line.

Manu

Quote from: eri0o on Tue 06/07/2021 11:15:22
How do you do it? CMake is wired to do full static library compilation. It doesn't depend on anything, you can check with ldd on command line.

I don't understand your question. I just downloaded ags-v.3.6.0.4.zip, extracted it, copied the resources of the game, compiled it with "Cmake" and "make" (like I did with 3.5.1.8). Everything worked smoothly. It wasn't supposed to work?

eri0o

QuoteMy game works probably because I have SDL2 installed on my MacBook

Perhaps I am not understanding what you said. What do you mean by the above?

To clarify, all cmake builds are self contained in any OS, it's scripted to download all dependencies, build them on your machine, and static link to all of them. The result is a self contained binary that should work pretty much anywhere that's the same OS and architecture.

So if you are referring to a binary you built on MacOS, SDL2 is already inside the binary. It should work as long the standard C libraries are compatible across machines.

About distribution, you need to notarize and sign your application, here's a guide:
http://www.edenwaith.com/blog/index.php?p=112

Manu

Quote from: eri0o on Tue 06/07/2021 13:21:56
So if you are referring to a binary you built on MacOS, SDL2 is already inside the binary. It should work as long the standard C libraries are compatible across machines.

Ah ok, I get it now. I thought the SDL2 was not in the binary, because I read for the windows version the DLL should be zipped together with the exe. Or am I wrong?

eri0o

QuoteAh ok, I get it now. I thought the SDL2 was not in the binary, because I read for the windows version the DLL should be zipped together with the exe. Or am I wrong?

Windows version provided by the Editor is built with a different build system (using VS Solutions). And there hasn't been a decision yet to build it statically or to keep it dynamically yet, this is why it's not shipped together yet.

If you use CMake on Windows, a static-linked version of ags executable will be built.

For Windows and Linux, for distributable binaries, I recommend using the Docker Images generated by the CI or building the same images from the Dockerfiles as a standardized build environment - it's not needed, on Windows it should be fine, but on Linux you may have glibc incompatibilities when running your binary elsewhere.

Crimson Wizard

Quote from: Manu on Tue 06/07/2021 09:40:01
I compiled 3.6.0.4 on my Mac from source code (followed the guide I posted some days ago in the Mac thread). My game works perfectly. The only problem that I found is that in windowed mode, there's no way to open the game with the window enlarged. The game always opens in a small window 320x200 in the center of the screen.

I finally realized why that may be, will link a test build soon.

EDIT: https://cirrus-ci.com/build/5531686894043136

Crimson Wizard

Updated to Alpha 6
(use download links in the first post)

Backported a number of simplier Script API entries from the experimental ags4 branch; because many of them are ready for a while, and they are simple enough to not require big changes to the engine:

- DrawingSurface.DrawImage() and DrawSurface() now accept optional source rect coordinates, so you can draw a chosen part of the sprite directly;
Code: ags
DrawingSurface.DrawImage(int x, int y, int spriteSlot, optional int transparency, optional int width, optional int height,
		optional int cut_x, optional int cut_y, optional int cut_width, optional int cut_height);

- Room.Exists(): tests if the room of certain number is available;
- WaitMouse(): complements other Wait* functions.
- SkipWait(): skips current Wait (will normally only work from repeatedly_execute_always callback).
- All the Wait* functions now accept "0" as "no timeout", in which case waiting may only be interrupted using either corresponding input or SkipWait.
- All the Wait* functions now return a code telling how they were interrupted:
Quote* positive value means a key code;
* negative value means a -(mouse code);
* 0 means timeout or interrupt with a script command.
- Object.SetView() now resets loop and frame to 0 by default. Previously default was -1 which made object retain loop & frame, which was often unexpected, and could cause game errors.
- Object.ManualScaling and Scaling properties, now letting to scale an object by command similar to Character (previously objects were only scaled by the walkable area).
- Game.BlockingWaitSkipped: returns the last reason of the last blocking action interruption: this is same as Wait* function return value, but also works for skipped blocking speech, and so on.
- Speech.TextOverlay and Speech.PortraitOverlay: give access to the text and portrait overlays of a current blocking speech. In practice these are only available in repeatedly_execute_always callback. Among other things, these properties allow to detect appearance, removal, and change of the blocking speech; also calling Speech.TextOverlay.Remove() will work as a speech interrupt.
- System.Log(): prints into the engine log.


Oh, and Characters now may be scaled freely, not limited to 5 - 200% (new range is 1 - 32767 for technical reasons).

Manu

Great job! Thanks for adding System.Log(), super useful addition.

Laura Hunt

Quote from: Crimson Wizard on Thu 15/07/2021 01:02:15
- WaitMouse(): complements other Wait* functions.
- SkipWait(): skips current Wait (will normally only work from repeatedly_execute_always callback).
- All the Wait* functions now accept "0" as "no timeout", in which case waiting may only be interrupted using SkipWait.

Is -1 still a valid parameter for Wait* functions?

Crimson Wizard

Quote from: Laura Hunt on Thu 15/07/2021 10:13:50
Is -1 still a valid parameter for Wait* functions?

What is -1  :-\? I tried in AGS 3.5.1 and passing anything negative results in error.

Laura Hunt

Quote from: Crimson Wizard on Thu 15/07/2021 10:24:27
Quote from: Laura Hunt on Thu 15/07/2021 10:13:50
Is -1 still a valid parameter for Wait* functions?

What is -1  :-\? I tried in AGS 3.5.1 and passing anything negative results in error.

I seem to recall it was mentioned on Discord? I'll try to find the conversation, maybe I'm getting things mixed up...

Laura Hunt

Found the conversation and you're right; somebody mentioned that WaitMouseKey(-1) was an alternative in 3.5.1 to while(WaitMouseKey(1) == 0) {}, but indeed, it didn't compile. For some reason, the idea that -1 was valid had gotten stuck in my head.

SMF spam blocked by CleanTalk