wine-devel May 2006

wine-devel@winehq.org

151 participants
288 discussions

WineD3D patches for review and discussion - not to be applied as-is.
by Jason Green 26 May '06

26 May '06

All of these apply to the latest Git tree, and should come after my last patch submission to wine-patches, but it shouldn't matter. I'm just looking for a little more feedback on these before I submit. This should lay the groundwork to begin implementing GLSL opcode generation. I've hacked around with some of them, and this will succesfully generate a GLSL shader program if the opcodes are implemented properly. Please let me know if any of my ideas here are fundamentally flawed. We've worked a bunch of it out on IRC, but this should be a nicer version to look at than my stuff at pastebin. :-) None of this code changes anything for the end-result ARB_vertex/fragment_program. It only generates GLSL if you have this regkey: HKLU\Software\Wine\Direct3D\UseGLSL = "enabled"

2 1

Announcing another ddraw/d3d7 patch
by Stefan Dösinger 26 May '06

26 May '06

Hi, Merging the code into WineD3D is done now, so the last thing is to merge the new ddraw code. I have uploaded a new diff to http://stud4.tuwien.ac.at/~e0526822/, with some updated screenshots. The diff is against wine git from May, 26th, 12 am(yep, the site has an older date). It should apply to much older versions too, but it won't work because a few crucial patches were applied in the last 2 days. 2 games are missing in my game list, Anarchy Online and Worms 2 are also known to work. Ok, what to do now? The patch fixes quite a few games, but with all bigger changes there are problems. I know some games which worked before that are broken now(Tibia, Z-Ball, Battlezone 2 and Swat 3). Battlezone 2 and Swat 3 have fogging issues, I have to talk to Lionel Ulmer about that, and BZ2 also needs tripple buffering. Tibia does some Blt Voodoo which doesn't work in OpenGL yet, z-ball is similar. It's likely that there are other breakages too. Another issue is that wined3d still has a hard dependency on OpenGL, and that means that my DirectDraw lib cannot do 2D rendering without libGL.so. It doesn't need hardware acceleration, only the lib has to be available. Roderic is working on that. So what can we do? * Wait with the merge until WineD3D does lazy linking to libGL * Wait with the merge until all games that worked before work now(gonna take some time) * Merge it now and fix the regressions as they occur. This would have the advantage that the code is in and it will only improve from that point, and it's easier for users to test. The drawback is that some users might complain that their games are broken :-|. On the other had, lots of others are waiting for this to get their games working. What is missing except of fixing regressions? Mostly performance improvements: 1) Make all ddraw games working with the OpenGL renderer 2) More intelligent texture upload: I have some hacks in that in my tree(Swat 3!, Half-Life 2 maybe?) 3) The same for render targets(System shock 2, swat 3, Prince of persia 3D) 4) Try to write an OpenGL gdi driver which handles TextOut and friends directly in OpenGL(Age of Empires, Settlers 3 combined with 1) 5) Rendering fixes: Fog and color keying(Pop3D, Battlezone 2, Swat 3) 6) Better OpenGL state management, this the lack of that takes performance down. 7) Multi-threaded D3D(Need for speed 3, Empire Earth, many others) All this will happen in wined3d, and the improvements aren't limited to D3D7 games. They don't have to be done in that order. If you're on wine-users, please CC me, I'm not yet subscribed there.

1 0

Re: MAPI32: implement FGetComponentPath
by Joris Huizer 26 May '06

26 May '06

Dmitry Timoshkov wrote: > + static const char * const fmt[] = { "%d\\NT", "%d\\95", "%d" }; > + char lcid_ver[20]; > + UINT i; > + > + for (i = 0; i < sizeof(fmt)/sizeof(fmt[0]); i++) > + { > + /* FIXME: what's the correct behaviour here? */ > + if (!qualifier || qualifier == lcid_ver) > + { > + sprintf(lcid_ver, fmt[i], GetUserDefaultUILanguage()); > + qualifier = lcid_ver; > + } > + I don't know this API or so, but... it seems to me that variable lcid_ver needs to be declared static, the data might get trashed otherwise HTH, Joris

1 0

Picasa for Linux available!
by Dan Kegel 26 May '06

26 May '06

Google has indeed been working on Picasa, and it's finally available for download at http://labs.google.com/ For the curious, here are a few tidbits about how it came to be. When Google wanted to port Picasa to Linux, they faced a problem: the Picasa team was busy working on new projects, and having them also do a native port would have taken a while. As an experiment, Google decided to give Wine a try. A quick look showed that much of Picasa already worked, but key features were missing: the IWebBrowser API, SSL, scanner/camera support, removable media notification (so you can insert a flash drive and have Windows notice it right away), and change notification (so Windows can notify apps when new files are created), among others. Fortunately, Wine was already halfway to having an implementation of IWebBrowser thanks to Jacek Caban's Summer of Code 2005 project. And all that other stuff couldn't be *that* hard, right? :-) So Google engaged Codeweavers to add those features and fix any other bugs. This resulted in tons of improvements to Wine (see the list at code.google.com/wine.html), all of which are now in the public tree at winehq.org. Many people assume that when porting a Windows app to Linux using Wine, the best thing to do is link Winelib into the application to create a native Linux application. Not so! It's just as effective, and a heck of a lot easier, to run the same binary on both Windows and Wine. So that's what the Picasa team did. Picasa for Linux uses slightly different text messages, but the .exe file is identical for both Windows and Linux. Toward the very end, everything was looking great except that the initial assumption that most cameras emulate storage devices turned out to be wrong. Fortunately, Marcus Meissner just happened to decide to implement libgphoto support; his patch appeared at the perfect moment, and now Picasa supports both common flavors of cameras. Two features left out of the Linux version were CD-ROM burning (the driver Picasa uses is hard to support under Wine) and movie playback (Wine doesn't have the necessary codecs). Both are potentially fixable in a future version, but were beyond the scope of this first port. One interesting challenge when shipping commercial apps for Linux is packaging -- do you choose RPM or Debian packages, or do you use a WIndows-style installer? The Picasa for Linux team chose all three, in hopes of pleasing everybody. (Let's see how well *that* works :-) The Windows-style installer was implemented using the open-source Loki installer, and a few patches were contributed back for that, too. The Picasa for Linux team had a blast. It's not often you get to pour resources into a vital open source project to help ship a commercial application! We hope we get to do it again sometime soon, and we hope the results are good enough to encourage other companies to give Wine a try. Thanks to the Wine community for a very capable platform! - Dan

8 9

Fonts getting corrupted in x11drv
by Troy Rollo 26 May '06

26 May '06

The attached sample program demonstrates a bug in font handling that can lead to corrupted fonts. Compile with "winegcc -g sysfont.c -lgdi32 -lcomdlg32". Run the resulting a.out, and you will see the letter "C" in the top left corner of the window, rendered in the system font. Click anywhere in the client area of the window and the letter will change its shape, even though it is still using the stock SYSTEM_FONT. The left click action creates a device context for the default printer and immediately deletes it. As part of the deletion of that device context, DeleteDC selects the stock SYSTEM_FONT into the device context. Since printer device contexts insist on scalable fonts, the existing (bitmapped) GDI font for the system font is unable to serve, so a new one is created, which ends up being based on the Tahoma (TrueType) font. On the next paint loop, when the test program calls SetFont it is the new, scalable font (based on Tahoma) that is found. The Tahoma font has different glyph codes to the System font, such that 'C' is glyph code 36 in the System font and 38 in Tahoma. Accordingly, x11drv identifies the glyph as not having been uploaded (it has uploaded glyph 36 before), and uploads it as glyph 38 based on its outline in Tahoma. The problem gets worse later on because some glyphs in the glyphset have been uploaded according to their "System" font positions (or in this case ,the same character has been uploaded in its position in both fonts). Rendering a character that uses the other glyph code results in the wrong character. You can get a mix of Tahoma and System characters appearing on the screen with the System characters displaying the shape of the wrong character. Every fix I look at seems like a horrible hack. Perhaps find_in_cache should only return bitmap fonts if the device can use them. If the caller then finds there is no bitmap font that matches it can then look for scalable fonts in the cache. -- Troy Rollo - wine(a)troy.rollo.name

3 5

Re: WineD3D: dynamicly load GL_ARB_multitexture functions
by Jason Green 26 May '06

26 May '06

On 5/25/06, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > > This patch will dynamicly load the needed GL_ARB_multitexture functions, adds the needed function prototypes and defines to wined3d_gl.h and gets rid of a GL_VERSION compile check. The patch also removes a few lines of code in drawprim.c. The piece of code checked for the presence of GL_ARB_multitexture and if it wasn't supported it called GLMULTITEXCOORD4F (which is only available if GL_ARB_multitexture is available) and then continued. Further in that function GLCLIENTACTIVETEXTURE (which is part of the extension too) before we checked if the extension was available. > This patch causes a pretty major regression in quite a few apps. Civilization 4 just flashes a lot and loses most of what few textures that did work previously. ;-) Program #16 here: http://www.zanir.szm.sk/dx10-19.html - It didn't work fully correct before, but it's worse now. All of the text is gone. Possibly more, time for bed, though. Jason

1 0

MSI installer flaw
by EA Durbin 26 May '06

26 May '06

Currently the MSI Installer is working backwards, In the file files.c it reads the files from the msi package and iterates through them and queries the Media table in order by LastSequence. The sort order for the media table should be DiskId according to MSDN. Just changing the sort order wont work unless the msi installer is revamped to work the right way. The code is written wrong for this. Currently its using LIST_FOR_EACH_ENTRY in the Install Files function for the files and then trying to ready the media per file using the sequence number of the file in the query on the media table using the file sequence as last sequence and returning the results order by LastSequence. It should first be reading the Media table first and sorting by DiskId. The installer then iterates through each row returned by the query from the media table and then for each file in the file table that falls within that disk id it should ready the media. Currently wine is doing it backwards which ends up trying to ready the wrong media if the last sequence. It needs to read the media table, then starting with DiskId 1, iterate through all of disk Id 1 and read from the file table order by sequence until it reaches the last sequence as indicated in the media table for the working DiskId, then it jumps to the next DiskId 2, 3, and so on. The lastsequence of the working DiskId should always be greater than that of the last sequence of the previous DiskId, if not the results should be skipped, currently it is trying to read from DiskId's that have zero as the LastSequence but 22 as the DiskId. Zero indicates the first entry in the media table(if your in DiskId 1). as you increment through the DiskId's the LastSequence should increment as well, if it doesnt you skip that install media. This is what causes the cabinet bugs in bugs #4533 and #5139. A quick fix , but not the solution would be to change the query so it doesn't return the results from the media table if the LastSequence is 0 and the DiskId is greater than 1. The solution would be to rewrite the installer to do things the right way querying the Media table first, and then installing the files in order from the media table. If someone could help me work on this it would be much appreciated as I'm kind of rusty in C, I'm a perl monger by trade and not very familiar with wine's msi innerworkings. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/msi/setup/…. http://msdn.microsoft.com/library/en-us/msi/setup/ordering_file_sequence_nu… http://msdn.microsoft.com/library/en-us/msi/setup/file_table.asp?frame=true As you'll see in MSDN the file and media table sequence and LastSequence correspond with one another. Each has checks upon the other to determine the proper install order.

2 1

Re: Mac OS X Audio driver
by Alexandre Julliard 26 May '06

26 May '06

Emmanuel Maillard <mahanuu(a)opendarwin.org> writes: > Authors: > Ken Thomases <ken at codeweavers dot com> > Emmanuel Maillard <mahanuu at opendarwin dot org> > > Changelog: > Initial Audio Driver for Mac OS X. Could you please replace the fprintfs by the proper Wine debug macros? Also it would be nice if you could send only your own code; I can then merge Ken's patches on top of it, this way we get a proper record of the development in the git history. -- Alexandre Julliard julliard(a)winehq.org

4 7

Press: Linux Journal - Running Sound Apps
by Brian Vincent 25 May '06

25 May '06

I just saw the May issue of Linux Journal and it has an article titled "Running Sound Applications Under Wine". It's written by Dave Phillips and it's pretty good. Things seemed to work about as well as you'd expect, well, maybe even better than a lot of you would expect. Programs installed ok, audio configuration seemed pretty easy, etc. I actually think it's a great that Wine isn't the focus of the article; he spends most of the time talking about applications. I guess that means all the magic was successfully hidden. I half expected the article to complain about broken things, but there was hardly a mention of it at all. At the end he did list about 4 applications that issues, including one named "Finale" that didn't install. Dave did mention he'd like to see the JACK audio driver working: "Hopefully, Wine's JACK driver will work again by the time this article is printed. JACK is the present and future of Linux audio, and it world be a definite Good Thing for the Wine Project. A virtual ASIO driver might be a helpful addition as well." All in all, it's a wonderful article written by one of the top Linux sound gurus. [Oops. I just noticed there's a glaring mistake in it. He said he tested with Wine 0.9.6 and then has a paragraph discussing ~/.wine/config. I think it's a remnant of an old installation.] -Brian

1 0

Re: usp10: Add more stubs
by Alexandre Julliard 25 May '06

25 May '06

Jeff L <lats(a)yless4u.com.au> writes: > + hr = ScriptBreak(pwcChars, cChars3, &psa2, &psla); > + ok(hr == S_OK, "ScriptBreak Stub should return S_OK not %08x\n", (unsigned int) hr); This can't possibly work, you are passing complete garbage to that function. Have you really tested that on Windows? -- Alexandre Julliard julliard(a)winehq.org

1 0

← Newer
1
...
5
6
7
8
9
10
11
...
29
Older →

Jump to page:

2025

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 May 2006