AGS 3.3.5 -- Release Candidate

Started by Crimson Wizard, Sat 21/11/2015 19:45:52

Previous topic - Next topic

morganw

Are you sure that it's not caused by a mouse acceleration feature of whatever you are using to run the VM? I've played 4 or 5 games on the Linux engine over the last year and it's never been an issue (the way you are describing it is as if the whole thing is fundamentally unusable). Also, have you got more than one CPU core available to the VM?

Crimson Wizard

#21
Quote from: morganw on Sat 13/02/2016 23:24:18
Are you sure that it's not caused by a mouse acceleration feature of whatever you are using to run the VM? I've played 4 or 5 games on the Linux engine over the last year and it's never been an issue (the way you are describing it is as if the whole thing is fundamentally unusable). Also, have you got more than one CPU core available to the VM?

The new mouse routine was added to the WIP branch only recently. This ONLY happens in fullscreen mode.

I do not think this is related to acceleration, its more like mouse movements are lagging behind. I move mouse to the left, then stop and then start moving it to the right, but cursor continues to move to left for some time. It looks like the event queue gets cloggered with extra "relative move" events.

E: or it can be that Allegro summs up extra dx/dy values at some point...



E2: The most interesting thing is that simply calling get_mouse_mickeys function without actually using returned values produce this effect...

E3: The real trouble is that I MUST use mouse_mickeys, because otherwise it is possible to get into situation when system cursor reaches the screen border, while the game cursor haven't, and player won't be able to move cursor any further. (This may happen e.g. if the cursor speed is lowered).

I need to find out what is going on...


Can someone else test this on Linux? I need to know if this happens only for me, or others can reproduce this too.

Mehrdad

#22
Is it possible add 640X360 support resolution in this version?
I think 3.4 takes long time for stable release.
As I need to this size for HD output.
My official site: http://www.pershaland.com/

Crimson Wizard

Quote from: Mehrdad on Sun 14/02/2016 16:18:21
Is it possible add 640X360 support resolution in this version?
No, I am done adding features to this version. I just have 1 issue to fix and the version is finished.

Crimson Wizard

#24
Released an update to 3.3.5 Beta (now 3.3.5.2 RC1).

Installer: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5.exe
ZIP archive: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5.zip
No-MP3 engine: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5-noMP3.zip


This is a mainly a bug-fixing update.


Added changes:

Editor Bug Fixes:
- Fixed parsing functions with optional parameters (regression);
- Fixed minimal negative integer literal (-2147483648) was not parsed properly (incomplete feature).

Manual:
- Updated to 3.3.5.


KNOWN ISSUES (expected to be fixed):
- Mouse cursor movement does not work well under Linux when running in fullscreen. This is pretty bad, and this version cannot be finalized without addressing this issue first.
- The Windows Installer uses application GUID from AGS 3.3.4, which will replace existin 3.3.4 installation with 3.3.5 in the installed program list, if you have installed 3.3.4 to your computer earlier. This is a small technical mistake, that will be corrected in final release.

AGD2

I gave this a quick test and the previous compile errors I reported are solved now. Hooray!

Though, I ran into a new one. Our game has some custom debug functions and one of them uses the .File functions to store and retrieve data from a .log file.

Code: ags

static void Debugger::ShowDebugMessage(String message, int iCategory, int iSeverity ){
#ifdef DEBUG
  if( gbShowDebugMessages ){
    File *logFile = File.Open("debug.log",eFileAppend);
    
    message = String.Format("%s|%d|%d", message, iCategory, iSeverity );
    
    logFile.WriteRawLine(message);
    logFile.Close();
    int i = GetNextFreeMessage();
    if (i < 0) return;
    DebugMessages[i].Message = message;
    DebugMessages[i].timer = 120;
  }
#endif
}


This function was called from game_start and it crashes with a "Null pointer referenced" error on the logFile.WriteRawLine and logFile.Close(); lines. (It also crashes if I move the function call from game start to a room's Load_room or After Fadein script. These lines/functions didn't cause a crash in previous editor builds.

A couple of other things:

1) In winsetup.exe, "Auto Lock to Window" works on my system, but the Mouse Speed slider doesn't seem to make any difference to the cursor speed in game (Win 7). When I quit and reload winsetup.exe, the slider always resets back to the default (x 1.0) position. However, if I load winsetup.exe, change the slider position, click Save, close winsetup without running the game, and then open winsetup.exe again, the slider will be saved at the last position I had set it to.

2) I downloaded the zip archive, and pressing F1 in the editor says that ags-help.chm is missing.

Crimson Wizard

#26
Quote from: AGD2 on Wed 17/02/2016 14:26:21
Though, I ran into a new one. Our game has some custom debug functions and one of them uses the .File functions to store and retrieve data from a .log file.
Please, read the information just below the red font line in the first post of this thread. It has an information regarding new file path rules.

E: the fact that it does not report error, but just returns a null pointer seem to be a bug...


Crimson Wizard

Quote from: AGD2 on Wed 17/02/2016 14:26:21
the Mouse Speed slider doesn't seem to make any difference to the cursor speed in game (Win 7).

Do you test in fullscreen or windowed mode?

AGD2

QuotePlease, read the information just below the red font line in the first post of this thread. It has an information regarding new file path rules.

E: the fact that it does not report error, but just returns a null pointer seem to be a bug...

Hmm, when I put $SAVEGAMEDIR$/ into the path it did start compiling fine again. Just figured I should report it anyway.

QuoteDo you test in fullscreen or windowed mode?

I had tested it in windowed mode. But just tested it in full-screen mode and that worked perfectly. :)

Crimson Wizard

#29
Quote from: AGD2 on Wed 17/02/2016 15:01:40
Hmm, when I put $SAVEGAMEDIR$/ into the path it did start compiling fine again. Just figured I should report it anyway.
I should note that you may find it easier to set up a custom path for writeable game files in winsetup (by default it should choose current directory) when testing the game, to have faster access to logs.

I was also considering to allow the game write to any random location if it is compiled with DEBUG setting, but I am not sure about that: it is easy to forget about this peculiarity and leave non-working code in game if you do not safeguard the script with "#ifdef DEBUG".

Quote from: AGD2 on Wed 17/02/2016 15:01:40
QuoteDo you test in fullscreen or windowed mode?
I had tested it in windowed mode. But just tested it in full-screen mode and that worked perfectly. :)
Ok, then it works as intended. I disabled the ability to control mouse cursor speed in windowed mode; that is technically possible, but I had doubts it may be usable.

Crimson Wizard

#30
I cannot stop thinking that I made a mistake putting this filesystem changes into minor update. With minor update users will expect they may continue working on their existing projects without fixing anything.
But it is too late now. I guess I should add a switch that would reset the behavior.


E: No, on second thought the switch idea seem wrong; I'd rather make it remap unsafe path to safe one with a warning to debug log (aka "warnings.log"), same as we do for old games now.
In other words, there won't be any script error, but the written file will end up in a "safe-to-write-into" directory.
Remember that you (and the player) can always setup their own location for saving game files into, including game location.

Crimson Wizard

Released an update to 3.3.5 RC (now 3.3.5.2 RC2).

Installer: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5.exe
ZIP archive: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5.zip
No-MP3 engine: http://www.adventuregamestudio.co.uk/betas/AGS-3.3.5-noMP3.zip


This is a mainly a bug-fixing update.


Added changes:
Engine Features:
- Changed the file paths behavior: now if you use the path relative to the game installation directory for writing a file, the path will be remapped to $APPDATADIR$, and a warning printed to warning.log (Debug game build only).
Earlier remapping was done only for games created with previous versions of AGS, and new games caused File.Open return null.

Engine Bug Fixes:
- Fixed engine was saving default mouse speed values to config when game run in windowed mode, overwriting user's settings.

Linux:
- Temporarily disabled mouse speed option for Linux. There seem to be something wrong in Allegro4 lib that does not let us use current cursor speed implementation. When we find out how to fix that, the option will be made working on Linux again. As of now, it simply cause no effect.
- Added patch that supposedly fixes mouse lag for mouses with high polling rate.

Manual:
- Updates in topics related to File functions.

Mehrdad

Thanks a lot CW for another great release. I switched and converted my game to this version today . It works fine. I don't see any problem at the moment ;) 
My official site: http://www.pershaland.com/

Crimson Wizard

#33
Too bad it was taking much more time than expected.

cianty

Awesome! Thanks a lot for all the hard work!
ca. 70% completed

Crimson Wizard

Can someone please tell if you are able to build AGS under Linux in "develop-3.3.5" branch?
We have makefile changed some time ago and now it does not work for me, unless I change it a little.
Since this is something beyond my current knowledge, I need to know if it's only my problem, or other people have it as well.

morganw

#36
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.

Crimson Wizard

Quote from: morganw on Sat 05/03/2016 21:38:28
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.
Does it behave so if you build the latest state of the branch? I explicitly disabled new mouse code for Linux for this time.

blur

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.

Crimson Wizard

That sounds different from what I experienced.
Would anyone be able to walk the history back and see if it was introduced recently?

SMF spam blocked by CleanTalk