Re: Implement THREAD_PRIORITY_TIME_CRITICAL

2006-04-05 Thread Adam D. Moss

Willie Sippel wrote:
No need for a full-blown game, I use this great free 5.9MB demo to test audio 
on Wine:

http://www.pouet.net/prod.php?which=18359

Unbearable with regular Wine (kernel 2.6.13/ amd64, gentoo r5 patchset - can't 
test with later kernels, as there's a problem with the SCSI-subsystem as of 
2.6.14), just dandy with Mikes patch and realtime-lsm...


This works 101% perfectly under WINE (CVS HEAD, no
special patches), running as a user, kernel 2.4.31,
wine-oss sound driver on top of ALSA 1.0.5a's OSS
emulation.

Frame rate isn't brilliant (750MHz machine) but audio
is spotless.

My sound hardware is:
0 [Live   ]: EMU10K1 - Sound Blaster Live!
 Sound Blaster Live! (rev.7) at 0xd800, irq 12

FYI my audio experience with this setup has been flawless
with wine for as long as I can remember, at least devoid
of the stutters and noise that many people seem to
experience.

Wow, I just tried the demo with wine's 'native' ALSA driver
and the audio does break up a lot...

--adam





Re: Failed to find a suitable visual

2005-07-17 Thread Adam D. Moss

Saulius Krasuckas wrote:

OpenGL vendor string: NVIDIA Corporation
OpenGL renderer string: GeForce2 MX/AGP/SSE
OpenGL version string: 1.5.3 NVIDIA 71.74

[..]

   visual  x  bf lv rg d st colorbuffer ax dp st accumbuffer  ms  cav
 id dep cl sp sz l  ci b ro  r  g  b  a bf th cl  r  g  b  a ns b eat
--
0x21 16 tc  0 16  0 r  y  .  5  6  5  0  4 16  0 16 16 16 16  0 0 None
0x22 16 dc  0 16  0 r  y  .  5  6  5  0  4 16  0 16 16 16 16  0 0 None
0x23 16 tc  0 16  0 r  .  .  5  6  5  0  4 16  0 16 16 16 16  0 0 None
0x24 16 tc  0 16  0 r  y  .  5  6  5  0  4  0  0 16 16 16 16  0 0 None
0x25 16 tc  0 16  0 r  .  .  5  6  5  0  4  0  0 16 16 16 16  0 0 None
0x26 16 dc  0 16  0 r  .  .  5  6  5  0  4 16  0 16 16 16 16  0 0 None
0x27 16 dc  0 16  0 r  y  .  5  6  5  0  4  0  0 16 16 16 16  0 0 None
0x28 16 dc  0 16  0 r  .  .  5  6  5  0  4  0  0 16 16 16 16  0 0 None


If I remember correctly (my GF2 blew up last year), this card does
implement/advertise stencil buffers if you run in 24-bit mode.  That
would certainly help to identify whether the lack of stencil is a
problem here.

--adam




Re: Failed to find a suitable visual

2005-07-17 Thread Adam D. Moss

Oliver Stieber wrote:

That's odd, you don't have a single visual that
supports a stencil buffer. I'm fairly sure that OpenGL
requires at least one, but seeing as you don't have
any I'll send in a new patch.


There's no requirement that a GL implementation supports stencil
buffers in any way (or accumulation buffers, or indexed-colour
modes, or destination-alpha, or quad-buffers, or...), unless of
course it advertises a visual with those features, which it is
under no obligation to do.

Cheers,
--Adam




Re: [x11drv] d3d stencil support

2005-07-04 Thread Adam D. Moss

Hi!

Oliver Stieber wrote:

+if (visual == NULL) {
+/* fallback to a 1 bit stencil (opengl states that at least 1 bit of 
stencil must be provided for on of the available configurations) */
+WARN(Failed to get a visual with at least 8 bits of stencil\n);
+int dblBuf2[] = 
{GLX_RGBA,GLX_DEPTH_SIZE,16,GLX_STENCIL_SIZE,1,GLX_DOUBLEBUFFER,None};
+
+wine_tsx11_lock();
+visual = pglXChooseVisual(display, DefaultScreen(display), dblBuf2);
+wine_tsx11_unlock();
+if (visual == NULL) {
+/* This should only happen if we cannot fidn a match with a depth 
size 16 */
+FIXME(Failed to find a suitable visual\n);
+}
+}


It's always nice to have a fallback, but in real life I've
never seen PC hardware (even back to the 90s) which supports
a 1-bit stencil buffer and not a 8-bit stencil buffer, so
this may be over-redundant.  (Would be interested in hearing
of any consumer hardware which only does a 1-bit stencil.)

Regards,
--adam



Re: [x11drv] d3d stencil support

2005-07-04 Thread Adam D. Moss

Oliver Stieber wrote:

The fallback is there because 1 bit stencil is the
minimum required by the opengl specification, so it is
possible that somewhere there is a driver that only
supports 1 bit stencil.


I understood that, I was simply saying that I don't think
there's ever been a consumer graphics card that did only
1-7 bits -- they seem to universally do 0 or 8 bits of
stencil (even the software-renderers), so the fallback is
likely a waste of breath, though I appreciate caution.

Perhaps more to the point, does D3D only guarantee a
1-bit stencil buffer?  A 1-bit stencil buffer (most
especially one without GL_EXT_stencil_wrap) is of very,
very limited use.  I somewhat expect that no D3D applications
(except maybe, just maybe, some very simple test-apps)
will actually operate correctly with a 1-bit unwrapped
stencil.

Cheers,
--adam




Re: DirectDraw YUV overlays

2005-03-25 Thread Adam D. Moss
Lionel Ulmer wrote:
I would suggest using the Xv extensions again if possible.
Yes, and it will provide hardware-based scaling for free too... I wonder if
GL exports any YUV-like texture formats on modern hardware.
Not really. :(  There's an apple-specific extension for it.  On
the other hand, YUV-RGB conversion should be really
easy to write as a fragment program (either NV_texture_shader,
ARB_fragment_shader [GLSL], ARB_fragment_program,
NV_fragment_program) on any gf3-era card or later, which I'm
guessing is why not many implementors are rushing to standardise
YUV textures.
--Adam



Re: Voodoo3, Banshee and D3D

2005-03-08 Thread Adam D. Moss
Troy Rollo wrote:
Given the age of the hardware I didn't plan to get into finding the correct 
fix, since the hack works for the time being to allow me to debug other 
problems and I haven't heard of anybody else complaining about D3D on Voodoo3 
and  Banshee cards.
Oh, I would have complained, but I just upgraded to a geforce instead. :)
--Adam