http://bugs.winehq.org/show_bug.cgi?id=35336
Bug ID: 35336
Summary: HoMM 3: Horn of the Abyss launcher freezes on the game
update (Mono issue)
Product: Wine
Version: 1.7.10
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: winebugs140(a)gmail.com
Classification: Unclassified
How to reproduce: open HotA_launcher.exe and then click on Update HotA. If you
try to cancel the update or there will be no updates available, the application
freezes.
With 'winetricks dotnet30' the launcher works fine, so it looks like a problem
with Mono.
You DON'T NEED Heroes of Might & Magic 3 to test this, you can open the
launcher of this unofficial expansion without downloading the original game.
There is nothing in the logs.
TESTED ON:
Ubuntu 13.04 and Mac OS X 10.9 Mavericks
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=54143
Bug ID: 54143
Summary: Chessbase 11 arrows draw too large
Product: Wine
Version: 8.0-rc1
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: gdiplus
Assignee: wine-bugs(a)winehq.org
Reporter: dav75uk(a)yahoo.co.uk
Distribution: ---
Created attachment 73675
--> https://bugs.winehq.org/attachment.cgi?id=73675
Picture of arrow on wine8.0-rc1
When arrows are drawn using Chessbase 11, they are too big. See attached
screenshot and log.
Compare with:
https://www.youtube.com/watch?v=xvJd97ZnHAk
At 4:58 an arrow is showing from g8 to f6 pointing to a knight that has just
moved. I've also set up this arrow on chessbase 11 with wine 8.0-rc1. Note
later chessbase draws arrows slightly different, so software like CBReader14
doesn't appear to be affecting by this issue.
On wine 8.0-rc1 in CB 11 the stem of the arrow looks approx in the right place.
It crosses f7/g7 (the squares occupied by pawns) at the right point. The tip of
the arrow is in the right place on the knight between the white on the mane and
the chin. On wine 7.22 the endcap square (some default catch in a switch
statement maybe) is being drawn which is not on native chessbase (thus the
arrow isn't meant to hide it). Finally the back of the arrow head is in the
wrong place (some scaling maybe?) which is making it too large. On wine 7.22
the back of the arrow is drawn from the right shoulder of the pawn on f7 (the
one nearest the king) to near (left of) the base of the one on g7. In the video
the arrow appears from under the base of the f7 pawn (almost but not quite
lined up horizontally the bishop on f8's cross right hand edge) to just inside
the corner of the square the knight is on.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=51890
Bug ID: 51890
Summary: A lot more old games would be so much more usable if
wine's virtual desktop had proper resizing
Product: Wine-staging
Version: 6.18
Hardware: x86-64
OS: Linux
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: el(a)horse64.org
CC: leslie_alistair(a)hotmail.com, z.figura12(a)gmail.com
Distribution: ---
I have a really significant amount of older games around, none of which will
launch on this machine without wine's virtual desktop feature because on a
widescreen monitor, they determine there is no "expected" fullscreen resolution
available and crash.
Now I'd just use the virtual desktop, except it feels archaic and not very
usable: why is it that for a 800x600 game on a 800x600 virtual desktop, I can't
just maximize the virtual desktop window and get the virtual desktop SCALED UP
with proper letterboxing so I can play in some other way than a tiny window
with zero immersion and everything so small I can barely see it? Funnily enough
I can even resize the virtual desktop window except the resizing is fully
ignored and I just get black void with no scaling up all around with the game
stuck in the top-left, and the maximizing is blocked.
Scaling up (with automatic letterboxing), maximizing would seem like such
obvious features to make virtual desktop gaming infinitely less clumsy and
weird that I am a bit surprised it's not in there yet. Can it please be added??
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55006
Bug ID: 55006
Summary: vbscript single line if else without else body fails
compilation
Product: Wine
Version: unspecified
Hardware: aarch64
OS: Mac OS X
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: vbscript
Assignee: wine-bugs(a)winehq.org
Reporter: francisdb(a)gmail.com
This is valid vbs when run with `cscript`
```
If x = 1 Then DoSomething() Else
```
wine vbscript fails with: "Compile error: Line: #, Character: #, Description
unavailable"
Workaround is changing the code to
```
If x = 1 Then DoSomething() Else:
```
or
```
If x = 1 Then DoSomething()
```
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44931
Bug ID: 44931
Summary: This program requires at least 3MB of free virtual
memory to run in "Nine: The last Resort" game
Product: Wine
Version: 3.5
Hardware: x86
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: register001(a)free.fr
Distribution: ---
Created attachment 61032
--> https://bugs.winehq.org/attachment.cgi?id=61032
WINEDEBUG=+relay,+seh,+tid wine your_program.exe >> /tmp/output.txt 2>&1
I get this error dialog box when running the game Nine The last Resort after
installation.
Dialog Title: "Director Player 5.0"
Message: "This program requires at least 3MB of free virtual memory to run"
Config:
Ubuntu 16.04
wine-3.5
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55496
Bug ID: 55496
Summary: World of Warships (12.7 update) - Graphical glitch -
Water texture and effects at wrong sea level.
Product: Wine
Version: 8.11
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: o.dierick(a)piezo-forte.be
Distribution: ---
Created attachment 75058
--> https://bugs.winehq.org/attachment.cgi?id=75058
Screenshots with glitch highlighted in red.
Hello,
Since the game update to 12.7, water textures and effects are rendered below
the sea level.
All objects are rendered at the same 'sea' level and the physics are respected,
but the water texture and effects are drawn below the sea surface, as if it was
painted at the bottom of a perfectly transparent sea, instead of the top.
I'm joining screenshots that show the issue. The glitches are highlighted with
red arrows.
On the first screenshot, the splash of the water drains are visibly shifted
below the ship in the port.
On the second screenshot, the space between the island in the distance and the
water texture below them is visible. Water trails from moving ships are shifted
below them.
On the third screenshot, the water trail from the player ship is shifted, as
are the splashes from artillery shells.
The fourth screenshot shows more shifted water trails and shells splashes, from
a dead player's observation camera (higher in the sky).
The height of the glitch is proportional to the distance of the camera zoom.
The farthest the camera is of the ship, the lower the water texture is drawn.
When the camera is zoomed to the closest, the water texture and effects are
nearly perfectly placed (it's still shifted by a small amount).
The glitch is easier to see when turning the camera around, as the water
texture doesn't match the ship position (because of perspective). The water
trails and splash effects do match the water texture position, but not their
respective objects. Objects matches their relative positions.
Note that on the screenshots, the horizon curve to the edge is magnified by my
ultra-wide resolution. Don't worry about the calculator on the first
screenshot. I had trouble getting a non-transparent screenshot of the Wine
full-screen window. After that capture, I found another way that didn't require
a non-full-screen window to be active.
Regards.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=53371
Bug ID: 53371
Summary: 0024:fixme:ntdll:create_logical_proc_info stub
Product: Wine
Version: 7.12
Hardware: x86-64
OS: FreeBSD
Status: UNCONFIRMED
Severity: blocker
Priority: P2
Component: -unknown
Assignee: wine-bugs(a)winehq.org
Reporter: yklaxds(a)gmail.com
Created attachment 72755
--> https://bugs.winehq.org/attachment.cgi?id=72755
log
FreeBSD 13.1 release amd64
KDE plasma 5
emulators/wine-devel 7.12 not work at all.
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55495
Bug ID: 55495
Summary: ntdll:threadpool - test_tp_wait() sometimes gets an
unexpected timeout in Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
ntdll:threadpool - test_tp_wait() sometimes gets an unexpected timeout in Wine:
threadpool.c:1715: Test failed: WaitForSingleObject returned 258
threadpool.c:1720: Test failed: expected info.userdata = 0, got 65536
threadpool.c:1729: Test failed: WaitForSingleObject returned 0
See See https://test.winehq.org/data/patterns.html#ntdll:threadpool
1715 & 1720: The timeout can also happen on Windows 8 and in that case the test
expects info.userdata to still be zero. But in Wine info.userdata still gets
set despite the timeout so the test fails. A hacky fix would be to expect the
correct behavior if (!broken(result == WAIT_TIMEOUT)) but it would be much
better to fix Wine's implementation.
Then the next WaitForSingleObject() does not time out which sounds a bit
similar to bug 55493.
The oldest known instance happened at the start of May and this seems to mostly
happen on the GitLab CI:
* 2023-07-28 MR!3441 (only the last two failures?)
* 2023-06-01 MR!2951 (only the last two failures?)
* 2023-05-31 fg-deb64-t32
* 2023-05-24 gitlab-debian-32
* 2023-05-02 MR!2734
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=55493
Bug ID: 55493
Summary: ntdll:threadpool - test_tp_timer() sometimes fails in
Wine
Product: Wine
Version: unspecified
Hardware: x86-64
OS: Linux
Status: NEW
Severity: normal
Priority: P2
Component: ntdll
Assignee: wine-bugs(a)winehq.org
Reporter: fgouget(a)codeweavers.com
Distribution: ---
ntdll:threadpool - test_tp_timer() sometimes fails in Wine:
threadpool.c:1439: Test failed: WaitForSingleObject returned 0
threadpool.c:1441: Test failed: WaitForSingleObject returned 258
See https://test.winehq.org/data/patterns.html#ntdll:threadpool
So instead of getting a timeout then a success, the test first gets an
unexpected WaitForSingleObject() success and then a timeout. That means it's
not a simple issue of the test running too slow.
There are only three known instances so far:
* 2023-08-23 MR!3621
* 2023-07-03 MR!3218
* 2023-06-09 fg-deb64-t32
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.