Messages

Once it is clear what exactly AGS 3.30 is, we can provide a source archive for the users. Also an ags+libraries archive which is intended for game distributors. I find it confusing that you call the version 3.30.0 in git, 3.3.0 in this thread and 330 in the file name of the Windows package.

What the play store then does when you goto download and install an app is Download the main app and then the rest of the expansion files automatically. Yes, seems kind of dumb. Why not just allow for one big file in the first place???

Because the apk has to be updated for each and every small change. If you need hundreds of megabytes for an app for a mobile device, you better make sure the large data files only need to be downloaded once.

What is its status? Why was it discontinued?

I guess it's much less polished than the the 3.3 engine.

Also, he mentions a reasonable argument about using SDL instead of Allegro 5. May anyone on comment that?

He just said Allegro 5 is lacking pixel drawing and palette manipulation features. Is pixel drawing really a problem? Do you think SDL provides everything, so that it would require less code to be moved to AGS itself?

berolinux is Bernhard Rosenkraenzer.

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.

It's probably not required, but strictly speaking the offset information at the end of the data (JJS mentions it) should also be updated to 0. Would be nice to have a small tool to do the cut.

The engine does not require an exe, data file also works. JJS explains here where to cut an AGS game exe to get just the data file.

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

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!

But when we talk about changing the return value of IsModeSupported(), we talk about the case where no list of available modes is available and in that case it does not matter how many resolutions are tried, all will fail.

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.

Ok, that can maybe improved by changing the driver, but we are talking about changing the return value of IsModeSupported() now.

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.

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?

I'm not objecting to any changes, I'm just advising.

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.

So, right now, my focus is to find a good method of discovering supported modes.

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?

Code: AGS

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;
}

I was thinking merely about adding a human(end-user)-readable changelog to the repository.

I'm thinking that is a very good idea.

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.

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

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

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.

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.