[OLD-1] AGS engine Linux port

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

Previous topic - Next topic

Sslaxx

Quote from: Crimson Wizard on Mon 18/02/2013 23:03:53
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.
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.
Stuart "Sslaxx" Moore.

BigMc

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.

scottchiefbaker

Quote from: BigMc on Mon 18/02/2013 23:20:13
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.

That seems like the ideal solution. Probably something we should shoot at for the next version?

s_d

Quote from: BigMc on Sun 17/02/2013 19:26:20
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.

I think that filtering for the closest supported resolution would be the quickest fix to avoid a crash bug (which is my worst reported Linux issue).  It does nothing, as BigMC astutely notes, to solve the problem of reliably restoring the original resolution, but perhaps it is worth me trying to fix now, rather than waiting what could be weeks or months to rewrite or port a bunch of backend code in.  It appears that the OGLGraphicsDriver::IsModeSupported() and OGLGraphicsDriver::FindSupportedResolutionWidth() functions aren't actually trying to query or filter anything (IsModeSupported returns true, and FindSupportedResolutionWidth returns whatever you pass in, for example).  Is that how they are built?

Also, is Linux using OGLGraphicsDriver or ALSoftwareGraphicsDriver?

At any rate, without a way to actually test an odd resolution from my home (right now) it will be tough to validate, but I'll try to run it by our bug reporters.

Quote from: BigMc on Mon 18/02/2013 23:20:13
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.

We have had reports of performance issue.  Perhaps it is related to this.  Interestingly, the reporter stated that when using the HqNx filters, the performance improved, which was surprising to me since I assumed that they do more work.  I'm not terribly familiar with that section of the code, but

Crimson Wizard

Linux is using ALSoftwareGraphicsDriver.
Portable devices are using ALSoftware and OpenGL drivers.
Windows allows all three, although it does not allow to set OpenGL it in config (there's an automatic selection algorythm which I do not know well).

Spoiler

Code: cpp

void create_gfx_driver() 
{
#ifdef WINDOWS_VERSION
    if (stricmp(usetup.gfxDriverID, "D3D9") == 0)
        gfxDriver = GetD3DGraphicsDriver(filter);
    else
#endif
    {
#if defined(IOS_VERSION) || defined(ANDROID_VERSION) || defined(WINDOWS_VERSION)
        if ((psp_gfx_renderer > 0) && (game.color_depth != 1))
            gfxDriver = GetOGLGraphicsDriver(filter);
        else
#endif
            gfxDriver = GetSoftwareGraphicsDriver(filter);
    }

    gfxDriver->SetCallbackOnInit(GfxDriverOnInitCallback);
    gfxDriver->SetTintMethod(TintReColourise);
}

[close]

scottchiefbaker

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

Crimson Wizard

Quote from: scottchiefbaker on Tue 19/02/2013 00:48:39
Quote from: s_d on Sat 16/02/2013 08:21:55
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?
This information should be printed in console (at Linux), and also in "agsgame.log".
The former is true for the latest build, there was a commit which updated debug output several days ago. But cvonsole output should have worked before, I think.

s_d

Quote from: scottchiefbaker on Tue 19/02/2013 00:48:39
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?

Produced on the console, even from a stripped release build.

s_d

Quote from: Crimson Wizard on Tue 19/02/2013 00:44:00
Linux is using ALSoftwareGraphicsDriver.

Thanks CW!

Ok, interesting.  Either something fishy is going on, or the Allegro get_gfx_mode_list() function isn't working.  ALSoftwareGraphicsDriver::IsModeSupported() seems to be implemented and being used in ALSoftwareGraphicsDriver::Init().

Spoiler

Code: CPP

bool ALSoftwareGraphicsDriver::IsModeSupported(int driver, int width, int height, int colDepth)
{
#if defined(ANDROID_VERSION) || defined(PSP_VERSION) || defined(IOS_VERSION)
  // Everything is drawn to a virtual screen, so all resolutions are supported.
  return true;
#endif
  
  if (_windowed)                                                                    
  {
    return true;            
  }
  if (_gfxModeList == NULL)
  { 
    _gfxModeList = get_gfx_mode_list(driver);
  }
  if (_gfxModeList != NULL)    
  { 
    // if a list is available, check if the mode exists. This prevents the screen flicking
    // between loads of unsupported resolutions
    for (int i = 0; i < _gfxModeList->num_modes; i++)
    {
      if ((_gfxModeList->mode[i].width == width) &&                                            
        (_gfxModeList->mode[i].height == height) &&
        (_gfxModeList->mode[i].bpp == colDepth))         
      {
        return true;
      } 
    } 
    strcpy(allegro_error, "This graphics mode is not supported");
    return false;       
  } 
  return true;
}   

[close]

...and then...
Spoiler

Code: CPP

bool ALSoftwareGraphicsDriver::Init(int width, int height, int colourDepth, bool windowed, volatile int *loopTimer)
{
  _screenWidth = width;
  _screenHeight = height;
  _colorDepth = colourDepth;
  _windowed = windowed;
  _loopTimer = loopTimer;
  int driver = GetAllegroGfxDriverID(windowed);

  set_color_depth(colourDepth);
  int actualInitWid = width, actualInitHit = height;
  _filter->GetRealResolution(&actualInitWid, &actualInitHit);

  if (_initGfxCallback != NULL)
    _initGfxCallback(NULL);

  if ((IsModeSupported(driver, actualInitWid, actualInitHit, colourDepth)) &&
      (set_gfx_mode(driver, actualInitWid, actualInitHit, 0, 0) == 0)) 
  {
    // [IKM] 2012-09-07
    // set_gfx_mode is an allegro function that creates screen bitmap;
    // following code assumes the screen is already created, therefore we should
    // ensure global bitmap wraps over existing allegro screen bitmap.

[close]

I see a bit of you in there, CW  :-D

Why would not strange resolutions be rejected?

scottchiefbaker

Quote from: s_d on Tue 19/02/2013 01:41:31
Produced on the console, even from a stripped release build.

Oh duh... I wasn't seeing the switch messages because I was running -windowed.

s_d

Yeah, it's important to test in full-screen mode sometimes, too.  In fact, the only bugs reported on QFI so far have been 1) ALSA not set up properly in acsetup.cfg 2) full-screen crash or image corruption.

BigMc

s_d, most of the iffy stuff goes on in graphics_mode.cpp.

scottchiefbaker

Quote from: s_d on Tue 19/02/2013 06:47:39
1) ALSA not set up properly in acsetup.cfg

Can you elaborate?

s_d

Quote from: BigMc on Tue 19/02/2013 09:11:14
s_d, most of the iffy stuff goes on in graphics_mode.cpp.

Ok, thanks.  I'll look in there and see how sad it makes me  ;)

s_d

Quote from: scottchiefbaker on Tue 19/02/2013 13:48:18
Quote from: s_d on Tue 19/02/2013 06:47:39
1) ALSA not set up properly in acsetup.cfg

Can you elaborate?

Certainly.

A tester on 64-bit Slackware 14 reported:

Quote
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]

... and also ...

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

One of IQ's gameplay engineers (chucklas, FYI) immediately recognized the source of the problem:

Quote
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 tester checked out his MIDI setup (something, by the way, that our GUI acsetup configurator will be easily able to probe), and properly configured DIGIMID:

Quote
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

[misc]
gamecolordepth=16
titletext=Quest for Infamy Demo 2.0
windowed=1
gfxfilter=Hq2x
[sound]
digiid=1
midiid=0


Is there anywhere i can find valid options for acsetup.cfg and explanations of them?

With properly probed & set up audio configuration prior to game launch, most folks on ALSA without Pulse will be well-served, as those running Pulse now already are.  There is always the chance of really lacking MIDI support, in which case it would be good for the engine to simply not crash (and not play any audio), but I would consider that task to be very low priority.

Crimson Wizard

#375
Quote from: scottchiefbaker on Mon 18/02/2013 21:54:25Using this build, which has the snowrain stub functions corrected, any reason to not use this for a Gemini Rue build? Anything else outstanding?

Ah. We need to add CHANGES.TXT. Chris Jones had one, but it was not included to the SVN, as it seems. We may take latest from the 3.2 release package.


MUCH LATER EDIT:
Also, our Copyright.txt sais "Copyright (C) 1999-2012"

BigMc

These things are more relevant for an AGS release. Or do you think about doing a beta AGS release?

scottchiefbaker

Quote from: BigMc on Fri 22/02/2013 18:09:48
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.

BigMc

Getting rid of compiler warnings doesn't necessarily fix real bugs. When you keep talking about this it sounds like there are no more important things to do.

Crimson Wizard

#379
Quote from: scottchiefbaker on Fri 22/02/2013 18:12:37
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.
I don't mean they should not be fixed, but, on other hand, they don't prevent a release.

Quote from: BigMc on Fri 22/02/2013 18:09:48
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.

SMF spam blocked by CleanTalk