I will make it so that you can just give the game exe as parameter instead of renaming it to ac2game.dat. Also I thought about incorporating the PE reading code from the PSP launcher so that the game data is automatically found if you pass the game directory as parameter to the engine.These two things are now implemented.
Furthermore plugin support for all platforms and also builtin plugins for all should be just around the corner.
ags game.exe
Adventure Creator v3.21 Interpreter
Copyright (c) 1999-2001 Chris Jones
ACI version 3.21.1115
ci_find_file: cannot change to directory: Compiled
Audio vox found and initialized.
Checking sound inits.
jack_client_new: deprecated
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
jack server is not running or cannot be started
Aborted (core dumped)
I'm pretty sure the engine is not currently capable of running under 64bit even if it compiles. There are too many int to pointer conversions and stuff.
Getting a 64bit compliant version of the source should be of high priority in my opinion. (mainly for linux)
I caved in and got the Blackwell games. The error was caused by the aastr library which used long* to access an int* value. Valgrind to the rescue again (nod). I pushed a fix to the repository.
About the error, that BigMc mentioned: It would be great if some more people would test the 64 bit branch on their system. Right now we don't have a lead on what is causing the engine to be loaded to different addresses on his system. This is something that should not happen for several reasons (1) The engine binary is not PIE enabled. (2) PIE is deactived in the system settings. Still, it is loaded to a different address every time. This is a problem because the script interpreter relies on global variables being accessible with 32 bit long pointers. As BigMc said, I cannot reproduce the error. It only occurs for me when I explicitly compile the engine with PIE support.
Should I try a different branch?No, no, I was asking, just in case. Refactory is still pretty unstable on 64-bit platforms. It's just that the bug sounds familiar.
I think the problem lies in the engine.Well, that's definitely in the engine, that's what I meant ;).
That was a bug in the saving code that I fixed now in the main branch (commit 205c56d693d903516b7b21beb454251e9489aab f). I don't know why it never caused problems on 32 bit.I've already fixed that in refactory branch some time ago. I wanted to ask JJS about this (since it was in his new code), but forgot :/.
When do you think is a good time to recommend people to use refactory? If there are no known bugs, why not now?I know only one bug related to freeing managed script objects that takes place when application window is closed by OS means (e.g. alt+f4 in windows), but it happens only when game is closing so maybe it isn't that critical.
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.
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:Was he speaking of main or refactory branch?
RoomStatus, GameState, GameSetupStructBase, maybe more
Allegro should use OSS if liballegro4.4-plugin-alsa is not installed.Apparently OSS support was removed from Ubuntu's Kernel: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/579300
That's what you get for removing Pulseaudio.A friend of mine removed the brakes from his bike as a kid to make it lighter. That's the spirit!
Allegro should use OSS if liballegro4.4-plugin-alsa is not installed.Apparently OSS support was removed from Ubuntu's Kernel: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/579300
That's what you get for removing Pulseaudio.A friend of mine removed the brakes from his bike as a kid to make it lighter. That's the spirit!
gcc -I../Engine -I../Common -I../Common/libinclude -O2 -g -fsigned-char -Wfatal-errors -DALLEGRO_STATICLINK -DTHIS_IS_THE_ENGINE -DLINUX_VERSION -DDISABLE_MPEG_AUDIO -DBUILTIN_PLUGINS -DRTLD_NEXT -I/usr/include/freetype2 -c -o libsrc/libcda-0.5/linux.o libsrc/libcda-0.5/linux.c
libsrc/libcda-0.5/linux.c:11:25: fatal error: linux/cdrom.h: No such file or directory
compilation terminated.
Adventure Creator v3.21 Interpreter
Copyright (c) 1999-2001 Chris Jones
ACI version 3.21.1115
AGS: ***** ENGINE STARTUP
AGS: Reading config file
AGS: Initializing allegro
AGS: Setting up window
AGS: Initializing game data
AGS: Initializing TTF renderer
AGS: Initializing mouse
AGS: Checking memory
ci_find_file: cannot change to directory: Compiled
ci_find_file: cannot change to directory: Compiled
AGS: Initializing keyboard
AGS: Install timer
Checking sound inits.
AGS: Initialize sound drivers
AGS: Install exit handler
AGS: Initialize path finder library
AGS: Initialize gfx
AGS: Load game data
AGS: Over the Edge
AGS: Checking for disk space
AGS: Initializing MOD/XM player
AGS: Initializing screen settings
AGS: Init gfx filters
AGS: Init gfx driver
AGS: Switching to graphics mode
AGS: Widescreen side borders: game resolution: 320 x 240; desktop resolution: 1367 x 770
AGS: Widescreen side borders: gfx card does not support suitable resolution. will attempt 426 x 240 anyway
AGS: Attempt to switch gfx mode to 426 x 240 (32-bit)
AGS: Succeeded. Using gfx mode 426 x 240 (32-bit)
AGS: Preparing graphics mode screen
AGS: Screen resolution: 426 x 240; game resolution 320 x 200
AGS: Initializing colour conversion
AGS: Check for preload image
AGS: Initialize sprites
AGS: Set up screen
AGS: Initialize game settings
AGS: Prepare to start game
AGS: Checking replay status
AGS: Engine initialization complete
AGS: Starting game
AGS: Loading room 26
X Error of failed request: BadValue (integer parameter out of range for operation)
Major opcode of failed request: 151 (XFree86-VidModeExtension)
Minor opcode of failed request: 10 (XF86VidModeSwitchToMode)
Value in failed request: 0x5c0000d
Serial number of failed request: 4921
Current serial number in output stream: 4927
Error: the program has exited without requesting it.
Program pointer: +72 (write this number down), ACI version 3.21.1115
If you see a list of numbers above, please write them down and contact
Chris Jones. Otherwise, note down any other information displayed.
Hey, JJS & BigMc, is the refactory branch merged upstream?Yes it is, as well as "main". Use "master" now. People say it is more stable on 64-bit linux too.
I've built an interpreter off of the main tree, but before the Revision Of Doom on November 29th of last year.Err... Revision of Doom?
Well, I read on a different thread that a significant scripting engine change went in that day, and that the tree should be considered a tad unstable after that. So I checked out the revision before that work, and built from there. Perhaps that was only in reference to a particular port?Ah, right. It was when new script interpreter was merged into what is now known as "master".
One factor which caused me no end of trouble was discovering that saved-game files seem to not always be portable (I assume there are data word size/alignment issues which can need fixing). Anyway, once I stopped trying to use the Wine-generated saved-game files, it seemed OKThe only possible reason for such incompatibility that I am aware of, is plugins which save their own data differently on different platforms. If the games you test do not use plugins, then this should be considered as a bug.
Forgive my ignorance here, but is it actually possible to currently compile and release a fully functioning Linux version of an AGS game with this port?You can take ANY AGS game*, take a port and run that game with that port on corresponding platform (linux, psp, android, ios).
Ah, sorry about the confusion. Yes, I understand that's how it currently works (and thanks for the confirmation!) I was more or less asking whether this specific Linux port is stable enough *right now* to release a commercial quality game?
Or wait a bit, it will surely be more stable in a few:=monthsyears.
Hopefully, if I provide nicely packaged installers for all the demos in their catalogue, I can convince Dave Gilbert to just sell native Linux versions of the games on Desura, Steam, and their website ;)
They are already there, but called "-windowed" and a "-fullscreen".Regarding this, I think we could eventually bring the cmdline params to standards? Like making a short alias preceded by '-' and long alias preceded by '--'.
They are already there, but called "-windowed" and a "-fullscreen".Regarding this, I think we could eventually bring the cmdline params to standards? Like making a short alias preceded by '-' and long alias preceded by '--'.
Regarding this, I think we could eventually bring the cmdline params to standards? Like making a short alias preceded by '-' and long alias preceded by '--'.
What are the default places for game data?I think we should put this in a readme. Anyway, here how it should work.
I could do this using getopt.h, but that's not available on Windows. Should we keep the current code with only long options for Windows and use getopt for everything else? Or can we live without commandline options on Windows? Everything should also be accessible via the config file right?I was thinking about writing a class for storing cmd args. That could also come handy to fullfil this user request: http://www.adventuregamestudio.co.uk/forums/index.php?issue=322.0
If we were to do Linux release we probably don't want to include a .exe file. Could we use something like ./ags agsdata.bin to launch? Where agsdata.bin is just the .exe file renamed?
I think we should put this in a readme.
I was thinking about writing a class for storing cmd args. That could also come handy to fullfil this user request: http://www.adventuregamestudio.co.uk/forums/index.php?issue=322.0
There are multiple possibilities. Ship two binaries with a script which checks which Allegro is present and chooses the binary accordingly, include the dynamic Allegro library as a fallback in case the system does not have it, or do a static build.My understanding is he wants to do a static build against Allegro 4.4?
My understanding is he wants to do a static build against Allegro 4.4?
Is that something that needs to be built ahead of time? I just assumed they would be built on the fly when we compile ags statically.Yes, definitely. You have to get the sources for Allegro 4.4.x and DUMB (0.9.3 I think, the newest one), patch Allegro (as described above) and then build them. Allegro goes first, then DUMB because it depends on it (aldumb). You also have to ensure that DUMB uses the newly built static libraries instead of the system Allegro libraries. You can take a look at how the libraries are cross-compiled for Android: https://github.com/adventuregamestudio/ags/tree/master/Android/buildlibs/x86 This might help with where to get the libraries, the flags used and how to build them without installing them over the system libraries.
When using the distributions Allegro, two binaries should be enough: one using Allegro 4.2 and one 4.4.
Wouldn't we need a 32bit and a 64bit one of each also?
It's no bug. Upstream did not give libaldmb a soname, so the distributions had to make up their own ones. AGS also works with Allegro 4.2.
You can take the libraries from a distribution.
EDIT2: We could include build date and time there.
Another idea would be to use the openSUSE Build Service (https://build.opensuse.org/) to provide AGS packages for all major distributions.
I have a Fedora 14 box that had glibc 2.13 and Allegro 4.2 on it. I can try that. Can you post "ldd shivah" from Debian Wheezy so I have an idea what we're talking about. Is that a 32 or 64bit install?
I like the idea of getting ags into a lot of the major Linux distros. ... AGS compiles quite simply, so it should be easy to package up.
Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).Can you provide a saved game close to that location?
Of course. I hadn't tried with previous builds of the code (or of the Linux runtime).Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).Can you provide a saved game close to that location?
Also, if you tried, did that happen to previous builds?
Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).
This should include a 32bit AND 64bit executable.
Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).
What was the issue?Ubuntu 12.10, Allegro 4.4 used to compile the latest (as of today) code... and found an odd bug with Primordia. The close-up for the generator doesn't disappear when you tell it to close. It doesn't disappear at all - moving to another room has it still there (and nothing underneath it is interactable, unless you're in the generator's location).
Fixed!
What was the issue?A silly typo rather than actual mistake. Wrong function was called by script command.
EDIT: Oh, I see, you didn't read the README. You must put the game into "data".
Now the only thing that's missing is a linux equivalent to winsetup.exe, so you don't have to find and edit acsetup.cfg to switch between fullscreen and windowed mode. A basic setup tool would be a good idea if you want to distribute a commercial game this way.
The demo works fine for me on Debian Wheezy 64 bit. :)
Now the only thing that's missing is a linux equivalent to winsetup.exe, so you don't have to find and edit acsetup.cfg to switch between fullscreen and windowed mode. A basic setup tool would be a good idea if you want to distribute a commercial game this way.
EDIT: But you should better not change that, because it's used to check if a game is compatible with the engine.
You can always change the help text in Engine/main/main.cpp.
Be VERY careful when changing existing command line options, Editor may use these to run games. If you change in one place, make sure you scan ALL the code and make appropriate changes.
Be VERY careful when changing existing command line options, Editor may use these to run games. If you change in one place, make sure you scan ALL the code and make appropriate changes.
My understanding was that they were JUST added last week. The Editor should not rely on these flags for anything.
#1) What are the default windowed/fullscreen/gfxfilter settings if no acsetup.cfg is found? I'm thinking a sane default is "-fullscreen and StdScale4" i.e. Fullscreen + stretch?Factual implementation, it is Fullscreen + Software Filter (No Scale). I doubt x4 scale is sane default, because the game may have large resolution. 800x600 with x4 scale will be 3200x2400.
#3) Do we need a StdScale5 or maybe even StdScale6? A 1080P display is 1920x1080p. If you scale up a 320x200 game 4x (the current highest) you only get 1280x800. I'm thinking we want a full 1080P option?I am not an expert in this area, but from quick glance in the code I see that there's no such filter objects as "x2" or "x3", instead there's a single Scaling Filter class, which takes "multiplier" as parameter. I think few simple experiments could show if this may be 5, 6, or more.
Are we ready to release an official version 0.9 of the Linux engine?
BigMc can you create another version of your package that includes the binary and the libs?
I also don't think it will happen while a savegame compatibility breaking change is right ahead.It's in "develop" branch. That branch currently contains only changes to (de)serialization routine. I tested that on number of games and it looks working. If it does not break anything, they could be merged to master right away.
#2) Is there any real case where you want fullscreen but NOT stretch? I hate doing -fullscreen and the game loads and it's 320x200 with black border around the whole game. I'm thinking maybe we want to default to "stretch to fit" if the user selects fullscreen?This seems to be a bug in Allegro to me or maybe it is just how Linux works, no idea. The problem is that on Windows the request for a fullscreen resolution that is not supported by the graphics driver will just fail. But on Linux it looks like the system returns success and then switches to the next best supported resolution (or does not switch at all in fact) which puts the game unscaled in the middle of the screen.
Why should I do that right now? There was not a single change to the code since the last one.
Or is your best bet to just do StdScaleX where X is as close as you can get?
Where do we stand on that savegame bug? I only ask because Wadjet asked me to package up a beta version of GeminiRue this morning.Ouch. Didn't realize it is this urgent.
Maybe it would be best to let AGS never change the screen resolution on Linux, but choose an appropriate scaling automatically instead.I would say that this would be the best for Windows too. The engine knows the game resolution and it queries the desktop resolution so it would be possible to calculate the appropriate scaler automatically. Sinced scaled graphics are more costly on the CPU we should make this optional, maybe with a new scaler parameter like "StdScaleAuto".
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 would say that this would be the best for Windows too. The engine knows the game resolution and it queries the desktop resolution so it would be possible to calculate the appropriate scaler automatically. Sinced scaled graphics are more costly on the CPU we should make this optional, maybe with a new scaler parameter like "StdScaleAuto".
BigMc: can you do a build of your ags+libraries with the big merge that just happened? Can you give is a BUILD_STR=$(date +%F)? I'll use that binary as a basis for my Gemini Rue beta.
I guess so. Since it's beta test. Let's hope testers will test it good.
This is interesting. Using the game's data files with a freshly-compiled executable is giving me sound corruption/speed issues (at random it seems, for at least a couple of seconds and usually longer).
Yup. Compiled today using the savegame changes, using it with the full version of Gemini Rue.This is interesting. Using the game's data files with a freshly-compiled executable is giving me sound corruption/speed issues (at random it seems, for at least a couple of seconds and usually longer).
Can you provide more details? You're using an engine compiled today (after the big checkin of savegame stuff)? What game are you having problems with? Gemini Rue?
Yup. Compiled today using the savegame changes, using it with the full version of Gemini Rue.
Here is the new build: http://people.debian.org/~thansen/ags+libraries_20130204.tar.xzNot worried about the missing rain sounds, aware that that's due to platform issues. Issues noticed primarily during the introduction sequence, during the start of the game and sometimes when you switched tasks.
I added automatic selection of the appropriate StdScale filter for the case that no filter is set, but did nothing to make sure that the screen resoltion is not changed.
EDIT: By the way, missing menu sound and rain in Gemini Rue are expected, because they were disabled by the creators unless you use Windows.
Not worried about the missing rain sounds, aware that that's due to platform issues. Issues noticed primarily during the introduction sequence, during the start of the game and sometimes when you switched tasks.
Ubuntu 12.10, 32-bit.Not worried about the missing rain sounds, aware that that's due to platform issues. Issues noticed primarily during the introduction sequence, during the start of the game and sometimes when you switched tasks.
I did not experience any of the sound or delay problems you mentioned. I'm running Fedora 64 bit, what are you running?
Is this binary the version with BigMC's StdScale auto-select?
Anyone care to take this package out for a test drive and give me any feedback before I send it off to Wadjet.
Also, is ags_shell.dll a Windows plugin?There is a function stub for it in the engine. This plugin basically provides access to the ShellExecute Windows API function. The Gemini Rue Demo uses it to open a website in the browser.
No Pulseaudio restart was needed here. Seems to be working better with the latest Git changes to the engine code.But these changes have nothing to do with audio nor game speed. It sounds like this effect is either random, or changes with every rebuild?
Sounds like an unintended side-effect of the scaling code, perhaps? It seems odd that it should change anything sound-wise though.No Pulseaudio restart was needed here. Seems to be working better with the latest Git changes to the engine code.But these changes have nothing to do with audio nor game speed. It sounds like this effect is either random, or changes with every rebuild?
Sounds like something I once experienced with a different engine. There was a bug in a sound library that was used, and the sound got corrupted sometimes. Even after quitting the game engine and restarting, the sound was still corrupted. Rebooting would help. That sound library is not used in AGS though.That possibility did cross my mind. So we need to eliminate the possibility of it being outside of the AGS source?
Maybe AGS uses external code incorrectly. Does not shut it down properly or so.Easily possible. Have you seen quit() function? It basically aborts the application at any random point, without returning to main loop. It does some cleanup, but may miss some things.
The version label built in program is "3.21.1115", although the build is technically not 3.21.1115 anymore (and for quite a long time already).
Since it is going to be used for official game releases (commercial or not), I think it would be appropriate if the version is updated.
We just have to think this out carefully and preview what consequences such change will have (if any).
I am going to investigate more on this.
Here, autoscaling is disabled, because gfxfilter=StdScale2 is set in acsetup.conf. Also, is ags_shell.dll a Windows plugin?
The version label built in program is "3.21.1115", although the build is technically not 3.21.1115 anymore (and for quite a long time already).
Since it is going to be used for official game releases (commercial or not), I think it would be appropriate if the version is updated.
We just have to think this out carefully and preview what consequences such change will have (if any).
I am going to investigate more on this.
Should we change this before we release?
Ultimately the simple solution would be a BUILD_STR. Did that get rejected? I didn't get any feedback, or maybe I just don't understand how github works.
No Pulseaudio restart was needed here. Seems to be working better with the latest Git changes to the engine code.
I strongly suggest advancing the build number, in some way, prior to the beta.
I think games rely on the version number. I think the easier thing to do, is just version the Linux version separately.
You did not create a pull request for that. (BTW, I don't consider myself responsible for merging pull requests.)
He did create a pull request: https://github.com/adventuregamestudio/ags/pull/53You did not create a pull request for that. (BTW, I don't consider myself responsible for merging pull requests.)
Would that be Crimson Wizard or JJS?
I can merge requests, but I think JJS knows makefiles (and linux in general) better.You did not create a pull request for that. (BTW, I don't consider myself responsible for merging pull requests.)
Would that be Crimson Wizard or JJS?
But, regarding the version. What is exactly a problem here?
So, what's next? Resonance? Primordia? (laugh)
Do we need any of the sound settings on Linux?
So, what's next? Resonance? Primordia? (laugh)
I hope we can do all of them! :)
Ok I removed that Windows DLL, and simplified the acsetup.cfg like I mentioned in the previous post. I'm pretty happy with this release:
http://www.perturb.org/tmp/GeminiRue-beta-2013-02-05.tar.gz
I'll send this on Wadjet as their initial beta test.
EDIT: By the way, missing menu sound and rain in Gemini Rue are expected, because they were disabled by the creators unless you use Windows.
I want to write a small configuration generator script for the releases. Is there a way to get the current display resolution from ags/allegro? Would it be possible to add a --display_geometry or something that would spit out: color depth, resolution, etc? Then my script could parse that and "suggest" intelligent defaults for the config?
For the Gemini Rue beta, a LOT of people complained about the game launching in fullscreen and only seeing a tiny postage stamp sized window in the middle.
For some reason the game checks the platform it is running on. Only if the platform is "Windows" it will enable the rain plugin.
The mobile platform ports all report back "Windows" to avoid this issue (and similar ones with other old games). But for a new release this check should be removed in the game script itself.
Is there maybe still a check for the platform to be Windows in place somewhere?
For the Gemini Rue beta, a LOT of people complained about the game launching in fullscreen and only seeing a tiny postage stamp sized window in the middle.
Since Janet is spinning a new version without the OS check, it would be a good time to repackage it with BigMC's autoscale feature. Introducing a config editor, simple or otherwise, seems like unnecessary work. Has anyone pinged Electroshokker? Might as well check out the old GUI code and see how portable it is. Why reinvent the wheel?
Introducing a config editor, simple or otherwise, seems like unnecessary work.It should be fairly easy program to write when such need arises, at least for Windows/Linux, using Qt, wxWidgets, maybe Python, idk, there's many.
Might as well check out the old GUI code and see how portable it is.Do you mean Elektroshokker's one, or vanilla AGS? The latter is non-portable, because it uses WinAPI.
Why reinvent the wheel?We don't re-invent, we re-implement, that's totally different thing :D.
Do you mean Elektroshokker's one, or vanilla AGS? The latter is non-portable, because it uses WinAPI.
I thought the autoscale feature did make it in the release that we used?
As for a config editor, it's SO simple I think we should do it. I have half a perl script written already. I'm thinking we should check for acsetup.cfg on launch, if it's not there launch the configuration editor.
I thought the autoscale feature did make it in the release that we used?
It is in my upload from February 4, but you used the older one (at least concerning ags64).
As part of the Gemini Rue beta we had several reports of people running at 1920x1080. Currently the engine only supports up to StdScale4, are we able to do 5 or 6?Simple answer is - not fully sure.
As part of the Gemini Rue beta we had several reports of people running at 1920x1080. Currently the engine only supports up to StdScale4, are we able to do 5 or 6?
Crimson Wizard answered this last week; there are Hqx2 and Hqx3 filters. Higher multipliers would need to be implemented (I'm at work right now, so I can't look at that to see if there are any inherent limitations, sorry). It may be easy it may be hard, someone will have to look.
But, hmm, thinking further about this. If rain is in script module, it might be pretty slowing factor for weaker platforms. Is it possible to, for instance, disable it for PSP, where we had speed issues lately? Just a thought.
I can't believe I released the Gemini Rue beta without BigMcs autoscale! That really sucks.
We have no plans for a PSP release, so it shouldn't be an issue.But it is already possible to run Gemini Rue on PSP using PSP port...
We have no plans for a PSP release, so it shouldn't be an issue.we could encourage game developers to add perfomance options to their games, like switching extra effects on/off.
These options could be hidden, and activated only from script as a reaction to platform check, like either game runs on "hi-end" or "lo-end" platform.
from end-user point of view the publisher should be responsible for both engine and game quality, so they see them as a single whole, I guess.
Yes, Elektroshokker's. Looks like he logged in here not too long ago, so a PM might get his attention :)
Though, if I recall, it used an old GTK or something and may need to be rewritten anyway. I suppose we could bung it out in Python and use iniparse & PyGtk to make it pretty.
I pushed a change enabling StdScale up to 8x. Seems to work just fine. Don't know about performance, my PC handles it.
Of course, I'm going to wait around a wee while to see if Elektroshokker is around and can throw the code for his tool at us.
Ah, yes the glibc versioning. I forgot. I have that set up partially (I set up my 32-bit build environment on Debian because of that issue, but have continued building 64-bit on Ubuntu). I might as well set up the 64-bit version as well. Thanks!
I think it's also no big deal to set up Debian chroots on Ubuntu and use them for building.
That way BigMc isn't the only one who can do official builds.
Here you go: http://people.debian.org/~thansen/ags+libraries_20130206.tar.xz
AGS: Widescreen side borders: game resolution: 320 x 200; desktop resolution: 1366 x 768
AGS: Widescreen side borders: disabled (not necessary, game and desktop aspect ratios match)
Also, there is an utility, made by one guy, which allows to "cut" Windows binaries from game exe, producing a clean game data package (this also saves 0.5-1.5 megs depending on game version): https://github.com/rofl0r/agsutils. That may be used meanwhile.
BigMC, just noticed something in widescreen mode, with auto-scaling. It seems to not be adding widescreen borders (i.e., it's off-center) even though it claims to have checked it and found it unnecessary:
So it's disobeying umask? Probably we could use umask() to set the process permissions mask for file and directory creation somewhere in the Linux port's initialization code (in an "#ifdef linux" section).
I don't think it's disobeying, it's specifically being told use 0.
Ah! So, we simply need to make a platform-dependant define and drop that into the mkdir() and open() calls (set to zero on on-UNIX platforms).Windows (or rather DOS) version of mkdir does not take any permission parameter at all.
No, quick hacks are bad news. They just build and build until nobody wants to fix it! We can do it properly and I have no problem conforming to the style.I just remembered I have a branch with directory helpers in my local repository, and all mkdir calls are replaced with custom CreateDirectory implementation. Did that a while ago, but could not find time to finish/test these. Probably something to do on current weekends.
Was this a rain plugin that was used? Is that something that's going to be available on their Linux build.I don't know the situation around this release, but doesn't WE have game source? In that case you could check how this rain was run.
The plugin to create rain (the SnowRain plugin) was indeed removed. BUT it was replaced by the SnowRain module which does EXACTLY the same thing. We absolutely would not remove the rain from Gemini Rue as it would irreparably damage the atmosphere of the game. So if you see rain missing, it is a very, very bad bug!
I can provide you with Windows build of our engine if you need one.
I reran the test... When I use the .exe provided from Wadjet I see rain on the main menu. If I use the acwin.exe nightly (2013-02-07) build you posted I do NOT see rain. Looks like something is wrong with the engine?
That warning is because the second parameter is implicitly cast to void* for every call to ccAddExternalFunctionForPlugin(). Generally it is a good idea to reduce the warning count and especially to get the source to compile without compatibility settings (e.g. -fpermissive). In this case it is easy and harmless, some others might be more subtle and indicate an underlying bug. So just explicitly casting everything (which would silence a lot the warnings) is not helpful in the long run.Are you saying that it'd be better to do the explicit cast with the warnings scottchiefbaker has indicated?
BTW, JJS, will there be any change to plugin stubs registration?I pushed the change. Stubs are now only registered if the game tries to load the plugin and neither the plugin can be loaded nor a built-in plugin is found.
Looking at cleaning up the build process, what are these errors?These are legacy issues, there are pointer types stored as 32-bit ints. I think these parts of code may be removed, because AFAIK they never run anymore.
Can someone review/check-in this patch to alfont.c to clean up the build process a little.
JJS, I have a bug report from a Linux tester on the Quest for Infamy demo. It seems, at first blush, that odd/unusual screen resolutions make the new auto-scaling code bug out:Do you know what scaling was used?Code: Adventure Game Studio
I haven't dug into it much further. I cannot actually reproduce it myself, as none of my hardware is compatible with that resolution. Perhaps it's just arithmetic.
Can someone review/check-in this patch to alfont.c to clean up the build process a little.Ok, buddy, I did that for you; pull request sent. If JJS agrees, then it will merge cleanly to the tip. :)
The engine should not change the resolution, at least on Linux and Windows when auto scaling is enabled. I had a look at it, but it is harder than it sounds to do it without breaking anything.
JJS seem to be absent for few days, so I'll do that.
For the future: I suggest doing fixes in separate branch, like "master-fixes".
Also, important thing is - if there were significant change in the main repo, simply merge changes from it to your personal branch, that will make your pull request valid again.
Should be 4x, but it does not matter.
The engine should not change the resolution, at least on Linux and Windows when auto scaling is enabled. I had a look at it, but it is harder than it sounds to do it without breaking anything.
The engine should not change the resolution, at least on Linux and Windows when auto scaling is enabled. I had a look at it, but it is harder than it sounds to do it without breaking anything.
When you say "should not change the resolution" do you mean that would like it not to, or that it is an error for that to occur? I'm assuming the former, not the latter. Also, I'm not really sure why I addressed that to JJS (brain fart on my part).
The problem is that if you just make up some bogus resolution and try to change the screen resolution to that (that is basically what AGS does), then on Windows Allegro just says it won't work and AGS tries something different, while on Linux Allegro tries to do it and crashes.This sounds like there is a need of "CheckIfSupported" function (or "GetSupportedResolutions")? Maybe Allegro has one.
It's no problem for me to update this if someone asks, but I don't have a good way to provide daily builds.
On a side note... is it at all possible to add something like ctrl + enter to toggle between fullscreen and windowed?
Autoscale is fine, but changing to unsupported resoltions and crashing is still there. It depends on the combination of screen resolution and filter used.
All I did was making sure an appropriate filter is selected. I didn't change the code that sets the video mode and that code still selects a resolution in questionable ways.
Using this build, which has the snowrain stub functions corrected, any reason to not use this for a Gemini Rue build? Anything else outstanding?Well, I did not have any plans on that. I've switched working in a separate branch (develop) already, further cleaning/factoring the code.
On a side note... is it at all possible to add something like ctrl + enter to toggle between fullscreen and windowed?No idea. But, frankly, I'd won't do that as a last-time update. As you may have already noticed, resolution stuff is pretty fragile in AGS.
At this stage it might be worthwhile to re-write the whole thing. If the (eventual) plan is to switch to Allegro 5 (or something else), it'll likely become necessary anyway.Using this build, which has the snowrain stub functions corrected, any reason to not use this for a Gemini Rue build? Anything else outstanding?Well, I did not have any plans on that. I've switched working in a separate branch (develop) already, further cleaning/factoring the code.
Unless there are bugs or any issues preventing people from playing the game, I think it is ok to use current version.On a side note... is it at all possible to add something like ctrl + enter to toggle between fullscreen and windowed?No idea. But, frankly, I'd won't do that as a last-time update. As you may have already noticed, resolution stuff is pretty fragile in AGS.
In my vision, whole thing should be carefully investigated and documented first.
If someone with more patience than me wants to give the resolution issue a go: There is also another way to deal with it, namely to make the OpenGL backend JJS wrote for the mobile platforms ready for Linux. In that case AGS draws in whatever resolution it wants to a virtual screen which is stretched to the screen by OpenGL. I'm sure this will also increase speed.
For the task of switching resolutions, yes I think a resolution should be selected from a list of supported resolutions, rather than being guessed. To be clear, this list must come from the OS, not from within AGS. But even if Allegro can provide such a list, there is still the problem that on Linux Allegro won't reliably switch the resolution back to what is was before upon quitting. And since we can avoid switching resolutions with filters, we should do it.
If someone with more patience than me wants to give the resolution issue a go: There is also another way to deal with it, namely to make the OpenGL backend JJS wrote for the mobile platforms ready for Linux. In that case AGS draws in whatever resolution it wants to a virtual screen which is stretched to the screen by OpenGL. I'm sure this will also increase speed.
AGS: Widescreen side borders: game resolution: 320 x 240; desktop resolution: 1680 x 1050
AGS: Widescreen side borders: gfx card does not support suitable resolution. will attempt 384 x 240 anyway
AGS: Attempt to switch gfx mode to 384 x 240 (32-bit)
This information should be printed in console (at Linux), and also in "agsgame.log".AGS: Widescreen side borders: game resolution: 320 x 240; desktop resolution: 1680 x 1050
AGS: Widescreen side borders: gfx card does not support suitable resolution. will attempt 384 x 240 anyway
AGS: Attempt to switch gfx mode to 384 x 240 (32-bit)
How/where are you getting this information? When I run ags on GeminiRue I don't see the output you're mentioning. Is there some debug mode I'm not using?
How/where are you getting this information? When I run ags on GeminiRue I don't see the output you're mentioning. Is there some debug mode I'm not using?
Linux is using ALSoftwareGraphicsDriver.
Produced on the console, even from a stripped release build.
1) ALSA not set up properly in acsetup.cfg
s_d, most of the iffy stuff goes on in graphics_mode.cpp.
1) ALSA not set up properly in acsetup.cfg
Can you elaborate?
1. Audio didn't work for me, i use alsa and has no pulseaudio.
Checking sound inits.
AGS: Initialize sound drivers
Unable to initialize your audio hardware.
[Problem: No supported synth type found]
3. The game crashed.
AGS: Loading room 1
An error has occurred. Please contact the game author for support, as this is likely to be a scripting error and not a bug in AGS.
(ACI version 3.21.1115)
Error: Error running function 'room_Load':
Error: Null pointer referenced
AGS: ***** ENGINE HAS SHUTDOWN
AGS: Debug system: shutting down output subsystem... ()
It also dies trying to load room 39 and room 28.
I have a pretty good idea as to why it is crashing in those rooms. I believe it has something to do with the music errors you referred to previously. When those rooms load, it checks what track is currently playing, and if you couldn't initilize the sound drivers that could result in the crash.
The problem was that i had no midi device since it's an internal sound card (codec).
"aplaymidi -l" does show midi support but there's no /dev/midi0X so i needed to add digiid.Code: INI
Is there anywhere i can find valid options for acsetup.cfg and explanations of them?
Using this build, which has the snowrain stub functions corrected, any reason to not use this for a Gemini Rue build? Anything else outstanding?
These things are more relevant for an AGS release. Or do you think about doing a beta AGS release?
Do we want to clean up the build process a bit before we look at an "official" release? There are still quite a few warnings on compile.Many of those warnings existed in AGS for years, I think.
These things are more relevant for an AGS release. Or do you think about doing a beta AGS release?I was thinking merely about adding a human(end-user)-readable changelog to the repository.
I was thinking merely about adding a human(end-user)-readable changelog to the repository.
Do we want to clean up the build process a bit before we look at an "official" release? There are still quite a few warnings on compile.
s_d, most of the iffy stuff goes on in graphics_mode.cpp.
Along these lines, is it just me, or is init_gfx_mode() actually recursive?Yes..... but I guess you haven't yet seen the parts with "goto" jumps up from "while" loop?
I see that 1680x1050 is not actually that uncommon of a display resolution for Linux users. With further research, I've learned that it was actually a very popular display resolution for high-end gaming laptops (15.4"-17" panels) between 2003-2006.It is also the resolution I am using right now on my desktop!
Anyway, hopefully I'm not annoying you folks too much with my rambling... just thinking out loud (or in paragraphs, actually).The only thing that annoys me - and sorry for being so frank - is when people talk but not do. I hope you are not just telling us what's wrong, but planning to find an actual solution meanwhile ;).
The only thing that annoys me - and sorry for being so frank - is when people talk but not do. I hope you are not just telling us what's wrong, but planning to find an actual solution meanwhile ;).
I don't mean to criticize code quality, I'm just puzzled by CJ's intent, in some places.I think the reason is very simple: these pieces were written by less experienced coder (and maybe hacked later to save time). If you compare different parts of engine, and, especially, new editor, you will notice a significant change in style and code quality between them. Engine bears legacy code from 1998.
Also, there isn't any while-loop escapism occurring in graphics_mode.cpp, where I'm looking now. :)https://github.com/adventuregamestudio/ags/blob/master/Engine/ac/dialog.cpp#L549
Perhaps just keep to myself until I have patches, then?Well, the thing is, there are very few people actualy working on the engine, and our work has been pretty separated so far, everyone keeping to its own task. It is a bit difficult to refer to everything... I mean, it would be nice if someone could help you, but I don't think it will be me, because I am pretty much focused on different things now.
So, right now, my focus is to find a good method of discovering supported modes.
It is a bit difficult to refer to everything... I mean, it would be nice if someone could help you, but I don't think it will be me, because I am pretty much focused on different things now.
Well there's Allegros get_gfx_mode_list(). But after another look at ali3dsw.cpp, I found that every mode is expected to work when get_gfx_mode_list() fails to supply the supported modes. Maybe the crashes are caused by the last 'return true' in the following code?
Allegros documentation says that get_gfx_mode_list() does not guarantee a result, so switching to another driver is still a hack. A better solution would be not to switch resolutions if there is no list of supported resolutions.
I'm not objecting to any changes, I'm just advising. :)
So, what I will do is try to prepare a "pretty" patch using the X windows driver. I will to make it refuse to switch modes if none are returned by get_gfx_mode_list(). A couple of opinions; do you think it would be good to return false from IsModeSupported() only for Linux? Right now the mobile ports return early. Does Windows (or old OS X) need that return true? Do you think it's worth plumbing up an undocumented "try anyway, shoot yourself in the foot" option to permit blind mode-switching? I don't know for sure if this behavior is needed somewhere.
So you will implement the possibility to keep the desktop resolution? Because right now if IsModeSupported() always reports false somewhere (because there is no list of supported modes), then the engine won't start at all, right?
We can either quit (gracefully?) with an AGS error informing the user that no compatible display mode ("Failed, resolution not supported"), which is not the same thing as an improperly handled internal X error,It is effectly the same: AGS won't work in fullscreen mode for people who are affected.
or I can figure out some way to display the game in the middle of the screen in it's native resolution (which is almost certainly smaller than the desktop display resolution). I'm not really sure how to accomplish that, yet, but I at least have to try.We still have StdScale filters and the possibility to select a matching one.
Ok, that can maybe improved by changing the driver, but we are talking about changing the return value of IsModeSupported() now.
We still have StdScale filters and the possibility to select a matching one.
There is no specific reason why the first attempted resolution would happen to be supported, but without changing the driver, it will not try any others. The next one in the list could have worked!
Everyone still alive? Been awfully quiet around here lately.And what we were supposed to do here? :)
CW, BigMC; the changes to avoid mode switch require slightly more refactor than I'm comfortable with for an impending release. I suggest you only accept the driver change to GFX_XWINDOWS for 3.30. This is a tiny patch, low risk, and it has the potential to bring playability to many more configurations (e.g., all boxes with compatible resolution that just happens not to be probed first).
I'm fine with that.
The only other driver is GFX_XDGA2 and that requires root permissions, so it isn't an option anyway.
With patches like this one, and future ones in a fix branch, should I still submit pull requests to you from it, or would you rather a different way to fetch specific commits?I don't know, we don't have an established rule for that, just some habits. I found it is simplier to make very small changes directly to "main" branch, and big changes that would require number of commits to the separate branch. Also, I think that it is not convenient to keep the "fix" branch for the future, because you will have to update it from master, practically creating parallel branch. The only parallel branch we should have is "develop".
Also, I've noticed your naming convention for commit messages, and probably should always put "Engine: ..." since that's where I'll work. I'll remember to do that.That was JJS's convention, he used to name commits like "Android:" or "Linux:" :)
Any comments from other linux users on this patch?It's pretty awesome I'd say. Mode switching for fullscreen now works on my Linux Mint and unsupported graphic modes properly return failure.
You saying framebuffer support under Linux should officially be removed (if it was ever really there or "official" in the first place) then? Makes sense.Any comments from other linux users on this patch?It's pretty awesome I'd say. Mode switching for fullscreen now works on my Linux Mint and unsupported graphic modes properly return failure.
The only downside I could see is that running AGS without X will now always fail I guess. But since a) nobody does that and b) the Allegro 4.4 Debian package does not contain the framebuffer driver anyway, it doesn't really matter.
I am still interested to hear about Gemini Rue status. Did they finish the beta test?
I don't know, we don't have an established rule for that, just some habits...
...
That was JJS's convention, he used to name commits like "Android:" or "Linux:" :)
Any comments from other linux users on this patch?It's pretty awesome I'd say. Mode switching for fullscreen now works on my Linux Mint and unsupported graphic modes properly return failure.
The only downside I could see is that running AGS without X will now always fail I guess. But since a) nobody does that and b) the Allegro 4.4 Debian package does not contain the framebuffer driver anyway, it doesn't really matter.
You saying framebuffer support under Linux should officially be removed (if it was ever really there or "official" in the first place) then? Makes sense.
I've another patch just about ready to send, which will permit a compile-time option to restore the original behavior.Is it the proper thing to do? Can't the program test that XWindows first, and auto-driver later, when the first fails?
Second, I've built a new distributable ags+libraries
build-essential is installed right?Yup. It compiled just fine until last night. Raring is still in development, so it could easily be an error of omission on Ubuntu's part in their package changes. Of course, it could also be part of other package changes, which could mean having to find out what dependency/ies have to be installed to fix it. So long as it isn't something being removed, I guess.
libsrc/alfont-2.0.9/alfont.c:14:21: fatal error: allegro.h: No such file or directory
Second, I've built a new distributable ags+libraries
Great! Was the process documented well enough? Did you make sure to build the 32 bit executable with rpath "lib32"? If you use the debian stuff to build in a chroot, that works by setting the environment variable DEB_BUILD_OPTIONS=rpath=lib32
I'm packaging an AGS title for Linux for a friend of mine (who'd prefer that the title wasn't publicly announced for Linux prematurely), and I've been encountering audio issues with Pulse (which I've seen mention of in this thread) with my builds. I'd like to resolve these before we start broader testing and would consider an interim workaround if anybody's got any ideas (using padsp to force alsa doesn't help, and I haven't had much luck with any cfg settings either).
It sounds like the resolution for this that's currently being pursued is the Allegro5 port which Crimson Wizard and s_d (?) have been talking about. I have a tiny bit of allegro experience, but I don't feel like I have enough familiarity with how AGS' innards work to try tracking this down, and I don't have enough availability to sink my teeth into the Allegro5 porting effort. I can certainly offer encouragement though :D
So far I've been using Allegro4.4. I've noticed that some are talking about 4.2 - are there any know issues with 4.4 and AGS that I might have missed?
I also read a few pages back that people had been working on config generation scripts (and trying to get ahold of source for a UI?). I had planned to make something quick and dirty using Zenity, but if there's other stuff in the works, I might be able to throw a little time at helping things move forward.
Thusly, I would be ever so grateful if you would give these a test-drive on Wheezy for me (we don't support Squeeze, right?).
Hey, Cheese, what's up? :)Small world, hey? :D
If all goes well, it'll be two titles :)I'm packaging an AGS title for Linux for a friend of mineOoh, exciting! Another title!
What are you running? What is the nature of your Pulse glitches?
We have no reason to think that A5 will do anything to help this whatsoever, as it doesn't seem like an A4/Pulseaudio problem specifically (nobody is reporting this issue on other A4 Linux games)... Recently, I've had some personal challenges, and frustratingly, my work there has not progressed as I've wanted. I am committed to working on it, though.Yeah, OK. I'd gotten the wrong impression from your post in the second Gemini Rue beta thread. I can see now that what you were saying about the issue was unrelated to the A5 migration.
I also read a few pages back that people had been working on config generation scripts (and trying to get ahold of source for a UI?). I had planned to make something quick and dirty using Zenity, but if there's other stuff in the works, I might be able to throw a little time at helping things move forward.
Well, Electroshokker built this: http://www.adventuregamestudio.co.uk/forums/index.php?topic=37968.msg501047#msg501047
...which apparently worked really well, and properly configured DIGIMID for ALSA (one bug report came from a Slackware user who was Pulse-free... setting up the proper DIGIMID index in the acsetup.cfg fixed his wagon). I'm fairly content to continue porting forward the util, once code appears.
scottchiefbaker has a simple generator script in-place for the Gemini Rue beta which may be sufficient until we have a GUI. Perhaps he'll share it with you?Could be worth taking a peek at. If you're keen, get in touch, scottchiefbaker :)
Thusly, I would be ever so grateful if you would give these a test-drive on Wheezy for me (we don't support Squeeze, right?).
The issue I've been encountering can best be described as crackly audio (I'll see if I can get a recording of an example during the week).
I had previously encountered sped up audio, but I haven't seen that for a while (and can't recall what I did to trigger it). I've had similar crackly audio issues with a number of titles in Wine which normally go away with a pulseaudio -k, and of course in the Gemini Rue beta.
Runs nicely on my F17 install. 0.5 sec worth of crackly sound when starting the title I'm packaging, but it comes right every time. It also seems to recover happily from switching focus after a second or so of crackly audio.
On my Wheezy VM, I get crackly audio no matter what I try (the same issues I'd been experiencing with my own build). I don't have a proper install to test on at the moment though.
For what it's worth I run AGS on Fedora 17 and Fedora 18 both 64 bit, three different machines, and haven't had any audio crackling. Some users HAVE reported it though, I suspect a driver issue incompatibility with AGS/Allegro
What type of audio do you have? Any other audio issues on your system?I'm running a Creative Audigy 2 Platinum Ex. Never really had any issues beyond a couple of Wine games (like Rage and Orcs Must Die 2) having this crackly audio thing from time to time (quitting and running pulseaudio -k has always sorted it out). My partner encounters it when playing Dead Island as well. I think she's running onboard audio (looks to be an intel chipset).
Yep, that's it.The issue I've been encountering can best be described as crackly audio (I'll see if I can get a recording of an example during the week).I got around to uploading to YouTube my instances of it:
Am I to understand, then, that restarting Pulse no longer eliminates the current incarnation of your audio corruption?With your build, pulseaudio -k doesn't fix it on my Wheezy VM. With my build, it doesn't fix it on my desktop :D
It's also interesting to note that my Wheezy VM is running from a MacBook Air rather than my F17 desktop.Runs nicely on my F17 install. 0.5 sec worth of crackly sound when starting the title I'm packaging, but it comes right every time. It also seems to recover happily from switching focus after a second or so of crackly audio.
On my Wheezy VM, I get crackly audio no matter what I try (the same issues I'd been experiencing with my own build). I don't have a proper install to test on at the moment though.
This is good info, thanks. It's probably fairly instructive that the glitch traverses distros, but follows Pulseaudio. I can reproduce this at will on my test setup. All that's left is the hard part :P (figuring out how to properly debug the problem).
Hey, nice to see Wadjet Eye expanding, but honestly, I think your kid is too young to start programming Mac/Linux ports. :)He may approve the code by tasting it though :P
Wadjet Eye has now got a programmer (not me) working on porting the Mac and Linux AGS engine so that we can commercially release Gemini Rue on those platforms. I know that the Linux build is in pretty good shape, but what needs doing at the moment apart from the crackly audio issues?
Next, some testers have reported performance issues. I've not spent any time profiling, as I considered the audio corruption a higher priority.I made few optimizations in "develop" branch, mostly simplifying new class hierarchies and inlining functions. They did not increase perfomance really much, but were enough to fix desynchronization between animation and sound/music during cutscenes in particular games. I think it would be possible to partially merge (or cherry-pick) that to master.
I'm curious; how will you have your programmer work on the engine, in terms of availability of sources? Will fixes and improvements be worked on in the open (for example, in coordination with CW and JJS using the public Github), or retained internally to Wadjet Eye? I'm working with other teams to do this same work (on a volunteer basis), and it would be ludicrous to run separate parallel development, though I fully understand the commercial need to not wait on volunteers :P
We want to keep everything that he (Edward) does open source so that everyone can benefit (including us!) I want to make sure what we do is compatible with the community's plans for AGS.
I made few optimizations in "develop" branch, mostly simplifying new class hierarchies and inlining functions. They did not increase perfomance really much, but were enough to fix desynchronization between animation and sound/music during cutscenes in particular games. I think it would be possible to partially merge (or cherry-pick) that to master.
(merging whole develop branch right before the release would be risky, because it has significant change in internal data structures).
How does the midi setup work in the linux version?
How do I tell AGS which alsa port to use? I run timidity which works fine in everything else but I can't seem to get any midi signals from AGS at all.
┌─[steve][archlaptop][~/games/yahtzee/5das]
└──╼ aplaymidi -l
Port Client name Port name
14:0 Midi Through Midi Through Port-0
128:0 TiMidity TiMidity port 0
128:1 TiMidity TiMidity port 1
128:2 TiMidity TiMidity port 2
128:3 TiMidity TiMidity port 3
┌─[steve][archlaptop][~/games/yahtzee/5das]
└──╼ cat acsetup.cfg
[sound]
digiid=1
midiid=0
[misc]
defaultres=1
screenres=0
letterbox=0
defaultgfxdriver=DX5
gfxdriver=DX5
windowed=1
refresh=0
gfxfilter=StdScale3
Cheeseness; thank you for the valuable input! I'm working on all of this, and will report back when I have more information.
Allegros DIGMID does not output midi (to Timidity or whatever), it uses the patches to output the audio itself. I could not get Allegro to output midi either.
I made few optimizations in "develop" branch, mostly simplifying new class hierarchies and inlining functions. They did not increase perfomance really much, but were enough to fix desynchronization between animation and sound/music during cutscenes in particular games. I think it would be possible to partially merge (or cherry-pick) that to master.
(merging whole develop branch right before the release would be risky, because it has significant change in internal data structures).
I agree with your merge strategy; would that be something you'd like me to cherry-pick and test, or would you prefer to?
I'm just getting back in to github and AGS, what branch are we working on currently?Here's the plan on branch usage: http://www.adventuregamestudio.co.uk/forums/index.php?topic=46296.msg636445912#msg636445912
Hi. Looks like you are missing the C++ standard library. Did you install build-essential as described in the Debian instructions?
Well I'm not sure exactly why you'd be getting that issue (I have successfully compiled the current repos on 32- and 64-bit Linux Mint). The very first link when Googling "linux cannot find lstdc++" is this StackOverflow question (http://stackoverflow.com/questions/2086072/linking-using-g-fails-searching-for-lstdc). Perhaps installing g++-multilib would resolve the issue for you?
Edit: I didn't even see there was another page, so I didn't see BigMc's post, but that also. :P
BigMc's post? I can only see 3 responses, none of whom are called BigMc?You quoted said post by BigMc in your reply above, I think.
Hi. Looks like you are missing the C++ standard library. Did you install build-essential as described in the Debian instructions?
BigMc's post? I can only see 3 responses, none of whom are called BigMc?You quoted said post by BigMc in your reply above, I think.Hi. Looks like you are missing the C++ standard library. Did you install build-essential as described in the Debian instructions?
Have you tried it with the Noveau drivers? I've definitely had the issue you describe in other programs (not specifically ags), that was related to a bad video driver.Thank you for your quick reply mate. Your confirmation that there were no reported problems like this got me going. I first tried the noveau driver, but it made no difference. Then I started getting exotic. Long story short; it wasn't at all related to nvidia. It was in fact a hardware problem. With my darn mouse, a Mad Catz RAT 7. The part of ags that interprets mouse movement (allegro? or is there a custom input layer?) does not receive the correct information from X. It does not correspond to actual mouse movement, which is bizarre since the mouse works perfectly in regular X and other applications.
There are no known pointer lag issues, especially on an updated distro like you have.
It was in fact a hardware problem. With my darn mouse, a Mad Catz RAT 7.Since that's the model of mouse that I use, I thought I'd pipe in and say that I've not encountered the sort of issues you've described either either of the ones I've had so far :(
Hopefully I made everything clear, in case you have any questions then I'll always be available for further testing. You can find the youtube video below.
Yeah, that was super clear, and this is really great information, TFeldt! Thanks for the video. We've had other testers intermittently report input lag as well.That's great, I'm happy it was useful. I had a look at that issue tracker and it does appear to be a likely culprit. If it's yielding for more than 1ms in a non-blocking mode then it'll create a queue build-up that keeps increasing over time. It might also be aggravated by the host's performance. For me 500hz polling was fine, so as long as it yields less than 2ms then it works fine for me. Actually had this exact problem with the unity3d engine a while back, but they eventually fixed it internally.
Looks like http://code.google.com/p/aseprite/issues/detail?id=283 to me, so maybe a known-issue with A4 at present (or at least with the way we're using it and polling inputs).
Where do we stand on a Mac build? I know the Humble Bundle guy sent us a lot of Mac code. Are we anywhere close to merging that? If we did merge it, do we have a Mac guy who could compile/test it?I don't know if anyone is working on that. I was thinking about having closer look, but could not find time yet. Also, I do not have a possibility to compile Mac code at the moment, nor I have much knowledge of OSX anyway. That said, I am afraid I won't be that much help in this case, other than checking out pull requests and making sure engine core code is not screwed by the changes.
deb and rpm packages have the advantage that they can be cleanly deinstalled later, but you still need something else in addition because not every distribution has deb or rpm.
What I like most is a tar.gz where you can decide if you want to start the game immediately after extracting or run an install script that copies the game and a .desktop file somewhere else so that you have a menu entry.
It's nice if the script is short and simple so that you can have a look at it before running it. That also helps with uninstalling.
If you look at the Humble Bundles, games often have multiple options, for example deb + rpm + something for all distributions.
Janet from Wadjeteye contacted me about releasing their games commercially on Linux. One question she asked me was about an installer. I don't have any experience with creating an installer, so I wasn't much help.
1) Do you think they need an installer? Or would a .tar.gz be enough?
2) If they do decide to do an installer, what should they use?
Maybe I'm old school, but I'd prefer a simple .tar.gz with the binaries/assets in it.
Our other option is to have detailed build instructions for lots of different platforms, and WadjetEye can just provide the game data files. BYOE style.
Our other option is to have detailed build instructions for lots of different platforms, and WadjetEye can just provide the game data files. BYOE style.
Not for a commercial game - that would be fine for freeware. People already do that by buying the PC version and compiling the Linux runtime for their platform.
Incidentally CW, I think that your threading fix actually solved the audio corruption issue we were seeing on 32-bit Linux! I spent so many weeks debugging the Linux audio server (PulseAudio) and had no idea that multithreaded audio could be problematic for the ports. Unfortunately now, a tester has reported a different audio issue on 64-bit Linux, Fedora 20 >:(What fix? I didn't do anything yet...
What fix? I didn't do anything yet...
But we too got a report about what seems to be memory corruption (possibly a deleted object accessed from other thread).
I am currently in a process of refactoring sound channels and sound clip objects in the engine code. After this is done, I will try to change the way threading works. I am afraid the way it was done originally made things more complicated.
I recommend to just disable threading in games where it causes problems, - for now. Should be:Code: Textin acsetup.cfg.
Also to note - there is no vSync on AGS games under Linux. I notice tearing during fade in and out transitions and in some animations. Though if I run the game under Wine there is no tearing at all.
Our other option is to have detailed build instructions for lots of different platforms, and WadjetEye can just provide the game data files. BYOE style.
Not for a commercial game - that would be fine for freeware. People already do that by buying the PC version and compiling the Linux runtime for their platform.
Janet, I'm working on a VM "appliance" that could be used to produce builds for the two architectures, with scripts to produce packaging (one "tar.gz" archive, one Mojosetup installer). Some hand-massaging would be necessary of course as it would be producing generic builds, and Mojosetup installers need some customization (game name & file names, images, etc). When it nears readiness, I'll share it with everyone.
There's one thing I really don't understand. Why are things done in such a complicated way? Why not use the package system?
There were experimental Editor versions with "build for linux" support:
http://www.adventuregamestudio.co.uk/forums/index.php?topic=50421.0
I have a question. I compiled my own version of AGS in Linux by make --directory=Engine. The ags engine file I obtained has very poor performance, sounds are jittered and framerate is low. I also tried Wine for Self, I could make it work flawless, so I know that it's not because my virtual machine is too low.I have the same on my Ubuntu virtual machine, but since no one real Linux user reported this, I was too lazy to investigate :tongue:.
It has worked before, so some change in the sound code must have caused this bug.I believe multiple users build AGS from the latest commits, so if this was a general issue, it would be reported already.
This is so funny.I have just tried that, it was jittering again.
I ran with "no sound" once. Then run with "autodetect" again. And it worked! :shocked: No jittering, perfect sound.
E: Next time it has jittering again :(.
Something's fishy going on here.
I just installed alex4 from the official repos. It uses allegro 4 and also has broken sound. Can you confirm that?Yes, I guess. It randomly either works or not, every time I run the game.
This is the most stupid thing I've ever seen to encode these Ids like that...The only stupid thing is to encode it as a decimal number. As a sequence of ASCII character bytes, it makes perfect sense:
They are for ALSA: 1095521089
and OSSD: 1330860868
Okay, it's just come to my attention that apparently the Linux engine isn't running standalone game data files any more. I know it was at one point, but now it simply refuses to find them. I have tested this with the game data files produced by the amended develop-3.4.0 branch, as well as the stripped EXE (hex edited everything leading up to "CLIB\x1A", which marks the start of game data) from both the new and legacy game compilers. The Windows engine reads all of these data files without issue. I also attempted to pad the raw game data file with "\x00\x00\x00\x00CLIB\x01\x02\x03\x04SIGE" (zero, as a four-byte integer, followed by the CLIB signature), but to no avail.
And, I managed to track the problem down (with only a small amount of egg on my face :-[ ). I've been referring to "ac2game.dta" (because that's what the editor calls it!) but the engine refers to "ac2game.dat".
VERSION 2.4, July 2002
Changed name of AC2GAME.DAT to AC2GAME.AGS to work with explorer better.
Was there ever any solution to the audio problem? I'm trying to submit a bug fix for The Cat Lady on Steam, and I don't recall this issue being present before... I might have to revert back to an older build if I can't find a better solution. :-\You mean the one with "jittering" sounds?
I just asked, and they say they outsourced the Linux build a couple of years ago, and that it doesn't work the same way anymore. So they are also trying to figure it out.Yes, their version is outdated, but it is possible to merge it with latest version we have. This is something I suggested them to do some time ago; I guess they just did not have enough time to try it yet.
I'll take a look at the AGS sources, but I fear this is beyond my abilities. But it can't hurt to try.
Well, their old Linux ports still seem to work. I just played The Shivah, and it doesn't have any sound issues at all.To clarify, you are using Shivah version packed by Wadjet Eye (with their own port)?
Well, I've tried running the latest Linux build from TeamCity in a virtual machine running Ubuntu, and it works pretty well albeit at a poor framerate.Except for VM being VM, Linux port does not support hardware acceleration at the moment, which means that all scaling is done by CPU.
That's because of the VM setup, of course. Has anyone had success in running AGS in a VM? Or should I really have a dedicated Linux machine?
Besides that, I experienced mouse issues on Ubuntu VM if mouse control is enabled in AGS (for mouse speed setting)Thanks. What do you mean by this? I'd expect most AGS games to be mouse controlled.
Sorry, I mean AGS directly controlling mouse position, instead of its position being read from the system and not adjusted. Since 3.3.5 AGS does that to implement cursor speed setting, but it is possible to disable by putting "control=never" string under "[mouse]" section in config. That also happens if mouse runs into screen border, and if you call Mouse.SetPosition from the script.Besides that, I experienced mouse issues on Ubuntu VM if mouse control is enabled in AGS (for mouse speed setting)Thanks. What do you mean by this? I'd expect most AGS games to be mouse controlled.
Is it correct that the Linux version ignores the windowed=1 and scaling parameters from the acsetup?No, it should read all the same parameters.
I was pretty thrilled to see that the latest version of AGS has an option to build for Linux, but I'm not sure how it works. I tried to run the output on my CentOS installation, but no joy. I'm not all that knowledgeable about Linux. What's the status of the "Build for Linux" feature in AGS 3.4.0? What are the steps involved in getting it running?As far as I know it is guaranteed to work only on certain limited Linux systems, probably those derived from Debian. I know it should work on Debian and Ubuntu. But better consult with monkey0506 or BigMC about this.
One user reports the following error/warning messages; is this something vital?
fixme:win:EnumDisplayDevicesW ((null),0,0x33f454,0x00000000), stub!
fixme:d3d:wined3d_device_decref Device released with resources still bound, acceptable but unexpected.
fixme:d3d:wined3d_device_decref Leftover resource 0x1903d8 with type WINED3D_RTYPE_SURFACE (0x1).
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
fixme:winediag:AUDDRV_GetAudioEndpoint Winepulse is not officially supported by the wine project
fixme:winediag:AUDDRV_GetAudioEndpoint For sound related feedback and support, please visit http://ubuntuforums.org/showthread.php?t=1960599
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
fixme:dsound:DSOUND_WaveFormat Limiting channels to 2 due to lack of multichannel support
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
err:ole:CoInitializeEx Attempt to change threading model of this apartment from multi-threaded to apartment threaded
fixme:win:EnumDisplayDevicesW ((null),0,0x33f864,0x00000000), stub!
fixme:d3d:resource_check_usage Unhandled usage flags 0x8.
Several users report that the game runs in fullscreen despite having windowed=1 in its config. Any thoughts on what might cause this?Writing log (or copying console messages if engine is run from console) should explain everything.
Writing log (or copying console messages if engine is run from console) should explain everything.
It sais "windowed = no" in log.
Maybe they put windowed=1 into wrong section? Name of the section has changed in 3.4.0, now display mode is set up in "[graphics]".
TBH I had a request to support old configs, which may be a good idea to add.
Aha, that explains it. I was using the config file from an earlier version, and did not know that fullscreen had to be moved (and linux doesn't have a GUI for config). Note that this is an issue for backwards compatibility: if you take an earlier-version game and open it with the 3.4 engine, it will not work as expected.Yes, that may be an annoying issue, I am not sure why but I forgot to keep support for old settings.
Wait, do the config settings digiwin, midiwin, digiindx, midiindx, digiwinindx, and midiwinindx (automatically generated in earlier versions) still do anything? What about gamecolordepth, defaultres, screenres, letterbox, defaultgfxdriver, and titletext; or the [disabled] section in the config file? If not, as of which version are they ignored? Does it harm anything if they're still present?
Also, is there something I can pass to midiid to disable midi entirely (since it causes error messages)?You can pass MIDI_NONE id. However as I found out, with Allegro it is not always obvious what's causing trouble exactly. For instance, I did not find way to get a separate error message for MIDI, because the only audio initialization function initialzes both MIDI and digitial sound at once. So only way to know which works is to call it several times with different combinations of "on/off" (which may be noticed in logs).
digiwinindx and midiwinindx are used only on Windows. They define internal index of audio in AGS.I suppose that corresponds to the pulldown in the winsetup menu. I've never seen reason to change these from their defaults.
digiid and midiid are used on all other platforms. They contain packed ID of the Allegro's audio driverSo how does a player know what the valid values are? Or should I just leave them at -1 which appears to be the default?
You can pass MIDI_NONE id.Thanks, I'll have to check that. The cause is that most Linux distros don't include MIDI libraries available in their default installation, although I suppose you could apt-get them.
No way except for looking into which ids allegro supports. These IDs are 32-bit integers, each byte equals to the code of the letter. 4-letters form a meaningful id. Having these options as integers instead of strings is absolutely not the best way, but this is how they remain since earlier versions of ags.Quotedigiid and midiid are used on all other platforms. They contain packed ID of the Allegro's audio driverSo how does a player know what the valid values are? Or should I just leave them at -1 which appears to be the default?
Turns out gfxfilter=StdScale2 also no longer works in newer AGS versions (meaning they'll ignore it if it was in an earlier config file, and pick the default instead).Of course not, as I mentioned above, all the old graphics options were replaced.
I am working on reading old options now.I thought you weren't going to work on the AGS engine anymore? ???
Playtesting reveals that under Linux, Steam achievements don't work. It may be the case that I'm using the wrong (or outdated) version of libagsteam.so and libsteam_api.so; can someone tell me where to find the correct ones please?AFAIK in previous times monkey0506 could only provide plugin stub for Linux, which essentially does nothing (only preventing AGS from bailing out with "plugin function not found" error).
A player notes that the AGS engine doesn't work well on Ubuntu Mate, reporting problems with audio playback and with a single screen being spread over two desktop windows. Does anyone have experience with this? I'm not familiar with the "mate" version of Ubuntu.Both of those two problems were reported before.
But I guess we must just admit that AGS does not support Linux. ...
Unofficially, I would say that you will get less rendering issues with the native port but you need a decent-ish CPU to cover the scaling overhead.We need to make OpenGL renderer working properly on Linux to solve this. It kinda works for other ports now, but it was never made to compile for Linux. Maybe it's not too hard to do, just someone needs to find time to look into this.
For me, sound in AGS 3.4 Linux port is distorted and really fast. (like, double speed)
Ubuntu 14.04, desktop environment doesn't seem to matter, happens in Unity and Xfce, AGS 3.3 engine is fine.
A player on Linux Mint reports that in Heroine's Quest, the music comes through has garbled and the voices are speaking too fast to comprehend. Does anyone recognize this? We don't usually test on Mint but there appears to be no reason why it shouldn't work.
Is there a way to either use AgsJoy in Linux, or at least a stub to keep a joypad-based game from crashing under Linux (because the DLL isn't there)?
EDIT: I just noticed that we already have agsjoy stubs in the engine. Now I recall that there was an opened issue about some stubs missing.
If I had a full list of functions, I could add them.
Where did you get your version, if it wasn't from that thread (http://www.adventuregamestudio.co.uk/forums/index.php?topic=41658.0)?It was from that thread, I clicked on Download v1.2.0 link.
Hey! I have a small problem on MY COMPUTER but I don't know how to solve. I built the Linux engine in Ubuntu 16.04 and if I try running a game with it, it's excruciatingly slow. So I test and run my own game using Wine. I have Steam in this computer too. I play the Wadjet Eye games and they all work well. When I tried running Until I Have You from Steam it ran as bad as my own built Linux Engine, so I guess there is something more to it. I don't have much installed on this Ubuntu computer since I mostly use it only for developing my game in Adventure Game Studio (with Wine).
Games run fine in windowed mode or when I run them fullscreen with officially packed ags from GOG
Games run fine in windowed mode or when I run them fullscreen with officially packed ags from GOG
Could you elaborate, what "officially packed ags from GOG" is?
So, you are saying that these packed by GoG run fine for you, but when you build engine yourself it runs slow? I was wondering what could be the difference.
Hey, which processor? I have similar performance issues on Until I Have Vou using KabyLake, but it works on my Sandy Bridge and Ivy Bridge laptops. Everything with Ubuntu 16.04 .
I know GOG wraps the games in WINE, which isn't something I really know much about. Which is why it's available exclusively on GOG.
... it's excruciatingly slow ...
My Linux build gives the following error,
ERROR: ld.so: object '/home/gamer/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ALSA lib rawmidi_hw.c:233:(snd_rawmidi_hw_open) open /dev/snd/midiC0D0 failed: No such file or directory
(edit) wait, that workaround is for setting MIDI to device 2 in the specific case that device 0 doesn't exist but device 2 does; but we can't just assume that everybody's going to have Timidity installed, either. Is there an Allegro config line for omitting Midi entirely?
Did you try setting "midiid = 0" in the acsetup.cfg?Ah, that should work, thakns. I'm currently using midiid = -1, which I assume means "pick the default".
Also, is this ALSA message a fatal error or just warning?I think this is a warning and the other message (about 32bit vs 64bit) is the fatal error.
(edit) Wait again, per this bug report (http://www.adventuregamestudio.co.uk/forums/index.php?issue=552.0), if you use the ACSetup tool to set MIDI to off, then AGS will play no music at all. Was this fixed at some point? Your fix in that ticket suggests the opposite (it fixes MIDIs not playing when DIGIs are disabled, but my issue is DIGI music not playing when MIDI is disabled...)
I've mentioned this before, that it is not AGS that insists on initializing MIDI anymore. There is one Allegro API function that initializes all sounds, and all AGS can do is to try it with different parameters (MIDI/DIGI, no MIDI/DIGI MIDI/ no DIGI, etc) until it returns positive answer.That's a good point, but it may be that the first function call (for MIDI+DIGI both, if I understand correctly) is causing problems in Allegro.
Yes, it could be; I think this may be tested out by disabling MIDI in setup file ("midiid = 0"), then sound init will be called with DIGI/ no MIDI at the first try. If that works, unlike other attempts, then adding a MIDI-disabling switch will have an actual meaning.
When specifying file path you may use special location tags:
$INSTALLDIR$, which allows you to explicitly read files in the game installation directory.
Any suggestions on how to help this player?
Help implementing OpenGL renderer for Linux... :(
Do you think the built in Allegro 4 OpenGL wrapper would be usable?
https://wiki.allegro.cc/index.php?title=Hardware_Accelerated_Allegro_(AllegroGL) (https://wiki.allegro.cc/index.php?title=Hardware_Accelerated_Allegro_(AllegroGL))
Why is there not a pre-built Linux build? Why do I have to compile it myself? Just curious, I will try to compile and share a package with others since there isn't a package. Cheers.
From my understanding of your reply, and lack of access to Linux right now(I will check in a few hours), there is no native build of the Editor for Linux, just an export package for the editor to build for Linux?
Anyway, this inspired me to try and get AGS' OpenGL renderer working on Linux. I don't have previous OpenGL experience but was able to crib from enough tutorials to get it working in windowed mode.
Code is at https://github.com/toojays/ags/tree/ags3+linux-opengl , see the commit message at https://github.com/toojays/ags/commit/4ae20e7317241fe3b1435ccd0652956dfca38c88 for more detail.
I've only tested it with one game (Lamplight City) on one system (Ubuntu 18.04, Intel graphics) so far. Fullscreen mode isn't working yet. Somewhere in AGS the system tries to resolve the game's 640x400 against my PC's 1920x1080 and comes up with 1728x1080 (game res * 2.7). I fail to set this as a fullscreen mode and AGS falls back to windowed mode. I guess the driver is supposed to realize the system won't do 1728x1080 and ask the windowing system for 1920x1080? Does anyone know?
Hello, toojays. It's really nice to see someone tried doing this. I kept hoping to look into this myself but never found a moment to research the OpenGL working on Linux (also, there was ongoing Nick Sonneveld's SDL port attempt, but it seems to get delayed again).
Can't answer to the fullscreen problem right away, this is something to investigate. I may mention one thing though (and also the main reason that was stopping me). Since OpenGL does not support "dedicated fullscreen mode" on Windows I had to emulate fullscreen mode (probably this is how everyone do this) by switching desktop resolution. This is not done in ali3dogl.cpp itself, but in the "platform driver" class. You may find calls to "platform->EnterFullscreenMode", "platform->AdjustWindowStyleForFullscreen" and "platform->ExitFullscreenMode" in OpenGL renderer. The implementation for Windows is located in acplwin.cpp. But I honestly do not know if we should follow same procedure for Linux or not (also don't know X11 very well, I wrote literally couple of functions using it before).
Am I right that you are using "glew" library, that helps to bind function pointers to dynamically loaded OpenGL object? OpenGL renderer was originally written in such a way that on Windows we manually getting function addresses, and that would be actually a nice thing to get glew used on Windows eventually too (not sure why I never tried, maybe was worried to break something that was already working).
I have a proposal, since this forum thread is too long already and contains all kinds of various discussions, could we continue on github instead, by opening an issue ticket in our repository? I believe that would be more convenient especially since you already have account and some code in progress there.
Hey! I have a small problem on MY COMPUTER but I don't know how to solve. I built the Linux engine in Ubuntu 16.04 and if I try running a game with it, it's excruciatingly slow. So I test and run my own game using Wine. I have Steam in this computer too. I play the Wadjet Eye games and they all work well. When I tried running Until I Have You from Steam it ran as bad as my own built Linux Engine, so I guess there is something more to it. I don't have much installed on this Ubuntu computer since I mostly use it only for developing my game in Adventure Game Studio (with Wine).
Linux port has only software renderer available at the moment, which runs slow, especially if game scales to larger display resolution. That would be my first guess. On Wine you have Direct3D and OpenGL (if you are using AGS 3.4.1).
The solution would be to make OpenGL renderer work on Linux, which may be trivial, except someone needs to make such change (this also requires a knowledge of what headers/libraries to add to the engine).
A player reports that AGS games run unreasonably slow under lubuntu 16.04.6 lts, using a gfx hd6670 graphics card. Does this sound familiar to anyone and if so, what could be done about it?
Linking engine...
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libdumb.a(itrender.o): in function `it_filter':
(.text+0x11f9): undefined reference to `__pow_finite'
/usr/bin/ld: (.text+0x123a): undefined reference to `__exp_finite'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libdumb.a(itrender.o): in function `update_effects':
(.text+0x404b): undefined reference to `__pow_finite'
/usr/bin/ld: (.text+0x4079): undefined reference to `__pow_finite'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libdumb.a(itrender.o): in function `process_tick':
(.text+0x429c): undefined reference to `__pow_finite'
/usr/bin/ld: (.text+0x42e0): undefined reference to `__pow_finite'
/usr/bin/ld: (.text+0x4386): undefined reference to `__pow_finite'
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libdumb.a(itrender.o):(.text+0x4c34): more undefined references to `__pow_finite' follow
/usr/bin/ld: /usr/lib/gcc/x86_64-linux-gnu/9/../../../x86_64-linux-gnu/libdumb.a(readmod.o): in function `dumb_read_mod_quick':
(.text+0x8d1): undefined reference to `__log_finite'
collect2: error: ld returned 1 exit status
make: *** [Makefile:40: ags] Error 1
Please send help.
make USE_BUILT_IN_LIBSRC=1