On Thursday 01 July 2010 17:19:42 Stefan Dösinger wrote:
> Am Donnerstag 01 Juli 2010 16:54:08 schrieb Fabian Bieler:
> > -glTexImage2D(GL_TEXTURE_2D, 0, GL_LUMINANCE, 1, 1, 0,
> > GL_LUMINANCE,
>
> GL_UNSIGNED_BYTE, &white);
>
> > +glTexImage2D(G
On Tuesday 03 June 2008 10:42:39 you wrote:
> Am Dienstag, 3. Juni 2008 10:02:26 schrieb Fabian Bieler:
> > The shader compiler can also do better optimization with hard-coded
> > constants (particularly if the constants are 0 or 1). I've seen the
> > nvidia-compile
On Monday 02 June 2008 12:04:54 Stefan Dösinger wrote:
> Am Montag, 2. Juni 2008 11:57:21 schrieb Ivan Gyurdiev:
> > The patch being reverted seems interesting - it basically undoes a prior
> > effort to get local constants into the same namespace as global ones due
> > to relative addressing. I as
On Thursday 22 March 2007 20:34, H. Verbeet wrote:
> On 22/03/07, Fabian Bieler <[EMAIL PROTECTED]> wrote:
> > +shader_addline(arg->buffer, "T%u%s /= T%u%s;\n", sampler_idx,
> > coord_mask, sampler_idx, coord_div_mask);
>
> Are you sure that's
On Friday 16 March 2007 08:40, H. Verbeet wrote:
> Did you check if the clamping is required?
Which clamping do you mean, the clamping in the vertexshader I removed or the
clamping in the fragmentshader I added?
The clamping I removed in the vertexshader is not required:
If we use opengl's fixed
I investigated the issue a bit further. Henri was right, the solution is much
simpler than I initially thought. :)
On Monday 12 March 2007 12:56, you wrote:
> Am Montag 12 März 2007 10:35 schrieb Fabian Bieler:
>
> With pixel Shaders < SM 3.0, the fixed function fog calculat
Hello!
I'd like to get fog working in conjunction with pixel shaders 2.0 or earlier.
The problem is that said shaders don't replace the fog stage in Direct3D.
Adding the necessary fog calculations to a GLSL fragment shader is trivial,
however, this results in a dependency of the shader on the cu
On Saturday 10 March 2007 23:20, Frank Richter wrote:
> On 10.03.2007 15:02, Fabian Bieler wrote:
> > +static const PixelFormatDesc NV_texture_shader_formats[] = {
> > +{WINED3DFMT_V8U8,0x0,0x0,0x0,0x0
> >,2 ,FALSE
> Am Samstag 10 März 2007 15:02 schrieb Fabian Bieler:
> > This Patch forces GL_CLAMP_TO_EDGE on all cubemaps.
> >
> > I tested this on XP with some Radeon X1???.
> >
> > Also, this fixes some renderissues Half-Life 2.
> Say, does that fix the strange q
> Am Samstag 10 März 2007 15:02 schrieb Fabian Bieler:
> > This patch implements D3DFMT_V8U8 and D3DFMT_Q8W8V8U8 via
> > NV_TEXTURE_SHADER. This fixes some renderissues in Half-Life 2 with the
> > DirectX9 path and the DirectX8 path via GLSL.
> What do those formats provi
Please ignore this patch.
On Tuesday 06 March 2007 05:02, Markus wrote:
> On Monday 05 March 2007 17:30, you wrote:
> > > I already updated the Wiki to reflect the settings I had to use under
> > > 10.2.
> >
> > -m32 is fully automatic detected in configure, it is not necessary to
> > mention.
>
> I cannot confirm this. Whe
On Saturday 24 February 2007 17:30, you wrote:
> Fabian Bieler wrote:
> > Windows silently ignores NULL pointers supplied to SendMessageCallback as
> > callback function.
>
> A testcase would be nice.
>
> Felix
The only way I know of to test this behavior would be
Hello!
In my last mail I confused a few message types. However, I think I know why
this bug occurs. Apparently windows silently ignores nullpointer callbacks
passed to SendMessageCallback (although it does deliver the message).
Fabian
Hello!
I tried to look into Bug 4791 (Civ4 crashes because of recent explorer/systray
changes http://bugs.winehq.org/show_bug.cgi?id=4791 ).
Pretty early during initialization (before the application creates any windows
itsself) a WM_FONTCHANGE message is broadcasted. The only window to which t
n ATI card
could test the patch. Alternatively, I attached a small test program which
just prints the amount of videoram to stdout and uses the same code as the
patch.
Fabian
From c1b2f368aa4580faef68cc0eaff0c5387e3eb8bf Mon Sep 17 00:00:00 2001
From: Fabian Bieler <[EMAIL PROTECTED]>
Date:
For me steam works if I use transgaming's mozcontrol with wine:
http://downloads.transgaming.com/mozilla_control_downloads/
(freely available under the MPL)
However it is somewhat unstable.
Fabian
On Tuesday 25 October 2005 01:19, Ivan Gyurdiev wrote:
> Roderick Colenbrander wrote:
> >> How is it
On Wednesday 19 October 2005 02:02, Fabian Bieler wrote:
> This patch removes window decorations in kde from windows which are not
> initially created with WS_POPUP style or similar but later altered via
> SetWindowLong.
>
> Examples for this are tooltips in wxwindows apps
On Sunday 16 October 2005 23:34, Fabian Bieler wrote:
> OK, here I go again:
> This is a small C program which should get the videoRam using the
> NV-CONTROL and ATIFGLEXTENSION extensions. As I only have a nVidia card,
> could someone with an ATI card (and the fglrx driver) plea
OK, here I go again:
This is a small C program which should get the videoRam using the NV-CONTROL
and ATIFGLEXTENSION extensions. As I only have a nVidia card, could someone
with an ATI card (and the fglrx driver) please test this?
Fabian
getvram.tar.gz
Description: application/tgz
On Sunday 16 October 2005 17:22, Oliver Stieber wrote:
> ATI and NVidia both have extensions to X that return the total video memory
> on the card, other options include using code from the DRI project, and
> I've got some very old dos code for some Matrox cards. Since there is no
> standard way to
On Sunday 16 October 2005 13:06, Stefan Dösinger wrote:
> Another update: The reason why the script is not working is the vendor
> string - it's "Gentoo (The X.Org Foundation 6.8.2, revision r4-0.1.10.2)"
> for me. Maybe a not so strict check against it would do it.
This should fix that problem.
Hello!
You can get the amount of videoRam from the x-server log (python script
attached). This is a little unsafe since the video driver is responsible for
logging this info and I don't know if my script works on the format of all
drivers. Also, certain drivers (fbdev) don't output this at all.
23 matches
Mail list logo
