Any news for a 1.6.0 version on iOS?
Moderator: ScummVM Team
Does it work in portrait mode?joanthedark wrote:The previous screenshot was taken with the phone rotated 90º to the left, I tried rotating it 90º to the right and now the mouse does the total opposite to the screenshot (trying to touch the start button moves the mouse to the upper right corner of the screen)
I think turning off click-and-drag mode doesn't automatically enable touchpad mode. So you'll have to enable it by hold one finger and swipe left-to-right.joanthedark wrote:Also, when I turn off click-and-drag mode afterwards, the mouse stays in the same mode for an unknown reason, even when the popup "click-and-drag mode off" appears on the screen.
joanthedark: Here is a test v1.5.0 build for IOS that I just compiled:
http://buildbot.scummvm.org/snapshots/o ... 55.tar.bz2
Can you let me know whether you see the same issue with this or not?
And if you could respond to Lordhoto's queries as he is in a better position to compare and try to replicate than I am.
http://buildbot.scummvm.org/snapshots/o ... 55.tar.bz2
Can you let me know whether you see the same issue with this or not?
And if you could respond to Lordhoto's queries as he is in a better position to compare and try to replicate than I am.
Hi all,
I experienced the same problem in the touch interface.
However, in my case the development version with the standard toolchain is ok, while the problem is present in the clang toolchain.
Along with the touch control problem, with the clang toolchain the ScummVM theme is different i.e. fonts are a lot smaller in the clang toolchain.
Could the problem be due to some settings in the toolchain that control the way that the picture is rendered?
Moreover: with the standard toolchain, support for OGG and MP3 is not present: as soon as a game tries to reproduce a sound, ScummVM crashes. With the clang toolchain everthing seems ok (at least for OGG)
BTW, I'm using an iPad Air.
I experienced the same problem in the touch interface.
However, in my case the development version with the standard toolchain is ok, while the problem is present in the clang toolchain.
Along with the touch control problem, with the clang toolchain the ScummVM theme is different i.e. fonts are a lot smaller in the clang toolchain.
Could the problem be due to some settings in the toolchain that control the way that the picture is rendered?
Moreover: with the standard toolchain, support for OGG and MP3 is not present: as soon as a game tries to reproduce a sound, ScummVM crashes. With the clang toolchain everthing seems ok (at least for OGG)
BTW, I'm using an iPad Air.
The font difference is probably because the Freetype2 library used for fonts is now correctly compiled and present for the newer iphone-clang toolchain. Compare:
http://buildbot.scummvm.org/builders/ma ... logs/stdio
to
http://buildbot.scummvm.org/builders/ma ... logs/stdio
The difference in the touch interface behaviour is very odd and could indicate an unstable heisenbug in the IPhone backend events code... but tracking those down is tricky.
Veda: Could you please test with the v1.5.0 build I indicated earlier and see if the touch interface issue is present or not?
http://buildbot.scummvm.org/builders/ma ... logs/stdio
to
http://buildbot.scummvm.org/builders/ma ... logs/stdio
The difference in the touch interface behaviour is very odd and could indicate an unstable heisenbug in the IPhone backend events code... but tracking those down is tricky.
Veda: Could you please test with the v1.5.0 build I indicated earlier and see if the touch interface issue is present or not?
About the 1.5.0 build you posted: I had to patch the ScummVM executable since I'm on iOS 7.0.4 and iPad Air. Apart from that, it is ok.
Also the stable branch with the standard toolchain (1.6.0) is ok. The problem seems to be present in the clang toolchain.
I just noticed that while I am on the main screen, the cursor is in the center only if I touch the top right corner of the screen.
It seems as there is an offset equal to half the width and height of the screen. Maybe something related to the doubling of the screen resolution that occurs with retina displays?
What about the OGG support difference between standard and clang toolchain? Can you explain that?
Also the stable branch with the standard toolchain (1.6.0) is ok. The problem seems to be present in the clang toolchain.
I just noticed that while I am on the main screen, the cursor is in the center only if I touch the top right corner of the screen.
It seems as there is an offset equal to half the width and height of the screen. Maybe something related to the doubling of the screen resolution that occurs with retina displays?
What about the OGG support difference between standard and clang toolchain? Can you explain that?
Veda: Really... So the bug is not present in the v1.5.0 build I provided?
In that case, this can NOT be due to the newer clang toolchain as that v1.5.0 build was made _WITH_ the clang toolchain and associated libraries.
If you would be willing to test about 5-10 further tests, we should be able to track this down when this problem was introduced to a specific commit.
I have no specific idea of the possible cause as I am not an expert in the iOS backend code or iPhone development in general.
As for the ogg difference, I switched the new toolchain from Tremor (fixed point ogg) to the normal Ogg as this allowed the Theora video decoder to be built and thus the ZVision engine to be built.
In that case, this can NOT be due to the newer clang toolchain as that v1.5.0 build was made _WITH_ the clang toolchain and associated libraries.
If you would be willing to test about 5-10 further tests, we should be able to track this down when this problem was introduced to a specific commit.
I have no specific idea of the possible cause as I am not an expert in the iOS backend code or iPhone development in general.
As for the ogg difference, I switched the new toolchain from Tremor (fixed point ogg) to the normal Ogg as this allowed the Theora video decoder to be built and thus the ZVision engine to be built.
Yes, I can confirm that the build iphone-branch-1-5-0-cb053b55.tar.bz2 is ok.
In this case however I'm not experiencing the "smaller fonts", and with the stable 1.6.0 is the same.
I can test other builds, no problem
So the build iphone-branch-1-5-0-cb053b55.tar.bz2 has been made with the clang toolchain... But with or without the Freetype library you were speaking about?
Should we start to try reverting that one back in the master (1.7.0) build?
In this case however I'm not experiencing the "smaller fonts", and with the stable 1.6.0 is the same.
I can test other builds, no problem
So the build iphone-branch-1-5-0-cb053b55.tar.bz2 has been made with the clang toolchain... But with or without the Freetype library you were speaking about?
Should we start to try reverting that one back in the master (1.7.0) build?
Hmm.. I suspect that build may have been made with the older toolchain. Certainly freetype appears to be missing.
A scan with strings shows the compiled features to be: TAINTED Tremor FLAC MP3 RGB zLib
(And please don't ask about TAINTED. It just means that the source code had some local changes. These are very experimental test builds and IIRC I had to make a minor modification to get the v1.5.0 source code to build with the updated environment).
SIGH. This is really tedious.
Removing freetype2 from the newer v1.7.0 build breaks several engines and I was bothered by several users to add it in. I am not going to start pulling it back out again unless we can exactly track down the cause of this, rather than shooting in the dark.
A scan with strings shows the compiled features to be: TAINTED Tremor FLAC MP3 RGB zLib
(And please don't ask about TAINTED. It just means that the source code had some local changes. These are very experimental test builds and IIRC I had to make a minor modification to get the v1.5.0 source code to build with the updated environment).
SIGH. This is really tedious.
Removing freetype2 from the newer v1.7.0 build breaks several engines and I was bothered by several users to add it in. I am not going to start pulling it back out again unless we can exactly track down the cause of this, rather than shooting in the dark.
Ah yes. Have confirmed that the v1.5.0 test build was made with the older toolchain and thus is missing Freetype2.
Also, you can always see in the ScummVM GUI whether a feature was compiled into a build as it is present at the start of the About box on the main "Game Chooser" screen.
That build was sufficient for debugging as joanthedark reported that the mouse issue occurred with both builds. Unfortunately she is now not responsive, so I have no idea if she has tested this or not.
I suspect your issue may be related to the iPad Air's high screen resolution size i.e. Retina as we have had other reports of issues with this.
Looking at our GUI code, the ThemeEngine class uses Freetype2 if present to provide loading of scalable fonts, otherwise it falls back to non-scalable ones.
I would suspect the large screen size is causing problems somewhere with this code, resulting in very small fonts.
Will produce the with and without freetype builds for you to test with to start with. After that, we can try adding some debugging to track down any issues.
Also, you can always see in the ScummVM GUI whether a feature was compiled into a build as it is present at the start of the About box on the main "Game Chooser" screen.
That build was sufficient for debugging as joanthedark reported that the mouse issue occurred with both builds. Unfortunately she is now not responsive, so I have no idea if she has tested this or not.
I suspect your issue may be related to the iPad Air's high screen resolution size i.e. Retina as we have had other reports of issues with this.
Looking at our GUI code, the ThemeEngine class uses Freetype2 if present to provide loading of scalable fonts, otherwise it falls back to non-scalable ones.
I would suspect the large screen size is causing problems somewhere with this code, resulting in very small fonts.
Will produce the with and without freetype builds for you to test with to start with. After that, we can try adding some debugging to track down any issues.
Veda: Please try these two builds of the latest master with and without freetype to compare:
http://buildbot.scummvm.org/snapshots/o ... pe.tar.bz2
http://buildbot.scummvm.org/snapshots/o ... pe.tar.bz2
http://buildbot.scummvm.org/snapshots/o ... pe.tar.bz2
http://buildbot.scummvm.org/snapshots/o ... pe.tar.bz2
Hmm... Right. Will build a v1.5.0 and v1.6.0 with freetype and without with the newer clang toolchain for you to test with i.e. 4 builds.
If we still get the same issues, then I will try producing a build with the older and the newer toolchain from the latest git master but with added debug output to print font information etc. and see if we can track down the difference.
If we still get the same issues, then I will try producing a build with the older and the newer toolchain from the latest git master but with added debug output to print font information etc. and see if we can track down the difference.
-
joanthedark
- Posts: 29
- Joined: Thu Apr 25, 2013 7:22 pm
No, when I enable click-and-drag on portrait mode, the mouse stays inaccurate.LordHoto wrote:Does it work in portrait mode?
Sorry I have been away too long, college can be time consuming sometimes.
I can confirm that iphone-branch-1-5-0-cb053b55.tar.bz2 "click-and-drag" mode works perfectly. In fact, it does run Eye of the Beholder 2 as well. And I could enable click-and-drag in-game with no trouble at all (remember I said I couldn't enable it on the other versions you provided for some reason).
I also noted that the menu has the same layout like the 1.5.0 version from Cydia store (where click-and-drag works as well).
However, the clangs with and without freetype (5eaddc58) have the same problem I have been experiencing (where click-and-drag mode doesn't work accurate and its impossible to enable it in-game). So the problem is not about freetype. They also have the new layout menu.
What Veda says about Retina Display is probably what is causing the problem, because iPhone 3G doesn't have it (LordHoto's one) and maybe that's why he can't replicate the issue.