James Hawkins wrote:
static const WCHAR create_fmt[] = {'C','R','E','A','T','E','
','T','A','B','L','E',' ','`','%','s','`',' ','(',' ',0};
-size = sizeof(create_fmt) + lstrlenW(table) - 2;
+size = lstrlenW(create_fmt) + lstrlenW(table) - 1;
Since the string is const, and we
Matthew Kehrer wrote:
Is there a way I can convert a source tarball I download to a local GIT
repository?
Not really.
I have dial-up a home, but I know of a place where I can bring my flash
drive and use it to get the tarball as GIT does not have resume support.
Is this possible?
It a 20
On Thursday, October 19, 2006 17:04, Matthew Kehrer wrote:
> Is there a way I can convert a source tarball I download to a local GIT
> repository?
>
> I have dial-up a home, but I know of a place where I can bring my flash
> drive and use it to get the tarball as GIT does not have resume support.
>
Dmitry Timoshkov wrote:
> "Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
>
>> Please don't. Kernel32 is the source of all core functionality. As well
>> as winex11drv, user32 and gdi32. No this will generate more broken bug
>> reports.
>
> We are using this internally in Crossover already for 3 ye
More?
What are your plans for dealing with these:
=
SetLight()
SetLightEnable()
SetTexture()
SetDepthStencilBuffer()
SetRenderTarget()
SetSomethingElseThatsNotARenderState().
Is there a way I can convert a source tarball I download to a local GIT repository?I have dial-up a home, but I know of a place where I can bring my flash drive and use it to get the tarball as GIT does not have resume support.
Is this possible?Thanks.
Well, the number of sampler stages (and thus the number of sampler
stage states) for example is dependant on hardware limits, so you
can't really use the "#define STATE_SAMPLER(b, a)
STATE_RENDER(WINEHIGHEST_RENDER_STATE +
WINEHIGHEST_SAMPLER_STATE * b + a)" macro since
WINEHIGHEST_SAMPLER_STATE w
Hi,
Well, I'm not so familiar with detailed licencing stuff, sorry
for not noticing.
However, I've worked alot on mp3 codec a few years ago to make
my own assembly codec (sorry, not x86) and after comparing many
different sources, all I can say is that there aren't so many
ways to decode the strea
Am Donnerstag 19 Oktober 2006 12:08 schrieb Stefan Dösinger:
> Hi,
> I considererd that it would be finally time to get started with the state
> management rewrite :-) Just a mail with the final plan, if anyone has
> comments.
Well, I started with the thing, and I want to show the first results so
I thought at first you just diff:ed the file against mplayer's code
however, as mplayer's uses the old mpglib code, one could also ask
mplayer's team to release the diffs they made to mpglib as LGPL (which
they have to...)
They don't have to (although it would certainly be kind of them to do
so,
Am Donnerstag 19 Oktober 2006 02:46 schrieb Robert Lunnon:
> I'm still trying to work this out, see below, but I have a silly question,
> how *should* IWineGDISurfaceImpl_Blt behave if args 2 & 3 are NULL IE
> DestRect and SrcSurface are both NULL. Is this a no-op ?
No, look at the DDBLTFX struct
Deun wrote:
Hi,
Well, I'm not so familiar with detailed licencing stuff, sorry
for not noticing.
However, I've worked alot on mp3 codec a few years ago to make
my own assembly codec (sorry, not x86) and after comparing many
different sources, all I can say is that there aren't so many
ways to d
the test could force the user backend (see the console test in
kernel32 directory)
I see - I haven't noticed that --use-event automatically chooses the
user backend.
Mikolaj Zalewski
Mikołaj Zalewski wrote:
but your code doesn't release the selection on button up, which is
rather strange when you do only mouse selection
A+
I've checked it and currently the whole section is dead code as on
WM_LBUTTONUP the (wParam&MK_LBUTTON) is always false.
However if I remove this
Alex Villacís Lasso <[EMAIL PROTECTED]> writes:
> So, when metafiles are involved, this sequence of calls triggers the
> debug assertion in CreateCompatibleDC(). Since I don't really see the
> point of having the assertion in CreateCompatibleDC(), I was planning
> to send a patch to simply remove
Vitaliy Margolen escribió:
Alex Villacís Lasso wrote:
I would like to draw attention to bug #6439
Why that bug in particular? Can we pick any other?
Yes, you can:
http://bugs.winehq.org/buglist.cgi?query_format=&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&l
On Fri, Oct 20, 2006 at 12:07:14AM +0900, Dmitry Timoshkov wrote:
> "Huw Davies" <[EMAIL PROTECTED]> wrote:
>
> >case WM_COMMAND:
> >switch(LOWORD(wp))
> >{
> >case IDOK:
> >case IDCANCEL:
> >+if(wp == IDOK)
> >+update_structure(hdlg,
"Vitaliy Margolen" <[EMAIL PROTECTED]> wrote:
Please don't. Kernel32 is the source of all core functionality. As well
as winex11drv, user32 and gdi32. No this will generate more broken bug
reports.
We are using this internally in Crossover already for 3 years and, mind
you, it's very helpful.
Francois Gouget wrote:
On Thu, 19 Oct 2006, Robert Shearman wrote:
[...]
Actually, in the PSDK there seems to be a correlation between
COM_NO_WINDOWS_H and idl files. It's not 100% but that may be just be
because they don't ship all the idl files. Also, the COM_NO_WINDOWS_H #ifdef
is not pres
"Huw Davies" <[EMAIL PROTECTED]> wrote:
case WM_COMMAND:
switch(LOWORD(wp))
{
case IDOK:
case IDCANCEL:
+if(wp == IDOK)
+update_structure(hdlg, ps_struct);
EndDialog(hdlg, wp);
+free_structure(ps_struct);
On Thu, 19 Oct 2006, Robert Shearman wrote:
[...]
> > Actually, in the PSDK there seems to be a correlation between
> > COM_NO_WINDOWS_H and idl files. It's not 100% but that may be just be
> > because they don't ship all the idl files. Also, the COM_NO_WINDOWS_H #ifdef
> > is not present in the id
Am Donnerstag 19 Oktober 2006 13:35 schrieb Ivan Gyurdiev:
> > States will be applied in drawprim.
>
> It will be good if *all* texture-related states were applied in
> drawprim, specifically. This is a prerequisite to VTF support, since
> that involves repacking pixel and vertex textures into a si
Dmitry Timoshkov wrote:
> Hello,
>
> please use this version intead of the previous one.
>
> Changelog:
> Update RelayExclude and add RelayFromExclude filter in order to avoid not
> useful APIs in the traces, and greatly reduce the size of the relay logs.
>
> --- cvs/hq/wine/tools/wine.i
Oleg Krylov <[EMAIL PROTECTED]> writes:
> Toolbar tooltips can sometimes steal focus from application window (I
> think it's window manager issue, I experience it on
> Metacity). Creating tooltip control with WS_POPUP style prevents
> it. Native toolbar control uses same style for toolbar tooltips
"Karsten Elfenbein" <[EMAIL PROTECTED]> writes:
> @@ -175,6 +175,17 @@ static HRESULT WINAPI IWineD3DSwapChainI
> /* DDBLT_KEYSRC will cause BltOverride to enable the alpha test with
> GL_NOTEQUAL, 0.0,
> * which is exactly what we want :-)
> */
> +if (This->p
Mikołaj Zalewski <[EMAIL PROTECTED]> writes:
> @@ -274,11 +274,17 @@ VOID PROGRAM_ExecuteProgram(HLOCAL hProg
>LPSTR lpszCmdLine = LocalLock(program->hCmdLine);
>LPSTR lpszWorkDir = LocalLock(program->hWorkDir);
>
> - /* FIXME set working directory */
> - lpszWorkDir = lpszWorkDir;
> +
States will be applied in drawprim.
It will be good if *all* texture-related states were applied in
drawprim, specifically. This is a prerequisite to VTF support, since
that involves repacking pixel and vertex textures into a single array,
and changing their indices [ should happen at drawpri
States will be applied in drawprim. BltOverride and UnlockRect change states
on their own, and they can put the states the change onto the dirty list so
drawprim will reset them to what the application wants.
What about Clear()?
Maybe you should also provide the capability of applying a single
> Not sure about the _utils part there, since it's pretty much core
> functionality, but fair enough.
well, we can use other names too :-) opengl_state.c, opengl_AllOtherStuff.c
> > vertex type) will share the same list. The index of the changed state
> > will identify the type of the state, e.g.
On 19/10/06, Stefan Dösinger <[EMAIL PROTECTED]> wrote:
I will move the functions applying the states into a new file,
opengl_utils.c(name inspired by old ddraw). I don't want to put them into
drawprim.c because that file is already quite long.
Not sure about the _utils part there, since it's pr
Hi,
I considererd that it would be finally time to get started with the state
management rewrite :-) Just a mail with the final plan, if anyone has
comments.
I will move the functions applying the states into a new file,
opengl_utils.c(name inspired by old ddraw). I don't want to put them into
At 19:09 18.10.2006 -0600, you wrote:
>Alex Villacís Lasso wrote:
>> I would like to draw attention to bug #6439
>Why that bug in particular? Can we pick any other? You seems to really
>like to copy list of all of your bugs. Hell that's turn this list into
>another Bugzilla!
>
>You know, I wanted
Am Donnerstag 19 Oktober 2006 00:44 schrieb Karsten Elfenbein:
> This change for the non scaled BltOverride should allow correct usage of
> src and dest rect. So the content ends up where it is supposed to be.
> It is needed for a correct Frontbuffer capture while running in a
> window. (next mail)
33 matches
Mail list logo
