This patch adds lots of download to the winehq download page. Sending only to
wine-devel for now, as I'm not sure they are all needed, but they could all be
useful in some situation or another. Comment welcome.
Ivan.
p.s. Maybe we should have a download page just for m$ components?
pat
> The link to the images is broken, it is winedows.gif when it should be
> windows.gif.
Yes, I've just noticed that.
Ivan.
simply have no hope of working with wine.
We may also want to list dcom, as we even had it up on the sf page at one time.
Ivan.
< And if a prog doesn't provide the dll it should have at least a readme to tell
people where to get it.
I can tell you out of experience that this isn't always true.
What about the attached patches?
Ivan.
lostwages.diff
Description: Binary data
wine.diff
Description: Binary data
Current CVS works for me.
Ivan.
le can download it free from m$ anyway.
But Alexandre doesn't like long links, and the link to the dcom95 download page
is just too long. It's
http://www.microsoft.com/downloads/details.aspx?familyid=d7a4de78-81a9-4db7-beb6-84ff99342172&displaylang=en
and we want to keep the error log short.
Ivan.
gt; and a $250,000 fine. Click here to exit the install
> program"
They can't do that, it would be an illegal violation of anti-trust laws. If they
could have done it, you probably couldn't run
office on crossover.
Ivan.
> So - do we still need it?
Can we use the registry (BTW then will winecfg be working?) to set up all the
stuff we can do in the config file?
Stuff such as winver, UseDGA, UseXVidMode, Managed or desktop more, and
DllOverrides? If we can, IMHO wineinstall can go.
Ivan.
ake[2]: *** [dde/server.o] Error 1
make[2]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls/user'
make[1]: *** [user] Error 2
make[1]: Leaving directory `/home/ivan/Development/Wine/CVS/wine/wine/dlls'
make: *** [dlls] Error 2
Ivan.
> this can be acquired at ...
That site is illegal, please avoid linking to such sites. Developers know where
to get native dlls.
Ivan.
o anyway.
> That suggests saving it for this purpose would be prudent.
Save it until we have a good reason to sped it. That reason could be wineconf,
or something else, in the mean time keep it in the bank.
Ivan.
about the
config will have to be re-written, as soon everything will be done with winecfg
of regedit, and as that will take a non trivial amount of time, it's a good idea
to start well in advance, so the docs aren't behind wine when the switch is done.
Ivan.
;s not a
configuration problem, so configure has been run and LD_LIBRARY_PATH is set
correctly. Apart from this, all this sort of stuff can be done in the build
system anyway. Also removing wineinstall is on the todo, and it does nothing
that can't be handled (more transparently) elsewhere.
Ivan.
d)? Sure, it may be possible to build one binary and run
it anywhere, but in most cases it wouldn't run as well (and as fast) as a build
done natively on the distro.
Ivan.
About building one binary of wine for all distros, it's interesting to notice
that one the same distro you need different binaries depending on if you're
using xfree86 or x.org.
Ivan.
nywhere, but in most cases it wouldn't run as well (and as fast) as a build
> done natively on the distro.
Actually, yes it is. Go read the docs on autopackage.org to find out
how.
> would be somewhat suboptimal as we sacrifice speed for flexibility and distro
neutrality.
Do we NEED to sacrifice such things? Also we can't use it until version 1.0, it
will be reasonable to look at this then.
Ivan.
> Maybe, but for example Mandrake users won't get wine listed in the "remove
> software" utility, and that will be confusing
> Solving that problem is a desktop issue, I've done a bit of work on it but
nothing has got into mainstream yet.
OK, but in the mean time I still don't see how one binary c
> Why is that?
I have no idea, but X11drv doesn't initialize properly. This has been reported
by users, I don't have x.org myself.
Ivan.
> Why is that?
Adam Schreiber may know as slackware he build 2 binaries for slack users using
xfree86 and x.org, you can reach him at shipssadam -at - clemson.edu
Ivan.
gure/make depend/make/make
install
Ivan.
Wine oss doesn't work with the via82cxxx_audio audio driver shipped in the linux
kernel, no other app has any problems, so I'm wondering if it's wine related.
What info is needed to debug this?
Ivan.
I haven't tested any non-directx software, anyway, both the winmm and dsound
tests give quite a few errors, the logs are attached. I can hear the test tones,
BTW the dsound one is much
louder than the winmm one for no obvious reason.
Ivan.
dsound.log.bz2
Description: BZip2 compressed
> Do you really think we need to switch from American to English spelling?
A common solution is to spell the same word in A.E. in some places and in B.E.
in others, and that's what my patch does. Apart fomr that, it's not only a
spelling patch.
Ivan.
> And they don't use the metric system. Shame.
The matric system is way more used in the UK than in the US, where it's hardly
used at all.
Ivan.
range because I tested both RPMs on multiple versions of Mandrake
before releasing them. Anyway, new RPMs will be up soon.
Ivan.
on my laptop wine just starts and doesn't do anything. In addition to this, ps
-A, ctrl+c, ctrl+z, the kde system guard and all tools that popup a box to
ask for root password all stop working. Attached is a relay log. Any ideas?
log.txt.bz2
Description: BZip2 compressed data
In the future please avoid having 22 winetest packages set to active, it doubles
the size of the sourceforge download page.
Ivan.
(short summary: why is emulation of Windows environment so difficult).
First of all, my apologies if this is an off-topic question for this list
but I hope it will be useful for others in the similar situation.
I need to port fairly large WinAPI-heavy application to Linux. After some
googling it
make sense to have a more formal
framework, where all instructions are tracked or maybe each backend
requests which instructions it is interested to track?
Ivan
H. Verbeet wrote:
On 09/04/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
1) The following pixel shader opcodes appear to be implemented with
fragment_ARB, yet they are marked REQUIRE_GLSL.
This generates errors, and they are skipped. Is this intentional?
D3DSIO_TEX (texld), D3DS
Why does wine write ARBfp2.0 into opengl shaders that originated from
DirectX2.0?
The shaders I'm seeing all use commands currently available to us [ no
branches or anything like that ], but are marked v2.0. As a result the
ARB extension fails on them every single time (invalid header -
ARBfp2.
I'm afraid this page changes too much at one go. You should split it into
separate pieces. For example:
I can break out some unrelated pieces of it as you point out, but once
we start moving code around it seems like all of it should be moved in
the right place, or the result wouldn't make
Goal: prevent wraparound of lines on 1024x768 resolution using
standard fonts
Hmm, if wrapping lines you must, then wrap them at the standard 80
characters, rather than some ill defined length (whose 'standard
fonts'? xemacs'? gedit's? eterm's (vi)? using which display dpi?).
80-characters
H. Verbeet wrote:
On 25/04/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
(2) write a NULL argument on no match.
This patch corrects those issues, and also changes GetContainer() for
surfaces and volumes to use the return value as MSDN specifies
(WINED3D_INVALIDCALL), not E_NOINTERF
H. Verbeet wrote:
On 28/04/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
Move Roderick's new function for obtaining the register code into
wined3d_private.h,
Personally, I would prefer to not move code into headers.
It can't be inlined otherwise.
H. Verbeet wrote:
On 29/04/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
+ DWORD major = D3DSHADER_VERSION_MAJOR(version);
+ DWORD minor = D3DSHADER_VERSION_MINOR(version);
It's probably a bad idea to add more dependencies on d3d8/d3d9 in
wined3d.
So what should be done instead?
Ivan Gyurdiev wrote:
H. Verbeet wrote:
On 29/04/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
+ DWORD major = D3DSHADER_VERSION_MAJOR(version);
+ DWORD minor = D3DSHADER_VERSION_MINOR(version);
It's probably a bad idea to add more dependencies on d3d8/d3d9 in
wined3d.
So
Subject: [PATCH 8/8] Add TRACE output of full shader strings for both pixel and
vertex shaders.
This makes it easier to read or copy & paste the shader string to make sure it
makes sense.
I think we should do the opposite, and get rid of the one that's already
there.
The shader output i
Jason Green wrote:
The following 8 patches apply to Mike's tree and accomplish the
following:
- Create a new function in baseshader named generate_base_shader()
which generates the bulk of the GL ARB shader string.
- Renames the GenerateProgramArbHW() in both ps & vs to
GenerateShader() and min
H. Verbeet wrote:
On 25/04/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
H. Verbeet wrote:
> On 25/04/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
>
>> (2) write a NULL argument on no match.
>>
>> This patch corrects those issues, and also changes GetContai
H. Verbeet wrote:
On 06/05/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
[ applies on top of Mike's tree, but hopefully on the main tree too ]
R8G8B8 means red is the most significant bit.
On a little-endian system, the texture is stored starting with blue.
It is read b
Stefan Dösinger wrote:
Am Sonntag, 7. Mai 2006 11:06 schrieb H. Verbeet:
There might be more to this. This was changed the other way around not
too long ago. See
http://source.winehq.org/git/?p=wine.git;a=commit;h=252c4adb965a26db19c1c91
61c40a82b488cb6d4
If I'm not mistaken, then this p
Andreas Mohr wrote:
Hi,
On Thu, May 04, 2006 at 06:36:48PM -0400, Ivan Gyurdiev wrote:
Also cleans up what looks like the result of a patch being applied twice
- same value is written to on consecutive lines.
You didn't mix up streamSource with streamStride, right?
Since I c
Paul Vriens wrote:
Hi,
don't know anything about wined3d, but the code in
IWineD3DVertexShaderImpl_ExecuteSW could make use of 6 parameters. The
definitions should cover this.
I don't think so... the case for 6 parameters should be removed.
I can't find 6-parameter instructions in the ins ta
Ivan Gyurdiev wrote:
Paul Vriens wrote:
Hi,
don't know anything about wined3d, but the code in
IWineD3DVertexShaderImpl_ExecuteSW could make use of 6 parameters. The
definitions should cover this.
I don't think so... the case for 6 parameters should be removed.
I can't f
Sound report:
Kernel 2.6.16-1.2196_FC6 (Fedora Rawhide)
Sound driver: snd_intel8x0,
Sound description from lspci:
00:04.0 Multimedia audio controller: nVidia Corporation CK804
AC'97 Audio Controller (rev a2)
64 bit Fedora Rawhide system (x86_64)
Alsa version 1.0.11-3.rc2.2
OSS run also had interruption problems.
It ran until: wave.c:657:Playing 1 second 440Hz tone at 8000x 8x2
WAVE_FORMAT_PCM_CALLBACK_THREAD|WAVE_FORMAT_DIRECT
...after which no sound was produced, and I killed the test,
since it seemed to have frozen.
I re-ran
+/* Create the uniforms (aka constants) */
+shader_addline(&buffer, "uniform vec4 C[%u];\n",
This->baseShader.limits.constant_float);
+/* TODO - Add varyings, attributes, etc. */
+
Shouldn't this go into the "generate_glsl_declarations" thing into
baseshader?
Things pr
Jason Green wrote:
This is a resend of the earlier patch, with one addition:
- previously, the line to alias the program.env[] to C[] was done in
the vertex shaders since that was the only function that needed them
(and it needs to be done to support relative addressing). However,
with PS 2.0+,
It is worth fixing although it should never occur, as ddraw will never call
GetBackBuffer(it manages them on it's own), and apparantly windows d3d8 and
d3d9 always create a back buffer, even if backbuffercount = 0 (This needs a
test case and a fix in d3d8 and
Look at the swapchains demo... it
diff --git a/dlls/wined3d/utils.c b/dlls/wined3d/utils.c
index 77b6b33..d15520b 100644
--- a/dlls/wined3d/utils.c
+++ b/dlls/wined3d/utils.c
@@ -1741,7 +1741,7 @@ GLenum D3DFmt2GLFmt(IWineD3DDeviceImpl*
/* color buffer */
case WINED3DFMT_R3G3B2: retVal = GL_RGB;
+/* Declare textures samplers */
+for(i = 0; i < /*This->baseShader.limits.texture */ 4; i++) {
+//if (reg_maps->texcoord & (1 << i))
+shader_addline(buffer,"uniform sampler2D mytex%lu;\n", i);
+}
What's the problem here?
+if (wined3d_settings.sha
+if (wined3d_settings.shader_mode == SHADER_GLSL)
+shader_glsl_add_instruction_modifiers(&hw_arg);
If you choose to pull modifier handling out of the per-opcode function,
this should be done for SHADER_ARB as well, imho.
All of the ARB modifiers are run p
Hi Raphael,
Strange, your email shows up as an attachment.
> +int i, cnt = min(count, MAX_VSHADER_CONSTANTS - (start
> + 1));
> should be:
> if (start > MAX_VSHADER_CONSTANTS - 1) return WINED3DERR_INVALIDCALL;
> UINT i, cnt = min(count, MAX_VSHADER_CONSTANTS - (start + 1));
> as count
Raphael wrote:
On Tuesday 06 June 2006 23:17, H. Verbeet wrote:
This is a test for Ivan's patch for shader constants
(http://source.winehq.org/git/?p=wine.git;a=commit;h=5f5969b3c5bd237277b8f2
f1eaa4ddacce5fb63b)
Changelog:
- Add a test for setting / getting vertex shader constants
+ * If a program for the given combination does not exist, create one, and store
+ * that data in both shader objects so we can delete all of the programs later.
+ * If it creates a program, it will link the given objects, too.
Is this comment still relevant?
- Fix relative addressing (it was
As of this patch, Wine now supports more opcodes in GLSL than
ARB_vp/fp and we can handle many of the shader 2.0+ instructions not
available before. There are a few missing texture operations compared
to ARB still, and we're not properly handling textures for any shaders
<2.0, but that's true i
> No i only see two problems, and made by use of xemacs
(as i have broken my kate install).
If vi was used this never would have happened :)
> PS: before many complains, my ISP webmail is buggy, sorry :)
If POP3 was used, this never would have happened :)
Seriously though - it's a major pain
229b4a0..80071ba 100644
--- a/dlls/d3d9/tests/vertexdeclaration.c
+++ b/dlls/d3d9/tests/vertexdeclaration.c
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2005 Henri Verbeet
+ * Copyright (C) 2006 Ivan Gyurdiev
*
* This library is free software; you can redistribute it and/or
* modify it under the terms of
Jason Green wrote:
- The LOOP register is an extended register and wasn't being checked
for in the current code. This moves the check up a level and checks
against the instruction code which is more efficient anyway.
It's important to also correct the reason why it wasn't being detected
where i
I've attached a patch which seems to fix the first set of failures.
This sets FVF values(from converted declarations) which were not set
before. I'm still getting a lot of 0 results myself. Pretty sure I
have everything enabled.
Comments?
- If the values really are supposed to be (almost)
H. Verbeet wrote:
On 17/06/06, Vitaly Budovski <[EMAIL PROTECTED]> wrote:
Comments?
A few points:
- Taking only the first element of the declaration into account
seems unlikely to be correct
- Is there a reason you're using pDeclaration9 instead of
pDeclarationWine? It would be usefull if dx8
Ivan Gyurdiev wrote:
H. Verbeet wrote:
On 17/06/06, Vitaly Budovski <[EMAIL PROTECTED]> wrote:
Comments?
A few points:
- Taking only the first element of the declaration into account
seems unlikely to be correct
- Is there a reason you're using pDeclaration9 instead of
pDeclarat
Stefan Dösinger wrote:
and those currently fail, because that case isn't handled at all in the
FVF loading code. It thinks this is a multi-stream case, when in fact
only the 0th stream is used. Jason Green has a demo -
dx9_hdr_texture_loader, which is broken exactly by this.
How about gettin
On 6/19/06, Jason Green <[EMAIL PROTECTED]> wrote:
- Fixes both ARB and GLSL shaders that use fog.Is it really necessary to keep track of whether the shader uses fog or not?What happens if you disable this post-processing for a shader that doesn't write to the fog register?
Also, how come the ARB
On 6/20/06, Jason Green <[EMAIL PROTECTED]> wrote:
- We are only checking against GL_MAX_TEXTURES when binding samplers,when we should be checking against the maximum number of samplers thatthe card supports. Spotted by H. Verbeet.Yes, I'm aware of that...it was done on purpose.
This limit is in a
On 6/21/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
This is a resend of the patch from a few days ago with some modificationsrequested by Alexandre:*getFormatDescEntry returns a pointer to a format structure, not an index inthe array* Removed the format counter
Stefan, can you clarify what happe
Hi,
Here's another problem with shaders.
Vertex shader input is marked up with tags that hint at the data usage -
semantics. For the fixed pipeline, those tags must be 100% correct,
because they tell the pipeline how to interpret the data - is that the
position stream, or the color stream, or
H. Verbeet wrote:
On 03/07/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
Demo #2: Many Per Pixel Lights,
http://www.zanir.szm.sk/dx/017_Many_Per_Pixel_Lights.zip
This is a d3d8 demo. The shader inputs are not marked with a semantic -
the declaration data is mapped 1:1 to the shader inputs
and I just made it work today,
by storing a fake semantic for d3d8 shaders.
By the way, I am still keeping that fake semantic around - it is useful
- it allows me to have a single code path for loading arrays, instead of
the two we currently have, which is a mess..
H. Verbeet wrote:
On 03/07/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
>>> and I just made it work today,
>>> by storing a fake semantic for d3d8 shaders.
By the way, I am still keeping that fake semantic around - it is useful
- it allows me to have a single code
H. Verbeet wrote:
On 03/07/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
> Well, it is wrong.
How is it wrong?
In one case you have a semantic, and you use that to load up the correct
register (query shader, shader gives you the index to load). In the
other case you preinitialize the
H. Verbeet wrote:
On 03/07/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
That's not particularly important.
Well, it breaks color fixups :-)
...color fixups will go in their own function that does this differently
for 8 vs 9
BOOL vshader_input_is_color(
IWineD3DVertexSh
H. Verbeet wrote:
On 04/07/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
There's something wrong with this patch... I'm not sure what it is yet,
The 0 program (fixed function) doesn't get set anymore when there are
no shaders.
The fixed function is a GLSL program?
H. Verbeet wrote:
On 04/07/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
Do not attach non-GLSL shaders to the GLSL program, that will cause a
crash. Mix with ARB shaders is never going to happen, because the
selection code will always choose GLSL for both or ARB for both.
As mentioned
H. Verbeet wrote:
On 04/07/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
- Store the shader selected mode into the shader itself. Different types
of shaders can be combined, so this is an improvement. In fact, storing
the mode into the settings globally is a mistake as well - it should b
To make it clear, this doesn't implement software shaders - it just
moves code around so when they're implemented it would be easier to do.
I already have one more or less working implementation, but it's based
on executing small functions for each opcode (like the previous code
does), except
Stefan Dösinger wrote:
WINED3DFMT_R8G8B8 means that the 8 most significant bits contain the red color
channel, and the 8 least significant ones the blue channel. But in memory the
least significant bits are at the highest address, so the surface ends up as
BGR in memory. This patch finally chan
Stefan Dösinger wrote:
And what about LockRect() ?
LockRect uses the formats from this table for glReadPixels, but UnlockRect
still has its own formats :-( . However render target locking still needs
some more work to catch nop locks and other stuff.
You're changing the format in one p
I am hoping someone (Stefan?) will help me with testing/review here,
because I don't have the apps and the disk space to test properly. This
changes things in drawStridedSlow, which is an important code path, so
correctness and performance matter (for non shader apps).
If there is no feedback
Stefan Dösinger wrote:
Am Dienstag 04 Juli 2006 11:17 schrieb Ivan Gyurdiev:
I am hoping someone (Stefan?) will help me with testing/review here,
because I don't have the apps and the disk space to test properly. This
changes things in drawStridedSlow, which is an important code pat
H. Verbeet wrote:
On 04/07/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
H. Verbeet wrote:
> On 04/07/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
>> There's something wrong with this patch... I'm not sure what it is
yet,
> The 0 program (fixed function) does
Speaking of the graphics page...
1. Is there a reason why we allow the user to choose software vs
hardware shaders?
(i.e. why isn't this a developers' option, or no option at all)
2. Is there a reason why we allow the user to disable vertex and/or
pixel shaders?
H. Verbeet wrote:
On 10/07/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
Also note that there's diffrent lifetime rules for immediate constants
in d3d8 and d3d9, and as far as I know we implement one of them wrong.
Here I stick with the current behavior, which I think is d3d9-complia
...but.. I shouldn't have to swap the two arguments in cmp, they are
correct as is, imho, and the previous implementation worked by accident.
In fact, swapping them will cause artifacts to appear in the Hair demo.
This patch is causing trouble for me. The current GLSL cmp
implementation is wrong - here's 4 reasons why, only the first of which
is mentioned in the source:
- it ignores destination write mask
- it ignores source swizzle
- it ignores other source modifiers.
- it works incorrectly src0 = 0
So
-shader_addline(arg->buffer, "%s.w = (%s.w > 0.0) ? %s.w : %s.w;\n",
dst_reg, src0_reg, src1_reg, src2_reg);
+shader_glsl_add_dst(arg->dst, dst_reg, dst_mask, tmpLine);
+shader_addline(arg->buffer, "%smix(vec4(%s), vec4(%s), vec4(lessThan(vec4(%s),
vec4(0.0)%s;\n",
+tmp
By all respect of all the hard work the developers make all day. But
to see the changes in 0.9.17 makes me really angry. Is everybody
developing for the gamers?
Actually I would say that the majority of developers are working on
features not directly related to games.
Whats the focus of the
;
diff --git a/dlls/d3d9/tests/stateblock.c b/dlls/d3d9/tests/stateblock.c
index 178edf5..4127918 100644
--- a/dlls/d3d9/tests/stateblock.c
+++ b/dlls/d3d9/tests/stateblock.c
@@ -1,5 +1,6 @@
/*
* Copyright (C) 2005 Henri Verbeet
+ * Copyright (C) 2006 Ivan Gyurdiev
*
* This library is free
Tony Lambregts wrote:
That would be me or Jeremy Newman
What do you want ;^)
I want a newer bugzilla where I can update my email? Please?
Otherwise it's going to start to bounce as soon as my university
realizes I'm not a student there anymore :)
+/* Make sure the fog value is positive - values above 1.0 are ignored
*/
+if (reg_maps->fog)
+shader_addline(&buffer, "MAX result.fogcoord, TMP_FOG, 0.0;\n");
+
What do you mean by "values above 1.0 are ignored" ? Why does the GLSL
implementation of this clamp
There were plenty of ways to fix this. One would have been to unroll
all of the memset/memcpy calls into functions that explicitly set
every value on the stateblock. While this might have been more
"correct", it would be harder to maintain.
I argue that an explicit initializer is always bette
Stefan Dösinger wrote:
Pre 2.0 pixel shaders do not contain a tag for the texture type to sample
from. Wine had 2D textures hardcoded, this patch checks the bound texture
type to decide from which texture to sample from. For >= 2.0 shaders the
shader tag is still used.
Why can't this be don
Also, maybe the stateblock should be passed as an argument to all
functions that use its states. I don't like walking up the tree to
find what you need (this->wineD3Ddevice) - it's a hidden dependency on
device state, which isn't even all the time - that's why you had to
move the point wher
Stefan Dösinger wrote:
Am Sonntag 27 August 2006 04:29 schrieb Ivan Gyurdiev:
Stefan Dösinger wrote:
Pre 2.0 pixel shaders do not contain a tag for the texture type to sample
from. Wine had 2D textures hardcoded, this patch checks the bound texture
type to decide from which texture to
Frank Richter wrote:
On 04.09.2006 07:33, Ivan Gyurdiev wrote:
... using:
GL_ARB_texture_float
GL_ARB_half_float_pixel
The internal format is RGB16/32F, which is wasteful (2 unused colors),
but there's no way around that.
What about INTENSITY or LUMINANCE textures
It seems
facts on the wall, but now most of the
demo's in shadow.
>From 98efb529e850dafb66c331afbc5168f90180650a Mon Sep 17 00:00:00 2001
From: Ivan Gyurdiev <[EMAIL PROTECTED]>
Date: Thu, 7 Sep 2006 07:17:00 -0400
Subject: [PATCH] Add support for offscreen rendering via FBOs.
This uses:
GL
H. Verbeet wrote:
On 08/09/06, Chris Robinson <[EMAIL PROTECTED]> wrote:
On Thursday 07 September 2006 23:50, Ivan Gyurdiev wrote:
> (3) Attempting to use GL_STENCIL_INDEX8_EXT in
glRenderbufferStorageEXT
> will fail on my hardware with GL_INVALID_OPERATION.
I've found tha
(2) Attempting to bind a framebuffer using GL_RGB32F_ARB, and
GL_RGBA32F_ARB formats will fail on my hardware (Nvidia GeForce
6800GS) with error GL_FRAMEBUFFER_UNSUPPORTED_EXT, which means the
format combination was invalid for implementation-dependent reasons.
However, this doesn't make se
State management in D3D... is currently kind of a mess.
Stefan D. posted a message about this some time ago, but I can't find it
right now...
- some states are applied immediately (via Set* calls)
- some are applied at draw time (like shaders, textures, transforms, ...)
- some are recorded into
1 - 100 of 790 matches
Mail list logo
