Messages

Just tested saving again...
The normal "SAVE" button seems to work fine, the "SAVE + EXIT" doesn't seem to save (unless it's meant to not overwrite a "SAVE").

Scrolling wise, it looks like pixel distortion (pixels appearing to compress or stretch as the they move) coming from the smooth scrolling, but if I change the game settings to run in my desktop resolution this seems to stop. I also just noticed that running with "Bind to game scaling" (I think this was the default) as the graphics mode, distorts the font on the title screen in a similar way.

Also, if you press escape on the title screen, you'll get a non-working menu appearing...

I think that this one is much easier to understand. If automatic selection of the Hqx filter type would be an issue you could have "Limit Hqx to x2" (or something similar) in the advanced section, for spacing you could move VSync option out of advanced and into "Graphics settings" (now that it works in Direct3D mode). But as it is now is fine to me.

E: The main issue (at least for me) is the time, because I honestly do not want to spend more than needed on setup program while there are more important issues waiting to be adressed.

That's fair enough. I think just these things would make it easier to understand:

- rename scaling options using Gurok's suggestions
- imply filter does not apply unless scaling is in use (just move it underneath and potentially disable it if not scaling)
- Change "Best round scaling (x1)" to "None", because that isn't going to use any scaling filter (right?)

I don't know if this is the case. As I see it, the options for Filter change when you change Display Driver. I agree that we should putting filters below scaling anyway. It would make more sense that it's subordinate, even if it's not right now.

At the moment, if you pick Hq3x, the 2x scaling option will magically disappear. I think it's best if the options presented remain consistent. After changing the graphics driver, that's fair enough, you'd expect it works differently.

Best round scaling --> Max multiplier (5x)

Sound good to me.

Presumably this form isn't straightforward to edit? Also I seem to recall someone already wrote a replacement in Lua, what happened to that one?

I mean, your quality setting does not change the resolution you chose to run in. So don't have an option saying Hq3x that doesn't necessarily give you 3x scaling. Just pick 3x scaling, and then set scaling to high quality.

Also, some advice. Forgive me if it's overly presumptuous. I think we should take cues from the Unity setup tool:

Yes, just like this, where quality has no perceived effect on resolution.

At the moment it's showing scaling multipliers under Filter (as in, the filter implies a scaling by it's name) and it looks like the scaling options are having certain multipliers removed based on the filter you pick.

What I'm suggesting is that for scaling you pick Nearest-neighbour or High Quality and there is no scaling multiplier associated with the filter (i.e. there are two options to choose from). This means that the scaling list does not magically have it's content changed depending on which filter you have selected and also makes sure no-one thinks the multipliers are cumulative (since "Hq3x" filter with "x3" scaling is not "x9" scaling). It's probably best to move filter below the scaling options, and rename it as "scaling filter", i.e. if you aren't scaling you aren't using the filters.

Also the "no scaling" mode changes between "x1" and "none", depending on whether you are using fullscreen or a window, but aren't these the same thing?

I would also rename the scaling options, and put them in this order (lower options are potentially less accurate in how they draw, so you should default to the top option and work your way down):

Best round scaling --> Pixel-perfect scaling
Stretch, keep game's aspect ratio --> Full-screen scaling (preserve aspect ratio)
Stretch to whole screen (window) --> Full-screen scaling

...maybe someone else could think of better names, but I don't think many people would understand them as they are labelled at the moment.

The difference between "Stretch (keep aspect ratio)" and "Best round scaling" is that stretching to whole screen, even if maintaining proportions, may produce fractional scaling (e.g. scaling to 3.2, or 5.1), which sometimes causes part of image to distort. "Best round scaling" on other hand uses maximal round (integer) scaling factor (e.g. x3 or x5) which always produce clear image.

So don't you just need these?

- Windowed or fullscreen
- Resolution (desktop resolution and anything else that is supported by the graphics card)
- Scaling type (HQ or Nearest-neighbour - with a note that HQ is only in-effect up to 2x scaling)
- Scaling (explicit scaling multiplier, max integer, fit to resolution, fit to resolution (preserve aspect ratio))

Unless I'm misunderstanding scaling vs. stretching, aren't they the same thing? I think the way it's working at the moment is giving you multiple options that give the same result and this makes it quite confusing.

Is there actually any difference in the result of these 3 selections?

- Game resolution
- Nearest-neighbour
- Stretch (keep aspect ratio)

- Desktop resolution
- Nearest-neighbour
- Best round scaling

- Desktop resolution
- Nearest-neighbour
- Stretch (keep aspect ratio)

I really liked this, everything about it is very cohesive.
Saving a game didn't seem to work for me (and you might need a seizure warning when the skyline scrolls!) but I really enjoyed it.

I just acquired a 1000. I can load a game without any problems using the latest master build from the build server, but it doesn't find the patches.dat file to get MIDI working. I compared it with the last build available from JJS, and with this build it seems to find the patches.dat file (no warning as the game starts, plus a lengthy delay before the game comes up - I guess it's actually caching audio data at this point). I don't actually get any audio with either build, but perhaps that's because the 1000 doesn't have enough memory.

When switching resolution the mouse cursor is being restricted in the window, by the same offset that it was restricted to in full screen (with black borders).

i.e. if the black border was 10px at the top of the screen, when switching to a window the cursor is being restricted 10px from the top of the game. If I don't see the problem at the top of the screen I see it at the bottom, but not top and bottom at the same time.

I've got an external monitor connected, but it seems to happen when just testing on the primary display.

I can confirm the mouse update problem for ags 3.3.5.3 on Linux in windowed mode with the game Mudlarks v1.6 but it works fine in full screen mode. The game Pendek works fine in windowed mode tough.

I think that you might not see the cursor movement restrictions if the game resolution is an exact fit for your display, i.e. you are running with no borders so there is no need to offset the game to centre it.

It seems that the cursor movement restrictions begin to occur once the mouse control routines were disabled for Linux. I've tested with mouse control routines for Linux enabled and for me it all seems to be working fine (I can control mouse speed with the game config file without any sort of control or display issues). I would like to suggest reverting the X11 lag fix and enabling mouse control for the Linux platform. This would give the chance for any interested party to test for issues.

I think a lot of the issues you were seeing were actually down to bizarre behaviour of the VMware mouse or graphics integration. I've had it go completely haywire after a resolution change and at times it has been causing cursor alignment issues inside the VM (input is no longer aligned to the mouse cursor in the window manager - not even running the game). At one point I ran the same game I've always been testing, fullscreen, and it decided to display it aligned to the right edge of the screen instead of in the middle. I did also see the delayed mouse acceleration that you had described earlier but I can't recreate this outside of the VMware environment.

Okay, I've tried building with this VMware image.
During the setup I:

• declined the installation of the host side keyboard driver
• installed all VMware tool updates
• installed all Ubuntu package updates

For me it acts the same way as the physical PC (very long delay on mouse input and cursor position is incorrectly restricted when fullscreen).

Leave it with me and I'll step through the changes.

I'll install VMware Player as well and see what it does. If it behaves the same way as you describe then I'll go back through the commits and test on the VM and an actual PC.

I should be able to test it on another computer tomorrow afternoon, so I'll confirm if that acts the same way as the one I have at home.
What do you use to run your VM?

But I need to clarify: the commit (https://github.com/adventuregamestudio/ags/commit/6a35ec9936b545cbb4d405309f24359fbe6e80f5) makes your mouse lag for 20 seconds?

Yes, in a window and fullscreen, the cursor only moves after a delay of around 20 seconds. There is no excessive CPU usage during this time.

There is something that I found: if I run the game with no scaling on large desktop, then it works very slow. It is not only mouse that moves slow, but everything: this is clearly visible if some animation is playing.

Yes, I can confirm that the "x11 lag" patch commit causes this.

As soon as I set any scaling filter, even x2 scaling, the slowdown stops.

The problem I'm seeing is definitely based on restricted mouse position, not on load.

I could not reproduce this, but when I run AGS games on my virtual machine, they always show up in the top-left corner, instead of the screen center. Since no one ever mentioned that, I was thinking this is because of how virtual machine works.

I think this goes some way to explaining the problem. The mouse restriction movement restrictions which are imposed seem to align with where the game would have been displayed if it was in the top left corner of the screen (instead of in the centre). Just to re-iterate, when I built 3.3.5 mid February I had no mouse issues at all, I noted unexpected load from applying standard scaling which slowed down everything, but without the excessive load the mouse behaved properly (in terms of position and control) in a window and fullscreen. This is why I asked if anyone else had seen the issues you were describing, perhaps the mouse issues you have seen are specific to how you run your VM.

I was seeing this problem in a window and fullscreen.

This commit introduces the problem:
https://github.com/adventuregamestudio/ags/commit/6a35ec9936b545cbb4d405309f24359fbe6e80f5

But even with a controllable cursor (reverting the above commit), something seems to off with regard to fullscreen. The cursor movement is restricted to co-ordinates which are too small, contained to the top left corner of the game. Using x2 scaling increases the area it's possible to move in, and is a closer match to the actually game resolution, but still not correct.

It is building for me, but unfortunately now I am seeing a problem with the mouse cursor. The cursor position is updating about 20 seconds after I move the mouse, so isn't usable to play a game. Did you find anyone else to confirm the mouse cursor issue you described earlier in this thread? To me the older 3.3.5 build wasn't behaving any differently to how I remembered 3.3.4 or 3.4.0 builds.