[OLD-1] AGS engine Linux port

Started by BigMc, Sun 03/06/2012 19:04:20

Previous topic - Next topic

Sslaxx

No Pulseaudio restart was needed here. Seems to be working better with the latest Git changes to the engine code.
Stuart "Sslaxx" Moore.

Crimson Wizard

Quote from: Sslaxx on Tue 05/02/2013 12:38:30
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?

Sslaxx

Quote from: Crimson Wizard on Tue 05/02/2013 12:53:33
Quote from: Sslaxx on Tue 05/02/2013 12:38:30
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.
Stuart "Sslaxx" Moore.

BigMc

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.

Sslaxx

Quote from: BigMc on Tue 05/02/2013 12:59:47
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?
Stuart "Sslaxx" Moore.

BigMc

Maybe AGS uses external code incorrectly. Does not shut it down properly or so. But the bug could still also be in AGS.

Crimson Wizard

Quote from: BigMc on Tue 05/02/2013 13:18:07
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.

scottchiefbaker

Quote from: Crimson Wizard on Tue 05/02/2013 11:37:04
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?

scottchiefbaker

Quote from: BigMc on Tue 05/02/2013 08:25:49
Here, autoscaling is disabled, because gfxfilter=StdScale2 is set in acsetup.conf. Also, is ags_shell.dll a Windows plugin?

Good catch I'll remove the .dll. The acsetup.cfg is direct from the Windows version. Since 90% of those options are ignored on the Linux version what SHOULD the config look like? I'm thinking ALL we need is:

[misc]
gamecolordepth=16
titletext=Gemini Rue Setup
windowed=0

Do we need any of the sound settings on Linux?

BigMc

Quote from: scottchiefbaker on Tue 05/02/2013 16:09:21
Quote from: Crimson Wizard on Tue 05/02/2013 11:37:04
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?

I guess you could start the beta test without it.

scottchiefbaker

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.

s_d

I strongly suggest advancing the build number, in some way, prior to the beta.

BigMc

Quote from: scottchiefbaker on Tue 05/02/2013 17:14:09
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.

You did not create a pull request for that. (BTW, I don't consider myself responsible for merging pull requests.)

s_d

Quote from: Sslaxx on Tue 05/02/2013 12:38:30
No Pulseaudio restart was needed here. Seems to be working better with the latest Git changes to the engine code.

Well, yes, it's an intermittent bug, but I seriously doubt it was fixed by those changes (they were nowhere near that behavior, as best I can tell).  What I assumed was my own setup, on one machine, is actually the bug.  I've observed it in earlier revisions as well.

It is possible that it is a race-condition, and the latest changes perturbed it so that they don't show up on your hardware, but it's unlikely that it's fixed.  Just masked.

I was hoping to find a workaround since it's difficult to reproduce.  When the OS, or audio subsystem, are in that state, where you would be convinced that a reboot is necessary, then that is the time to try to restart pulse.  I've confirmed (now that I'm at my office) that restarting pulse on that workstation immediately fixes it, as well.

scottchiefbaker

Quote from: s_d on Tue 05/02/2013 17:20:54
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.

s_d

Quote from: scottchiefbaker on Tue 05/02/2013 17:33:00
I think games rely on the version number. I think the easier thing to do, is just version the Linux version separately.

OK, in that case, we should at least include the Git revision hash and MD5 of the binary in a readme or something similar.  It's critical that beta testers can know for sure what they're running.

s_d

Quote from: BigMc on Tue 05/02/2013 17:30:10
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?

Crimson Wizard

#237
Quote from: s_d on Tue 05/02/2013 17:39:53
Quote from: BigMc on Tue 05/02/2013 17:30:10
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?
He did create a pull request: https://github.com/adventuregamestudio/ags/pull/53
It's just named afer last commit, which is unrelated to BUILD_STR.
I can merge requests, but I think JJS knows makefiles (and linux in general) better.

But, regarding the version. What is exactly a problem here? We need a 1) "base" version of the engine, which determines its features and overall behavior, and since AGS is now being released in open-source format, being built on daily basis 2) a build information, that will not be a decisive factor to determine game-to-engine compatibility.

My suggestion is:
1) increase major version once for now to reflect the huge changes made to the code. This will render all savegames made by new engine "conventionally" incompatible with original games, but as soon as savegame conversion utility is made, that won't be a much of a problem (it will need to replace version string inside savegame, because the format is still totally compatible to AGS 3.2.*; oh, and plugin stuff, but thats other story). Besides, no other platforms can run original Windows games anyway.
2) use any sane method to put purely informative build string into application. scottchiefbaker's suggestion seem to do this, although his code will only work for printing version info at console, and not in game (the Ctrl+V method). But that may work for starters.

s_d

Quote from: Crimson Wizard on Tue 05/02/2013 17:52:17
Quote from: s_d on Tue 05/02/2013 17:39:53
Quote from: BigMc on Tue 05/02/2013 17:30:10
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?
I can merge requests, but I think JJS knows makefiles (and linux in general) better.

Ok, thanks!  I was just curious about that.

Quote from: Crimson Wizard on Tue 05/02/2013 17:52:17
But, regarding the version. What is exactly a problem here?

In my mind it's primarily an issue for tracking bugs filed during beta testing (in general).  It would be better for games not to pay attention to the micro-version/build-number (e.g., bug fixes), but only look at "major.minor", going forward.  Anything beyond that is not really important right now for beta testing.

scottchiefbaker

For doing one off testing, it would be VERY useful to include a BUILD_STR that's only present at the commandline (I don't see why it would be needed in game) to indicate the difference between two builds that are the same version numbers.

Sort of like how the kernel has an -AC branch and a -linus etc. Even though they're working on the same core version.

SMF spam blocked by CleanTalk