[OLD-1] AGS engine Linux port

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

Previous topic - Next topic

BigMc

I suggest the scaling should stay as it is. Autoscaling only if no scaling is explicitly selected.

s_d

Ok, so how about this.  I'll hardcode my modelist returned to NULL, and work on it until native game resolution is working (both with QFI at 320x240@32bpp which I'm trying to support for IQ, and Gemini Rue at 320x200@16bpp for Wadjet Eye's beta) no scaling at all, on my test machines in fullscreen mode.  Then, I will try get it working with autoscaling (to support the mode you built for no gfxfilter supplied).  Hopefully I won't make the code too ugly  :)

s_d

Home from work now!  I've got _gfxModeList hardcoded to null, IsModeSupported() returning false, and am working on making it work anyway.  It is quitting out as expected, so I'm all set.  Wish me luck!  :)

scottchiefbaker

Everyone still alive? Been awfully quiet around here lately.

Crimson Wizard

Quote from: scottchiefbaker on Wed 06/03/2013 16:44:03
Everyone still alive? Been awfully quiet around here lately.
And what we were supposed to do here? :)
s_d is working on resolution problem.
I am making an experimental build with Allegro 5 (not related to Linux).
Are there any news from Gemini Rue beta-testing?

s_d

As CW says, I'm still working on the resolution switch problem.  The two major issues reported at QFI were crashes due to resolution or missing audio configuration.  I have a PM out to Pumaman about the nice setup utility from 2.X;  Electroshokker is totally on-board with sharing code, but needs his approval first (Pumaman hasn't visited here in a couple months though).  I can add to the GUI some automatic ALSA/DIGIMID index detection.  Could redo from scratch, but I really dislike GUI programming, and would much rather hack/refactor someone else's working GUI.

Full-screen resolution launch crash will be mostly covered by the Allegro driver switch, but BigMC has some confidence that we need to have a fall-back mode when no modes are detected.  I strongly respect his opinion, and am pursuing that with all my attention.  When I finish, then it's on to the setup util (hopefully CJ says yes).

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).

What do you guys think?  If yes, then I'll prepare a pull request so you can pull the trigger on 3.30.

For the other part of the work, I will continue with my refactor, but maybe it will be better for me to co-ordinate that with your Allegro abstraction work, CW?  I don't want to get in your way though.

BigMc

Quote from: s_d on Wed 06/03/2013 17:46:13
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.

s_d

#407
Quote from: BigMc on Wed 06/03/2013 21:06:33
I'm fine with that.

Ok, great.  I'm at work now, but when I'm home, I will try to use a fix-branch as CW requested, and you/he/JJS could cherry-pick the revision.  I want to work with you guys the way that helps you the most  :)

Quote from: BigMc on Wed 06/03/2013 21:06:33
The only other driver is GFX_XDGA2 and that requires root permissions, so it isn't an option anyway.

Well, yes root is bad, but compared to one major trouble you've highlighted, specifically unreliable mode switching back to the original mode, I'm quite certain that the failure mode using DGA is much worse.  Rather than leaving you in an unpleasantly tiny mode, you're scribbling directly onto internal X frame-buffer memory*, so the failure mode is trashing the X client, not just leaving the desktop in a bad state.  Much better that the grumpy player can log out and then back to get back to normal, than having X windows locked up (or worse, the kernel) :(

This way, at least, if the player's setup has mode detection and switching features, they will be reliable and properly handled.

EDIT:  *Oops, by "internal frame-buffer", I mean, "directly on video card memory".  Same outcome, though.

s_d

CW, at long last, I've finally figured out how to clean up the fine hash I'd made of my master branch.  I think I have a functional branch & fix strategy (thanks for the advice back in mid-February, that is all working well now, I think).

All this for a three line patch on my new "linux-fixes" branch: https://github.com/s--d/ags/commit/a92b4b040ae449ef46e2c8886ff4cc30dfcb76cc

That should get mode list probing and mode switching errors to be handled properly.  Again, I'm terribly sorry for making everyone wait, but now I think I'm set up to work with you guys more cleanly.  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?

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.

Crimson Wizard

Well, we were not in a big hurry, anyway, I think.
Any comments from other linux users on this patch?
I am still interested to hear about Gemini Rue status. Did they finish the beta test?


Quote from: s_d on Sat 09/03/2013 23:17:32
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".
Well, I made a note about branches here: http://www.adventuregamestudio.co.uk/forums/index.php?topic=46296.msg636445912#msg636445912

Quote from: s_d on Sat 09/03/2013 23:17:32
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:" :)

JJS

Quote from: Crimson Wizard on Sun 10/03/2013 14:26:24Any 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.
Ask me about AGS on PSP, Android and iOS! Source, Daily builds

Sslaxx

Quote from: JJS on Sun 10/03/2013 15:25:05
Quote from: Crimson Wizard on Sun 10/03/2013 14:26:24Any 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.
Stuart "Sslaxx" Moore.

s_d

Quote from: Crimson Wizard on Sun 10/03/2013 14:26:24
I am still interested to hear about Gemini Rue status. Did they finish the beta test?

My post with the test version of my patch is the last one, and received no PMs there.  I think (unfortunately for me) the Linux users are happy with the latest build enough that they're off thoroughly playing through Gemini Rue.  (laugh)  There are a couple of folks with outstanding issues, nearly all of which are related to the known PulseAudio corruption issue.  It is reportedly exacerbated by switching focus out of the game in windowed mode. That one has become "real" enough that I'm convinced to file an issue in our tracker (I've made video clips to illustrate the problem and such).  I can probably reproduce it, but it's going to be another research project to figure out how to actually root-cause the problem (from personal experience, I have a suspicion that the browser Flash plugin/player is guilty of same sin as well).  PulseAudio has some debugging features I can try out (and of course, sources are opened so I can lose my brain in that code also).

The way Wadjet Eye's beta 2 is distributed, the acsetup.cfg has a commented-out line setting gfxfilter to StdScale4, and instructions to uncomment it if the game crashes out.  I think the next build we give scottchiefbaker will solve the fullscreen problem for beta participants, but they apparently won't test it until Janet announces it, so I hope they will do another round of beta with my fix.

Quote from: Crimson Wizard on Sun 10/03/2013 14:26:24
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:" :)

I like habits & conventions better than hard-and-fast rules.  That said, I want to work with you folks in whatever way is most convenient (including diving into an ugly spaghetti mess that nobody else wants to touch  ;) ).  I like his convention, and will try to use it in the future.

s_d

Quote from: JJS on Sun 10/03/2013 15:25:05
Quote from: Crimson Wizard on Sun 10/03/2013 14:26:24Any 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.

Wow, thanks!  It's incredible to me how much time and research it took to wrap my head around, and properly test, what amounted to a four-line patch.  But now, I have a 32-bit build chroot and test VM to do basic validation, so I should be able to accomplish further improvements.

Quote from: JJS on Sun 10/03/2013 15:25:05
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.
Quote from: Sslaxx on Sun 10/03/2013 16:03:54
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 see what you guys are saying here.  I should have thought of that.

I disagree that nobody does this, however.  For example, on embedded Linux gaming devices (Pandora, GP2X, GCW Zero) they do not use X11.  Now, granted, while the install base on those devices is very small, it could be argued that AGS games are a tiny niche of the larger gaming world, so I'd prefer not to simply "compile out" these folks.  Testing will become a burden eventually, but it is possible that a member of this community will step up, and maybe learn from JJS's work on PSP to design a proper gamepad-like control scheme for those platforms.

Plumbing an option through to the Makefile would be trivial.  I'll do that patch and send a pull request, which you could (of course) reject if you wish.

Crimson Wizard

Uhhhh... I don't get anything what people say here about XWindows, framebuffers and stuff. Was that sarcasm? You guys gotta be careful... I thought you agree with patch, so I merged the pull request. Did I do right or wrong?  (wtf)

s_d

It's all good buddy  :)

They are happy, and the patch is good.

I've another patch just about ready to send, which will permit a compile-time option to restore the original behavior.  Basically, my first patch is great for desktop Linux users, but potentially not so nice for a (tiny) group of embedded Linux gamers, folks on old Linux distributions, or power users who hack the crap out of their install.  My second patch will allow the user to pass "ALLEGRO_MAGIC_DRV=1" to Make, and it will produce a version created the old way.  The level of support we provide for that feature, however, will depend on a dedicated community member.  It's ability to function may bitrot, otherwise.  We're basically all OK with this.

Crimson Wizard

Quote from: s_d on Mon 11/03/2013 00:33:49
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?

s_d

No, I don't think that's a good idea.  I could do it, but if you peek at that area of graphics_mode.cpp, (engine_init_graphics_mode()->switch_to_graphics_mode()->init_gfx_mode()), I think you'll agree that it is hard to see how adding another loop around that whole initialization dance is going to make the code any better  :(

It already looks pretty fragile there, and there are a couple of gfxDriver related inits that occur before it.  The compile-time define is a pretty clean way to prevent things getting worse, I think.  The whole mode-selection strategy needs a serious refactor... what I've begun to do is to diagram a generic state machine to accomplish the goal that the current algorithm does.

So, that mode-selection strategy is either A) totally the wrong way to do it, or B) way simpler in intention than the code that implements it today.  Or, worst case, it is the way it is because it works around unusual corner-cases in a port I cannot test (such as Windows).  That possibility is what scares me the most about refactoring  :(

One central problem with that is that it's hard to know whether or not the X driver failed, except to exhaust the mode list returned by the driver.  I don't know for sure what way the Allegro X driver errors out when no X11 server is present.  Even then, the whole idea of preserving a way to use non-X11 mode (basically VGA mode 13h) is pretty much to service a whole different set of people.  I think the way it is now, with the first patch, is the right way going forward for all Linux desktops.  The alternate mode, which someone could choose to build using the compile-time directive, builds an interpreter for a different group of folks.  Those people, in general, are not running games on a desktop or laptop, but on an embedded Linux device (also, they may have to port the main Linux build to ARM).

So, doing the above described double initialization hack (try X and then try auto) significantly increases the complexity of an already buggy section, just to provide functionality to a small group who probably do not want it probing for X windows anyway (since their embedded device is almost certainly a low-power, possibly underclocked, mobile CPU).  :)

s_d

Man, I really hope we can get in touch with Pumaman... I just noticed that Electroshokker's Linux ags-setup already does auto-detect for audio, which is precisely the feature I was most interested in implementing!

http://www.adventuregamestudio.co.uk/forums/index.php?topic=37968.msg501047#msg501047

Does anyone have a postal address for him?  At this rate, I could have posted a letter to him by now... (laugh)

AGA

CJ says it's okay.  If Electroshokker is reading this, CJ is fine with you releasing this.

SMF spam blocked by CleanTalk