wine-devel June 2003

wine-devel@winehq.org

123 participants
259 discussions

Re: Re: Re: Re: Submits galore
by fenix＠club-internet.fr 06 Jun '03

06 Jun '03

>Well, I would only use 1.2 defines from the GL headers. All the >rest would be prefixed or suffixed by _WINE so no risk of >conflicts. original way to solve the problem, but as openGL1.2 is really a few things you can redefine all openGL. (and i think it will be better readable and workable than mixing GL_*_WINE and GL_*) And if you do that (no more official gl.h include) you shouldn't have anymore problem that you have used some GL_* only defined in you official gl.h but not openGL1.2 compliant >So even if the headers are ugly, I do not see how it could break >things. Yes, you are right, but i prefer code readable :) >> i think you'll have many breakage :) > >Well, if I do the following, I wonder how I could have breakages >:-) : > >#define GL_COMBINE_RGB_WINE 0x8571 > >I.e. I do not plan to use ANY pre-defined values from the header >but to define them all myself. > >So tell me where I could have breakage ? so do it, i'll reuse it for d3d8 :) but do it for official OpenGL1.2 defines too (as i have commented before) >> As you want, >> But for me, I think building with GL1.4 (last ans most complete) >> headers and detecting/activing caps on runtime it's a more proper >> solution (no more #ifdef/#define in code, only in d3dcore_gl.h >> definitions). > >I cannot see how you can do this without shipping all the GL / >GLX 1.4 headers with Wine itself. As we used only a few parts of OpenGL1.4/GLX1.3 (and you a smaller one) we can only define in a "small" header what we need for what we used (i find it the more proper solution) First, i have thought that shipping official openGL headers into wine was the better solution (for opengl dll and d3d*). But as they should be installed into <wineinstalldir>/include/wine now i think its better to only have a small header only for compilation. >If you plan to redefine stuff, this is exactly what I planned to >do and you told that it would introduce breakage :-) well, i don't want to use the user installed gl.h (it can introduce breakage with "beautifuls" old specific headers), and i don't want to have all opengl headers into wine tree (wine don't need to install it adn we don't need all defines). > Lionel Raphael

2 1

Success Story with Tomb Raider 3
by Sylvain Petreolle 06 Jun '03

06 Jun '03

Thanks to the D3D/ddraw workers, the last storm of patches makes Tomb Raider 3 able to start. You must set ZBuffer to on to get all graphics, and we run into gray levels at the moment. Great Work guys. PS : I submitted the app to AppDB. ===== Sylvain Petreolle (spetreolle at users dot sourceforge dot net) ICQ #170597259 No more War ! "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". For the Law of Oil and Fire, Im an European that lives in France. For all my Brothers and friends, Im a human living on Earth. ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Agent crashes when accessing attachments
by Oliver Sampson 06 Jun '03

06 Jun '03

Howdy, I just reinstalled my Linux system (HD crash), and at the same time moved to a RH9.0 distro. I read about the problems with the NPTL threading, and I have the latest CVS running (with the --with-nptl). Now when I have Agent running (which in all other respects seems fine) every time I go to add an attachment or save an attachment Agent crashes. Is this a known problem? Or should I start getting a backtrace and providing some more information? Thanks, -- Oliver Sampson olsam(a)quickaudio.com http://www.oliversampson.com

2 2

GL Header question
by Ann and Jason Edmeades 06 Jun '03

06 Jun '03

Hi, I just wanted to apologize for the breaks caused by all the d3d8 commits. The gl headers are a real nightmare, and whereas we would have caught the problems over time, instead we get them all in one go. Just a question - What is the general feeling about us having our own gl headers. Our basic aim is to query support before using it, but we need to be able to compile in higher support than available on the build machine. I would initially see something as simple as a /include/wine/winegl.h, and we put all definitions in there (even if they would have come from glext, glx, glxext etc). To start with, it would only be used for d3d8 but probably ddraw support is easy. Comments? Jason

3 9

Submits galore
by Johan Gill 06 Jun '03

06 Jun '03

It seems Alexandre is back or just got tired of the patch storm :) D3D-lovers should update from CVS I'd say. -- Johan Gill, johane(a)lysator.liu.se

4 3

Re: [dx52] fix AddDirtyRect
by Raphaël Junqueira 06 Jun '03

06 Jun '03

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > Hi all, Hi, > This patch fixes a problem that appeared in Mafia. how mafia works ? ;))) > Before this function > crashed when pDirtyRect was null. According to MSDN D3DERR_INVALIDCALL > should be returned in case of problems. Well, this is not really the good way to fix the problem (as the surface isn't dirtified) IDirect3DSurface8Impl_AddDirtyRect is an internal function (as seen in d3d8_provate.h declaration) so i cannot see where you have found the msdn docs ;) I think you wanted to fix a crash who happened in some IDirect3D*TextureImpl_AddDirty* call no ? if yes, can you try this patch instead ? > Regards, > Roderick Colenbrander Thanks, Raphael -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) iD8DBQE+4NBdp7NA3AmQTU4RAkkxAJ9oHG+cSN5Px+mga6BQrrb/wytc9QCfRpc2 QMvmNo9HL43iicyKWEfp1bY= =H46H -----END PGP SIGNATURE-----

2 1

Re: [GDI] GetObject patch (for null buffer functionality)
by Michael Stefaniuc 06 Jun '03

06 Jun '03

On Fri, Jun 06, 2003 at 10:39:43AM -0500, Kelly Leahy wrote: > I just found a problem with this patch. Let me send another one... Please send the patch as unified diff (diff -u). See http://www.winehq.com/Docs/wine-devel/patches.shtml for details. bye michael > I'll have it this afternoon. It shouldn't be a big deal (it won't be worse than the code was before) but let me fix it anyway. > > Kelly > ----- Original Message ----- > From: Kelly Leahy > To: wine-patches(a)winehq.com > Sent: Friday, June 06, 2003 10:22 AM > Subject: [GDI] GetObject patch (for null buffer functionality) > > > Kelly Leahy > kellyleahy(a)swbell.net > > Changelog- > - fixes problems with GDI GetObject function not working properly when a NULL buffer or 0 count is used. > - note - no attempt was made to fix this problem under 16-bit windows functions (GetObject16). > > Description: > The GDI GetObject function should return the number of bytes required for the buffer, when a NULL buffer pointer is passed to the function. However, the implementation in CVS did not provide this functionality. I've added two function pointers to the gdi_obj_funcs structure that allow for this functionality. The pointers are pGetObjectSizeA and pGetObjectSizeW, and for all object types except FONT, they are implemented by the same function. On FONT, the structure differs depending on whether the LOGFONTA or LOGFONTW structure is required (depends on which function is called - GetObjectA or GetObjectW). For bitmaps, the function must determine which structure is most appropriate (BITMAP or DIBSECTION) and return the size of that structure - it does so now. > > Patch is attached. -- Michael Stefaniuc Tel.: +49-711-96437-199 System Administration Fax.: +49-711-96437-111 Red Hat GmbH Email: mstefani(a)redhat.com Hauptstaetterstr. 58 http://www.redhat.de/ D-70178 Stuttgart

1 0

Re: Re: RE: GL Header question
by fenix＠club-internet.fr 06 Jun '03

06 Jun '03

>Theyre proprietary and only have GL 1.1 & 1.2 version. no they calims to be openGL1.3 compatible (and the define most of the pre-openGL1.4 values) But if they are proprietary, we can't use it Raphael

2 1

dlls/d3d8/device.c fails to compile
by Gerald Pfeifer 06 Jun '03

06 Jun '03

After the recent wave of commits, I'm getting a build failure for the following line in dlls/d3d8/device.c: IDirect3DBaseTexture8* cont = NULL; The failure looks as follows device.c:1989: syntax error before `*' device.c:1991: `hr' undeclared (first use in this function) device.c:1991: (Each undeclared identifier is reported only once device.c:1991: for each function it appears in.) device.c:1991: `cont' undeclared (first use in this function) gmake[2]: *** [device.o] Error 1 gmake[2]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls/d3d8' gmake[1]: *** [d3d8] Error 2 gmake[1]: Leaving directory `/.amd_mnt/nashira/files5/test/wine/dlls' gmake: *** [dlls] Error 2 which indicates that IDirect3DBaseTexture8 is not a known type at that point. That's using XFree86-4.3.0 and Mesa-3.4.2 (on FreeBSD 4.8). Gerald PS: I'll happily test any patches to fix this. -- Gerald "Jerry" pfeifer(a)dbai.tuwien.ac.at http://www.pfeifer.com/gerald/

2 1

Re: Re: Re: Submits galore
by fenix＠club-internet.fr 06 Jun '03

06 Jun '03

>> PS: As jason have some compilation problems too as it use a specific gl.h >> with a generic glext.h, i'm thinking about not using anymore the gl/glext >> headers definitions (i'm too bored to fixes each mismatch headers >> declaration) Hi All, >Well, I would say that we use the standard gl.h file (otherwise >it's too messy) but completely remove the dependency on glext.h. well, the problem is that gl.h defines ugly things too. as i have reports from users using mesa headers 3.4 (openGL 1.2 only declared but ugly pre 1.3 support) while using Mesa5.0 (very easy to do: install a XFree4.0 and after install only mesa5) >I plan to change all _EXT and _ARB stuff in the D3D7 code by >_WINE #defines (defined from the GL extension specs) and to never >use at all the function pointer typedef and use my own. i think you'll have many breakage :) >Basically, my baseline would be GL 1.2 and all the rest would be >redefined. As you want, But for me, I think building with GL1.4 (last ans most complete) headers and detecting/activing caps on runtime it's a more proper solution (no more #ifdef/#define in code, only in d3dcore_gl.h definitions). > Lionel Regards, Raphael

2 1

← Newer
1
...
17
18
19
20
21
22
23
...
26
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel June 2003