http://bugs.winehq.org/show_bug.cgi?id=8460
--- Comment #8 from Stuart Middleton <Stuart(a)houseofanime.org> 2007-08-20 10:39:23 ---
Created an attachment (id=7688)
--> (http://bugs.winehq.org/attachment.cgi?id=7688)
relay log for running DVDProfiler
Incomplete log. The log continued to extend as new floating point errors were
created. The processes was killed once several errors were evident (note how
the kill process took some time to register and the program continued to log
output).
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=8460
Stuart Middleton <Stuart(a)houseofanime.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Stuart(a)houseofanime.org
Version|0.9.37. |0.9.43.
--- Comment #3 from Stuart Middleton <Stuart(a)houseofanime.org> 2007-08-20 10:29:32 ---
Release 0.9.43 has resolved the trivial problem of the hang part-way through
startup, but the main problem (the invalid floating point operation) still
persists. The bug can now be described as follows:
Installation proceeds as expected with only minor cosmetic issues. Upon
launching the application, it starts as expected but the initial screen fails
to display the usual 'next/cancel/whatever' buttons and returns multiple pop-up
messages:
"Invalid Floating Point Operation"
Actions such as clicking on the window can produce new instances of the error
(meaning you can have many errors at any one time), but I can't identify exact
actions that trigger / do not trigger a new message.
I've added several traces etc. although I have no idea what they mean and am
far from certain that they help shed any light on the issue.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=6095
--- Comment #12 from Aaron Slunt <tonglebeak(a)gmail.com> 2007-08-20 10:23:50 ---
I'm almost positive the MOTD relies on the ViewObject_Draw function, which
isn't even implemented yet. At least that's what console output is implying.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=2367
Jesse Allen <the3dfxdude(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |CLOSED
--- Comment #4 from Jesse Allen <the3dfxdude(a)gmail.com> 2007-08-20 10:18:17 ---
closing
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=4935
--- Comment #21 from Roderick Colenbrander <thunderbird2k(a)gmx.net> 2007-08-20 10:18:03 ---
I have debugged the program but the results aren't positive for now. At the
time we used totally different pixelformat code, there's not much left of it,
so I can't compare that with the current situation.
When you want to use OpenGL in your program you need to select a pixelformat
which describes the number of color bits, whether you want double buffering and
more.
The traditional way to select a pixelformat is by using ChoosePixelFormat. You
pass some specifications to it and it selects something. The problem is that
this function can return pixelformats which don't meet your specifications.
(Why this is a different story)
For this reason some programs implement their 'own' ChoosePixelFormat by
walking through all available pixelformats. This is what the IKEA program is
doing using DescribePixelFormat.
First of all it wants a single buffered pixelformat with GDI support
(PFD_DOUBLEBUFFER | PFD_SUPPORT_GDI). Right now we don't offer any single
buffering formats but this is fixable though tricky.
The most problematic thing it does is:
cColorBits = GetDeviceCaps(BITSPIXEL) | GetDeviceCaps(PLANES)
In case of GLX cColorBits corresponds to GLX_BUFFER_SIZE which is 32 while
BITSPIXEL is 24.. That's the main problem.
Wine's GetDeviceCaps should get fixed.
--
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.