(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
ually looks a lot more like C#
"as" operator than Java.ToString().
That's basically a safe cast, which returns NULL if the object is not of
the type you're trying to cast.
...except that in C# it's a language operator that works on any pointer
type.
Ivan
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
> Henri Verbeet wrote:
This looks like data structure design mixed with GL and shader code. I
think it would be better if the data structure was in its own file,
without any GL or D3D dependencies, and wined3d and other components
could use it.
- Ivan
32 constants.
Ivan
Thanks Dmitry,
I'll update the patch (again) and resubmit it.
This is my first time submitting a patch to wine, so still getting
used with how things work ... thanks for the help and patience
everyone :)
ivan
2008/10/17 Dmitry Timoshkov <[EMAIL PROTECTED]>:
> "Ivan Peevski
> This isn't the prettiest way to merge those functions, but it's a start
Will you be cleaning this up further to get rid of the huge if-else ?
I think at least all the MOV-specific stuff should go in its own instr.
function.
Ivan
turn "vs_2_a";
> +}
Please re-check - the second condition is an assignment and always true.
- Ivan
t can be moved).
There should also be a comment explaining what this ARL block is doing, and why
(as part of "wined3d: Relative addressing offsets are limited to [-64; 63] in
arb.").
Ivan
Ivan Gyurdiev wrote:
> James Hawkins wrote:
>>> context.c - same except in this case its just a return with noting
>>> else..
>>> why do a goto why not just do the return?
>>>
>>
>> This is probably ok to change. I can only imagine that the origi
leanup needed at some later point.
>
The bigger question is why there is a huge if-else statement, and why
this function is so large.
Huge if-else statement = 2 sub-functions
Shader dirty constants - do shader internals really belong here ?
Ivan
ery convincing. "It will compile
several ms slower" is probably a better case to make, but at Init3D-time
we probably don't care how fast it is.
Ivan
ndle the case
where an extension would control replacing a group of states ?
2. Not necessarily relating to this patch, but in general I would be
wary of trying to replace every if check with a pointer. Splitting on
extension support is probably ok.
Ivan
> Zachary Goldberg wrote:
... but did not spell check :)
Granted, the movie quote is pretty funny, even if isn't spelled right.
Ivan
В сообщении от Friday 04 July 2008 19:23:32 вы написали:
> Ivan Sinitsin wrote:
> > Changelog:
> > mshtml.dll:Add implementation of HTMLDocument_(Get|Set)Title
>
> First of all it would be nice if you could add a test case for these.
>
Hi,
I make test for HTMLDocument
V extension, since now you have two pipeline
replacements to test if the framework is sufficient or not.
Ivan
Ivan Gyurdiev wrote:
> Michael Karcher wrote:
>> Does anyone knows whether the test has this been written buggy on
>> purpose (some app does this), or it is by accident?
>>
>>
> Probably the first one - I wrote the test with rather limited
> understanding of
re was a specific application need driving this test.
The intention was to test how the stateblock behaves under different
event sequences - for example if the rendertarget is changed.
I see the test is doing its job uncovering interesting behavior :)
Ivan
namespace as global ones due
to relative addressing. I assume this is done for performance reasons,
is this correct ? I see your patch is special-case disabled in the case
of relative addressing. Do we really want to support multiple constant
loading code paths for performance savings ?
Ivan
ectations with a rather low percentage
number just means a lot of people won't even bother trying.
Ivan
ht be full of bugs,
but you don't point this out in your release announcement ).
Ivan
Hello, I have a question.
I make a patch, that fix problem with open html document in new window. I
tested it on "MyIE 2" and it works. But I am not assured, whether it is
possible to solve a problem in this way.
What do you think about it?
--
Sinitsin Ivan
Index: dlls/shdocvw/
omponents are more easy to
manage - specifically in your case this should allow separate backends
to be chosen per pipeline stage.
It seems reasonable that these changes would be deferred until after 1.0.
Ivan
ater as we try to add new features using a
particular extension, and we'll see a lot of functions that are just
empty forwards to other "shader backends", since they don't support
something themselves.
Ivan
> Name=Wine Windows Emulator
I like the expanded version better:
"Wine is not an emulator windows emulator".
Should help clear up any questions people might have :)
glsl pixel shader (you could use a different linker for other things).
Why is the vertex/pixel linkage related to how you generated the vertex
(or pixel) shader ? Does it matter if your shader was created from the
fixed or programmable interface on the d3d-side in order to link it to
the other one?
How will geometry shaders fit into the picture ?
Ivan
7;s written now scales to GL3, D3D10,
geometry shaders, and upcoming extensions. In that respect, it seems
like a good idea to try an ATIfs backend now as a test of the underlying
framework.
Ivan
Stefan Dösinger wrote:
>> I'll get back to you on that later tonight, need to think about this
>> some more - way late for work right now... (thanks to you!)
>>
>> However, yes, I think there needs to be distinction between a standalone
>> shader concept, and a pipeline concept, which is concerned
Stefan Dösinger wrote:
> Am Mittwoch, 19. März 2008 07:46:07 schrieb Ivan Gyurdiev:
>
>> Why do you need to reroute the shader path through atifs to support an
>> unrelated set of functionality (ffp replacement)? Isn't it possible to
>> have an ffp_backend, and a
t one based on what flags are set.
Why do you need to reroute the shader path through atifs to support an
unrelated set of functionality (ffp replacement)? Isn't it possible to
have an ffp_backend, and a shader_backend (shader being the d3d shader),
and you can implement both differently, with different APIs?
Ivan
Stefan Dösinger wrote:
> Am Sonntag, 16. März 2008 15:00:49 schrieb Ivan Gyurdiev:
>
>> I don't quite understand why it's necessary to write ARB, GLSL, and NONE
>> shader descriptors inside the ati_shader file.
>> How will this infrastructure scale to a new s
t explains how it works ?
I very much like that backend-specific functionality ends up in the
appropriate backend - as per patches 10, 11, and 14.
However, it seems those patches stand on their own, independent of the
rest of the patchset and this feature.
Ivan
1.0, 1.1, 2.0, 2.1, 3.0 ]
, [ ps: 1.0, 1.1, 1.2, 1.3, 1.4, 2.0, 2.1, 3.0 ] , NULL, and an invalid
token.
You can see some binary shaders in the d3d9 tests.
Ivan
#x27;s already in the user's files -
saved passwords, crypto keys, personal data, financial files. The root stuff is
not interesting at all, except as a means to get to the user's files.
- Ivan
comment to your patch, this implementation is wrong.
>
I do not speak, that my patch better than yours or my patch is right. I only
want to understand, why so occurs and where to look?
>
> Jacek
--
Sinitsin Ivan
On Monday the patch realizing this function has been accepted. It works
perfectly, but hyperlinks do not work.
If I makes this function that way:
static HRESULT WINAPI HTMLDocument_write(IHTMLDocument2 *iface, SAFEARRAY
*psarray)
{
HRESULT hres;
VARIANT *pvar;
IHTMLElement *pbody;
re lots of bugfixes...
Ivan
>");
write_name(header, def);
fprintf(header, "(p");
p=0;
for (c=0; clpVtbl->");
write_name(header, def);
fprintf(header,"(");
fprintf(header,"%s",str);
fprintf(header, ")\n");
What do you think about that?
Sinitsin Ivan
В сообщении от Thursday 20 December 2007 15:28:32 вы написали:
> "Ivan Sinitsin" <[EMAIL PROTECTED]> wrote:
> > + if( RegQueryValueExW( hKey, reg_logfont, NULL, &type,
> > + (LPBYTE) &logfont, &size ) !=
> > ERROR_SUC
the "object oriented programmer" - I would hope every programmer
thinks in terms of objects, even when writing C code.
The GLSL backend wouldn't be available today if the shader compiler was
still a big series of if statements.
Ivan
Any chance the formatting can be improved to include whitespace between
blocks and proper indentation?
> +if (use_vs(stateblock->wineD3DDevice) &&
> stateblock->wineD3DDevice->vs_selected_mode == SHADER_ARB)
GLSL specific logic should go in glsl_shader.c.
Please try to get away from writing code in terms of flags and if
statements - use the OOP model.
Backend-specific logic should be remove
Stefan Dösinger wrote:
> Am Donnerstag, 27. September 2007 02:57:01 schrieb Ivan Gyurdiev:
>
>> Aren't most of these 2.0 and 3.0 instructions ?
>> What's the goal of adding them to ARB - you won't be able to implement
>> full 2.0/3.0 support in ARB.
>&
Aren't most of these 2.0 and 3.0 instructions ?
What's the goal of adding them to ARB - you won't be able to implement
full 2.0/3.0 support in ARB.
I think most of these were left unimplemented on purpose.
Ivan
В сообщении от Thursday 30 August 2007 12:44:15 вы написали:
> Sorry, but purpose of your patch is unclear to me. In your changelog
> field
> you tell that "This patch does a font for the menu, statusbar and messages
> dependent from logpixels" but as far as I know WINE already have correct
Stefan Dösinger wrote:
Up to now we've been lucky that all the games requireing manual fog coords
haven't used vertex buffers, thus we always went through drawStridedSlow.
Make sure that the fog also works with vertexbuffers
As for the rejected patches from yesterday, I've moved them back to t
H. Verbeet wrote:
On 18/08/07, Roderick Colenbrander <[EMAIL PROTECTED]> wrote:
From what I have seen GL3 is very different. It would be like maintaining a
GTK and a QT backend in one library. They use very different calls
(glBegin/glEnable and so are gone), need different WGL contexts and so
Stefan Dösinger wrote:
There are other things too which could be moved, but I'm not sure if that
would make the code more readable. One big function which does things step by
step vs a few smaller functions which disturbs the readflow.
All of this code pasted 3 times could probably benefit
What Stefan says about discussing patches
is true--it helps if there's not a lot of debate around a patch.
This quote should go down in the history of open source :)
I hope the word you're looking for is "controversy".
nly modifying the first 16 will break: normal2, tangent, binormal,
tessFactor, fog, depth, sample in the fixed pipeline case (true, I don't
see these being used anywhere right now ...).
Please leave writing of the strided data to the functions designed for
this purpose.
Ivan
laration.c to list that
person if it isn't done already. I was just curious...
Ivan
Stefan Dösinger wrote:
Honestly I do not really agree with getter methods like this inside WineD3D.
Yes, they do hide the implementation details, namely how the flag is stored.
Yes, they do encapsulate data, like the Object Oriented Programming model
says. But honestly, how much use is it to do
Here is how this was meant to work at some point [ since I see all kinds
of incorrect things being done ]:
Entry point Code generation
==
Pixelshader Baseshader --- ARB backend
Vertexshader ---
directly - there should be a function which looks inside the
reg_maps, and code from other file should call that function (we are
emulating OOP programming in C, so we should try to use encapsulation).
Ivan
tween sequential Get() calls ?
Did you mention something about a driver bug causing this ?
Ivan
Vit Hrachovy wrote:
Hi,
according to thread 'WineCfg and DirectX options' at wine-devel,
That thread was heading in the wrong direction...
I'm
proposing a patch for winecfg to allow enabling/disabling usage of GLSL
for Direct3D applications rendering.
Do you want to make it easy to configure
From b1df18be85d1ca6a9904be05420f975f6933b030 Mon Sep 17 00:00:00 2001
From: Stefan Doesinger <[EMAIL PROTECTED]>
Date: Fri, 23 Mar 2007 19:03:58 +0100
Subject: [PATCH] WineD3D: Handle WINED3DSPSM_DZ and WINED3DSPSM_DW in texcrd in
arb shaders
Isn't there a function to handle modifiers?
"ge
Stefan Dösinger wrote:
Hi,
implementing GLSL checkbox, OffScreenRenderingMode dropdown menu and
VideoMemorySize textbox into winecfg would be easy.
GLSL is OK IMO, because some drivers(*cough* macos *cough*) have serious
problems with glsl. It could be included into the shader dropdown box.
Why should "inline static" be replaced with "static inline".
Does it improve compatibility with certain compilers?
Also, does wine aim to be compliant with ANSI, C99, or somewhere in
between (-gnu89)?
Stefan Dösinger wrote:
Am Samstag 10 März 2007 19:39 schrieb Ivan Gyurdiev:
Opinions? Suggestions?
Sounds too easy...if it included something like "HLSL compiler", that
would be another story.
Also, you have to have a well-defined project to set completion criteria.
&qu
Opinions? Suggestions?
Sounds too easy...if it included something like "HLSL compiler", that
would be another story.
Also, you have to have a well-defined project to set completion criteria.
"starting the infrastructure" does not define when the project is complete.
This time cube texture support is added. Hopefully the coords are right, I had
no test app for them. If not it should be easy to spot the very
characteristic flipping of the image.
I'm confused - you replaced a patch which had no support for cube maps,
with one that has untested support for
Kevin Wallerbos wrote:
This formatting patch cleans up the spacing in the pixel/vertexshader
instruction table, making it somewhat nicer on the eyes. The lines
have become a bit longer than practical on standard resolutions, but
that shouldn't be a problem as most lines were already too long.
A b
On 3/9/07, Huw Davies <[EMAIL PROTECTED]> wrote:
On Thu, Mar 08, 2007 at 10:50:30PM -0800, Dan Kegel wrote:
> An increasing number of apps need gdiplus.dll.
> Seems like it's time for Wine to include it.
Yes, absolutely.
> Since Mono has implemented much of gdiplus already
> ( http://www.mono-p
So what would be the overall of the project?
I'm interested in participating in this Google SoC, so this project
sound interesting to me for this SoC 2007.
Regards,
Ivan
On 3/9/07, Dan Kegel <[EMAIL PROTECTED]> wrote:
An increasing number of apps need gdiplus.dll.
Seems like it
verything? Am I right?
About the drawing code, I read that is possible to use the X11 code,
also the ReactOS code and the old Transgaming DIBEngine (incomplete).
Is that correct?
Waiting for your comments and ideas.
Regards,
Ivan
Changelog:
- The texldl instruction takes 3 arguments
Can the SW shader handlers be deleted now that the rest of the SW code
is gone.
They just get out of sync when you do things like this.
Something's wrong with this patch: it has more 2 nested if statements.
I suggest early returns on negated condition, gotos, and subroutines to
fix the problem :)
I don't know if that patch wasn't applied because other patches of my patchset
weren't applied, or because something is wrong with t
are This against convertedDecl
from the device in IDirect3DVertexDeclaration9Impl_Release, rather
than adding a convertedDecl flag to IDirect3DVertexDeclaration9Impl
and setting / unsetting it? I think it makes things harder than it has
to be. Also, afaik Ivan has some tests for the exact behavi
declaration.
Excellent.
I don't know if the implementation works, but the idea is certainly on
the right track. This was done incorrectly to begin with, and also made
it difficult to remove the dependency on d3d8/d3d9 includes (which I see
you're on track to complete).
Ivan
В сообщении от 1 февраля 2007 07:00 Dmitry Timoshkov написал(a):
> "Ivan Sinitsin" <[EMAIL PROTECTED]> wrote:
> > The patch corrects background color of a dialogue window " Choose color "
> > at copying a triangular marker, the user colors and the predete
Stefan Dösinger wrote:
This call can be handled fully by IWineD3DSurface::Blt.
So where did the filter argument go.. there's 3 different filter types
to support.
Here's a demo that breaks FBOs: http://www.humus.ca/3D/Water.zip
Also download: http://www.humus.ca/3D/Framework2.zip
You'll notice all the glClear calls fail [ or at least a lot of them ].
That's because the framebuffer is incomplete at that point -
checkFBOstatus() should be called before gl
Stefan Dösinger wrote:
Am Samstag 06 Januar 2007 22:25 schrieb Ivan Gyurdiev:
Stefan Dösinger wrote:
Now that almost everything is gone from drawPrimitiveDrawStrided we don't
need a subfunction for calling drawStridedSlow/Fast any longer
I think while we're cleaning
Stefan Dösinger wrote:
Now that almost everything is gone from drawPrimitiveDrawStrided we don't need
a subfunction for calling drawStridedSlow/Fast any longer
I think while we're cleaning up things, all of software shaders should
be removed.
There's tons of code in drawprim and *shader.c
Stefan Dösinger wrote:
Now that the decoded vertex declaration is put into the device with
baseVertexIndex = 0, vertex buffers can just memcpy it instead of decoding it
Here's an issue I see - isn't introduced by your patch, but I am just
confused.
In the vertex buffer code:
if(device->
Stefan Dösinger wrote:
I removed that call accidentally in one of my former patches, but I
think it is still a good idea to trace the final strided sources used
by drawprim
You removed it from a d3d8 fixed function FVF-only codepath, and are
adding it back into a shared codepath.
That functio
Jan Zerebecki wrote:
On Tue, Jan 02, 2007 at 07:00:20PM -0800, Dan Kegel wrote:
I'd like to change this to make it clear that cracks are a no-no for
anything Silver and above, and make Platinum and Gold rather
more rigorous:
I don't think that is helpful. What is more important:
to kn
Regarding the concern of storing the decoded strided data after
finishing drawing: This is intentional, the decoded vertex declaration
will remain valid after the draw is finished and the arrays loaded.
Future draws can use it, if the state is not dirtified again.
This sounds like a good id
Louis. Lenders wrote:
Hi, is there anything wrong with this patch? If so, could you please
tell me what. Thx
*/"Louis. Lenders" <[EMAIL PROTECTED]>/* wrote:
Hi, this patch should fix failing tests in d3d9, like you see for
example here:
http://test.winehq.org/data/200612231000/
+if (stateblock->wineD3DDevice->vs_selected_mode != SHADER_NONE && stateblock->vertexShader &&
+ ((IWineD3DVertexShaderImpl *)stateblock->vertexShader)->baseShader.function != NULL)
+memcpy(&stateblock->wineD3DDevice->strided_streams,
stateblock->wineD3DDevice->up_strided,
s
H. Verbeet wrote:
On 20/12/06, H. Verbeet <[EMAIL PROTECTED]> wrote:
This time as part of the device.c test.
Changelog:
- Add a render target test
Use the attached patch instead, the previous version doesn't apply.
This test really belongs in stateblock.c, along with every other set
<--> g
> - Mixing ARB and GLSL backends is pretty silly as well.
Why? I believe you can e.g. perfectly mix GLSL vertex programs together
with multitexturing setups.
ARB as in ARB_vertex_program or ARB_fragment_program, I'm not sure
what multitexturing has to do with it. You can't, for example,
proper
H. Verbeet wrote:
On 27/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
H. Verbeet wrote:
> There are a couple of instructions that have to sample from a texture,
> right now most of them duplicate that code, and hardcode the texture
> type.
>
> Changelog:
> - Create
- Software shaders currently simply don't work. If we do get software
shaders it'll likely be vertex only.
So, we should allow hardware pixel shaders, and software vertex shaders.
I could see
someone using software vertex shaders if he's got no hardware support
for shaders, although it's ques
H. Verbeet wrote:
There are a couple of instructions that have to sample from a texture,
right now most of them duplicate that code, and hardcode the texture
type.
Changelog:
- Create a separate function for sampling a texture
You should continue to use "add_param" or "get_register_name". There
H. Verbeet wrote:
Changelog:
- Select the right shader backend when creating the device
Imho there should be either ps_selected/vs_selected flags, or
shader_backend flag, but definitely not both [ does not make sense ].
I'd opt for allowing different backends on pshader vs vshader. Maybe the
That's still missing runtime check for GL_ARB_DEPTH_TEXTURE extension. I
don't like "developers only" and "registry key" - feature should be
complete or not in the tree.
> The trouble with the current setup is that we can't use different
formats based on what extensions
are present.
Then the
H. Verbeet wrote:
On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
H. Verbeet wrote:
> On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
>> This flag needs to be per adapter - should be added to device.c
like the
>> shader mode.
>>
> Well, the regi
H. Verbeet wrote:
On 17/11/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
This flag needs to be per adapter - should be added to device.c like the
shader mode.
Well, the registry setting is global. I'm not sure if it really makes
sense to use different offscreen rendering modes fo
Ivan Gyurdiev wrote:
This flag needs to be per adapter - should be added to device.c like
the shader mode.
I meant the device structure.
Also, the mode selection should include configuration and support
detection - I think you're missing the support detection. Imho there
should
H. Verbeet wrote:
Two things to note here:
- We use GL_DEPTH_COMPONENT24_ARB as internal format for 16-bit
depth textures. This is needed because GL_DEPTH_COMPONENT16_ARB
doesn't work with FBOs.
- We don't properly support combined depth and stencil buffer
formats yet. To support this properly
This flag needs to be per adapter - should be added to device.c like the
shader mode.
Mirek wrote:
Ok, i just found why is it not working with this patch, and why is it
working without this patch. It is based on position of definition MOVA
in vertexshader.c, if MOVA is on "after patch" position it is not
working, but if i move line "
{WINED3DSIO_MOVA, "mova", NULL, 1, 2, vshader_
Ivan Gyurdiev wrote:
Here is log with 3DMark running for about 3 seconds with patch and
without, trace+d3d.
http://www.czela.net/pub/Czela_Debian_2.5/mirek/wine/regression/3DMark03.tar.gz
There's no mova instruction in that log.
...grep for mova, or for "unrecognized" o
Here is log with 3DMark running for about 3 seconds with patch and
without, trace+d3d.
http://www.czela.net/pub/Czela_Debian_2.5/mirek/wine/regression/3DMark03.tar.gz
There's no mova instruction in that log.
Tom Wickline wrote:
I see the same thing as Mirek, 3dmark03 is totally broken now.
And yes I tested GLSL and ARB and before and after with the same
results as his.
So yes, this is a major regression :D
When testing with the GLSL backend, can you please do a +d3d_shader
trace, find the MOVA
Mirek wrote:
I tried it three times with same result. Can someone else test if
3DMark 2003 is working with latest wine?
You shouldn't test if it's working now - test if it's working before the
MOVA patch, and if it's not working after the MOVA patch [ no other
patches in between ].
The MOVA instruction is a 2.0 instruction, which cannot be fully
implemented in ARB.
However, the patch shouldn't have caused a regression - if you're seeing
a black screen with GLSL also, that means another patch is responsible
for this.
Can you describe what this would look like in detail
I haven't thought it through in detail - just making sure you have. I
think you're going in the right direction, as long as considering things
other than render states in the design - won't bother you anymore, until
I see some more of th
1 - 100 of 790 matches
Mail list logo
