http://bugs.winehq.org/show_bug.cgi?id=3117
------- Additional Comments From ead1234(a)hotmail.com 2006-29-04 22:13 -------
I'm having this same issue when trying to install the game political tycoon.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4009
------- Additional Comments From Rincebrain(a)gmail.com 2006-29-04 22:06 -------
So, this bug still persists, and I'd really like to know if anyone has a
solution other than the hack-patch posted below.
*shrug*
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=4449
------- Additional Comments From ryanbach(a)adelphia.net 2006-29-04 21:42 -------
Good question, Louis, I hope someone responds to your question. That sure would
be helpful to quite a few people here. ;)
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=5159
Summary: When using a Microphone in Half Life and HL:S games, it
is screwed up
Product: Wine
Version: 0.9.12.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: wine-directx-dsound
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: ryanbach(a)adelphia.net
I am using OSS driver, and I know it works correctly (Very well BTW) under linux
as I have tested that and it works well. It is good it doesn't crash now but it
is very harsh and goes in and out of "focus" all the time.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
http://bugs.winehq.org/show_bug.cgi?id=2398
dank(a)kegel.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC|dank(a)kegel.com |
------- Additional Comments From dank(a)kegel.com 2006-29-04 21:01 -------
That's it. I'm unsubscribing from this bug until such time
as the whiners and kibbitzers go away.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=2398
------- Additional Comments From philip(a)digitalinfinity.biz 2006-29-04 20:58 -------
Right now with the way the current code works. Just making a GL view port to
display will be very problematic to implement. From the discussion that I've
read on this bug and others. I can see conditions where that implementation and
all the other implementations will be a problem. This is a really ugly situation
we have here to make it work. But here is how I see it. I'm writing this post to
help identify the problem and define the problem better so as to get a better
solution:
First GL view ports probably won't interact properly with the wine windows
properly. I can give you guys some examples. What happens to the view port when
you drag it partially off the screen or over an area where the rendering engine
is supposed to render but clip the window. Because the viewport is a separate X
window your going to run in to problems here. It will be another bug because the
view port will clip the rendered area using the regular engine rather then the
other way around. So this is the draw back of using GL view ports for this.
With pbuffers although these will be the best solution for view ports in
programs that have MDI windows it is not ideal for games and other programs that
don't use those. You will see a performance hit in high performance gaming and
applications. So pbuffers will not be the ideal solution in that situation due
to the fact that you are not rendering directly to the screen. There is a
question of weather there is hardware support for pbuffers and GL Pixmaps. From
what I understand there is none or its very limited. So rendering to the screen
with these will be a problem as well. Pbuffers cannot be used in all
applications or wine will be unusable for games.
These unfortunately is where it stands now with the current engine. When we look
at it windows and X are not that different in their design. All controls in
windows are a window. The same as in X. I remember reading a book on the old
Motif library and how they created a set of controls called gadgets. They were
basically windowless controls. What they indicated in that book is that these
objects were created in earlier version of X and as time went on implementing
objects as an XWindow actually became less expensive then using gadgets. This
was due to improvements in efficiency in the X server. Thats why the practice
doesn't exist today in X and every X control has its own window. This may be
something to consider here.
Any rendering issues of which window to render can be taken care of by using an
Octree to determin which windows to paint. A paint message is then sent to the
individual control or window. The code I've given you above can be used for this
although the C implementation may be a little more involved. It would require
support in the x11drv code and the API to make this happen.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
http://bugs.winehq.org/show_bug.cgi?id=5158
Summary: Foobar2000 fails to write ID3v2 frame to file
Product: Wine
Version: 0.9.11.
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: wine-misc
AssignedTo: wine-bugs(a)winehq.org
ReportedBy: samsam.mn(a)mailnull.com
in most circumstances foobar2000 can write tags to files successfully. But I
noticed when adding a DISCNUMBER tag into a mp3 file with id3v2 tags, foobar
tries to add a TPOS frame into the file, with the desired string.
On winXP, it works as desired, the file gets tagged like :
(hexa) 54 50 4F 53 00 00 00 03 00 00 00 31 00
(ascii) T P O S 1
after adding DISCNUMBER=1. (3 is followed by 2 technical bytes (here 00 00) and
the actual ascii char).
With wine, the written TPOS frame holds an empty string :
(hexa) 54 50 4F 53 00 00 00 02 00 00 00 00
(ascii) T P O S
(there only are the zero bytes, not the actual "1").
Thus it seems wine is causing foobar to fail that operation somehow.
Foobar is not open source, so it's hard to know what is going wrong. This was
posted at
http://www.hydrogenaudio.org/forums/index.php?showtopic=44116, hopefully
foobar2000 devs will give info on what is happening.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.