[OLD-1] AGS engine Linux port

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

Previous topic - Next topic

s_d

Quote from: scottchiefbaker on Sat 16/02/2013 00:09:06
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.  :)

s_d

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:

Code: AGS
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)
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  150 (XFree86-VidModeExtension)
  Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
  Value in failed request:  0x4e00003
  Serial number of failed request:  87
  Current serial number in output stream:  92


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.

Sslaxx

Quote from: s_d on Sat 16/02/2013 08:21:55
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:

Code: AGS
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)
X Error of failed request:  BadValue (integer parameter out of range for operation)
  Major opcode of failed request:  150 (XFree86-VidModeExtension)
  Minor opcode of failed request:  10 (XF86VidModeSwitchToMode)
  Value in failed request:  0x4e00003
  Serial number of failed request:  87
  Current serial number in output stream:  92


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.
Do you know what scaling was used?
Stuart "Sslaxx" Moore.

BigMc

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.

Crimson Wizard

#344
Quote from: s_d on Sat 16/02/2013 08:15:21
Quote from: scottchiefbaker on Sat 16/02/2013 00:09:06
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.  :)

JJS seem to be absent for few days, so I'll do that.

EDIT: I fixed the explanation below, because what I wrote first was very unsafe thing to do.

For the future: I suggest doing fixes in separate branch, like "master-fixes". In such case, if something goes wrong, you may create new branch and copy only partial changes there (using "Cherry-pick commit" git function), and delete the original.
If changes are already in 'master', you can always make a revert, which is basically a commit that totally negates the changes by any previous commit.

Also, if you were working locally, and your local branch became a bit "dirty", you may then do this trick:
* create temporary local branch and copy the correct changes there by using "Cherry-pick commit" Git function. Or by manual copying. in extreme cases.
* hard-reset your working branch back to the last proper commit.
* apply changes back from the temporary branch.
* delete temporary branch.

I think it is unsafe to do this will remote branch though.

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.
You may reference as many remote origins to your repository as you want, so they will be "visible", and you can merge them to your personal branches. It should be
Code: terminal
git remote add <something>
, well, check the help. I used this several times.



UPD: Increased version number to 3.30.

s_d

Quote from: BigMc on Sat 16/02/2013 11:49:51
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).

s_d

Quote from: Crimson Wizard on Sat 16/02/2013 14:10:44
JJS seem to be absent for few days, so I'll do that.

Thanks from Scott (by proxy)  :)

Quote from: Crimson Wizard on Sat 16/02/2013 14:10:44
For the future: I suggest doing fixes in separate branch, like "master-fixes".

Aye, aye, Captain Wizard.  However you want it done ;-D

I've worked with half a dozen different SCM branch/merge models in the past decade, each with advantages and disadvantages, and there is very little I feel strongly about, provided a few things are in place.  One (as of recently) is distributed version control, which we have here with Git, and another is some kind of "gatekeeping" or curation on the official repository (which we have with a small group of JJS, you, BigMC, etc).  It would be nice to have continuous integration and nightly builds on all ports, but that requires infrastructure which requires money and volunteerism.  That one is great for regression testing, as well as pointing fingers when someone breaks the build on one of the ports, and helps make bisecting the offending changeset more simple.  Anyway, this was a cosmetic change authored by someone else, so I'm kind of digressing now  :P

Quote from: Crimson Wizard on Sat 16/02/2013 14:10:44
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.

Since I was unsure of the procedure I simply cloned the repo freshly, expressly for the purpose of this changeset, applied the patch, committed it to my github clone, and then issue the pull request directly from github.  Unless I was in the unlikely situation that someone was merging into the mainline at the same time, then would not my pull request be guaranteed valid?  At any rate, am I to understand that this is *not* what you want?

Yes, I'm certainly aware that such a workflow is unnecessarily tedious for any real work on the AGS interpreter, but I've yet to accomplish any  ;)

Right now, I'm trying to discover the auto-scaling bug which is causing Quest for Infamy to crash on resolution change for a person in the Infamous Quests community.  He's able to play the demo by going to windowed mode instead, but I'd like to resolve any problems with auto-scaling that I can find.  That feature is very nice on Linux, and it is good that it is the default.  Just need to squash all the bugs...

s_d

Quote from: BigMc on Sat 16/02/2013 11:49:51
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.

Oh, also, another bug reporter claimed that the HqNx filters bug out really badly on full-screen.  I've confirmed that bug (he's on an AMD card using the open-source radeon driver running 64-bit Slackware 14, and I'm on an Intel integrated adapter on Ubuntu 12.04).  In this particular case (Quest for Infamy), they're not advising use of (or expecting to support) the smoothing filters at all, so it's not critical for this game.  It is, however, a bug.  The only things in common between his setup and mine are the game under test, and the fact that both of us are running in a 64-bit environment.  The bug does not trigger on a 32-bit Linux VM.

Here are screenshots of what I mean by "bugging out":

Spoiler
[close]
Spoiler
[close]

Please forgive me if this is a known issue.

BigMc

Quote from: s_d on Sun 17/02/2013 05:50:17
Quote from: BigMc on Sat 16/02/2013 11:49:51
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.

The bug has nothing to do with auto-scaling, which is just selecting a filter automatically.

Crimson Wizard

Quote from: BigMc on Sun 17/02/2013 10:25:16
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.

BigMc

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.

scottchiefbaker

Now that we have a 3.30, can I get a build of ags+binaries using that? Has anyone be able to setup a simple build system that could give us nightlies? I'm not an expert with Debian buildroots or I'd attempt it myself.

BigMc

http://people.debian.org/~thansen/ags+libraries_20130218.tar.xz

It's no problem for me to update this if someone asks, but I don't have a good way to provide daily builds.

scottchiefbaker

Quote from: BigMc on Mon 18/02/2013 21:42:31
It's no problem for me to update this if someone asks, but I don't have a good way to provide daily builds.

Ok... as long as it's not a big hassle for you to build every so often, as features land. Using this build, which has the snowrain stub functions corrected, any reason to not use this for a Gemini Rue build? Anything else outstanding? I think the autoscale is in a pretty good place now right?

scottchiefbaker

On a side note... is it at all possible to add something like ctrl + enter to toggle between fullscreen and windowed?

BigMc

Autoscale is fine, but changing to unsupported resoltions and crashing is still there. It depends on the combination of screen resolution and filter used.

Quote from: scottchiefbaker on Mon 18/02/2013 21:54:52
On a side note... is it at all possible to add something like ctrl + enter to toggle between fullscreen and windowed?

Don't know.

scottchiefbaker

Quote from: BigMc on Mon 18/02/2013 21:59:16
Autoscale is fine, but changing to unsupported resoltions and crashing is still there. It depends on the combination of screen resolution and filter used.

Are we still switching resolutions, or does it leave the resolution alone, and just pick the appropriate scale factor? I'm confused.

BigMc

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.

scottchiefbaker

Quote from: BigMc on Mon 18/02/2013 22:58:17
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.

For the reasons you mentioned, we probably do NOT want it to switch resolutions when using auto scale? We should probably ONLY change the resolution when the user picks both fullscreen and a specific scale value?

Crimson Wizard

Quote from: scottchiefbaker on Mon 18/02/2013 21:54:52
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.

Quote from: scottchiefbaker on Mon 18/02/2013 21:54:52
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.

SMF spam blocked by CleanTalk