March 2007 - Wine-devel - list.winehq.org

re: Add d3drmdef.h header - try 2
by Dan Kegel 13 Mar '07

13 Mar '07

Vijay wrote: > Add minimalistic d3drmdef.h But why? None of the code in wine currently needs it. Maybe you should submit it together with the first bit of code that needs it. -- Wine for Windows ISVs: http://kegel.com/wine/isv

1 0

re: Add d3drmdef.h header
by Dan Kegel 13 Mar '07

13 Mar '07

vijay wrote: > [complete d3drmdef.h] It seems premature to check that in without any code that uses it. Also, did you really write all that yourself? - Dan

3 5

Wiki changes lost? (was: Re: Known desktop migration projects and their "must have" Windows apps)
by Dan Kegel 13 Mar '07

13 Mar '07

On 3/11/07, Dan Kegel <dank(a)kegel.com> wrote: > I'm putting a list together at > http://wiki.winehq.org/DesktopMigrationProjects This, and all my other recent wiki changes, seem to have vanished in a puff of greasy black smoke. What's up? This isn't doing much for my trust in wikis... - Dan

4 10

CreateScalableFontResource - a few questions
by Chris Howe 13 Mar '07

13 Mar '07

Hi all, For my first foray into contributing to Wine (a blast, so far :) ) I am implementing CreateScalableFontResource which is currently present in stub form, but when fully implemented should create .FOT files from .TTF files for (amongst other things) temporarily installing fonts by a successive call to AddFontResource (which exists in Wine). It was trivial to code the functionality for the flow of CreateScalableFontResource as per the documentation but my research into the .FOT file format threw up a couple of questions. Even though .FOT files, as far as they're used by AddFontResource are little more than storage for a couple of pathnames, they are in fact Win3.1-style NE-binary files. With that in mind, 1) AFAICT, there is no code in Wine currently to save NE-binaries to disk, although obviously they are loadable and data structures relating to the format are defined. Rather than write a standalone, .FOT saving function, based off the kind of code you see in the fnt2fon program - .FON files are a similar, though not identical format - would it be better to write something like a NE_SaveModule that takes an in-memory NE module and saves it to disk, and call that from my .FOT saving code? This would live in ne_module.c I guess, and be limited, certainly initially, to the context in which I'd be using it. IE, just saving the resources. Indeed, I don't know in what other context that code WOULD be used, but who knows, down the line someone might want to expand it to do something more useful. 2) NE binaries, including FOT files, contain as part of the header a DOS stub-executable that typically spits out a message of some sort. I reasoned that being in itself a compiled binary we can't legally use the blob of binary that would appear in a real-world FOT file as-is, and I certainly wasn't about to go decompiling it, so I lifted the DOS stub executable from fnt2fon which I'm assuming as it's distributed with WINE is fair game. This will mean .FOT files generated by my code will be slightly different to a real, "in-the-wild" .FOT file, but I'm not sure in the circumstances that matters as the file is typically temporary, and only used as a container, never to be run - it's just different from a user perspective. Is this OK? Also, are there any open-source requirements on that small binary blob? Fnt2fon certainly includes it with no added info. 3) Related to item 2, so far, the actual spec of the .FOT file format has eluded me, though knowing that it's a NE binary has enabled me to reverse a lot of it, which I'm yet to test but I believe will be enough to fool AddFontResource into doing what it's supposed to do. Again, is it enough to go that far for now as the FOT format seems to be unsupported in WINE? Advice on these points would help me help you :) -- Chris Howe

2 1

DirectX 10 start as a SoC project?
by Stefan Dösinger 13 Mar '07

13 Mar '07

Hi, Thinking about SoC I though that starting a DirectX 10 implementation may be a good summer of code project. I do not mean implementing the full d3d10 lib, that would be way to much, more starting the infrastructure. Henri disagreed with the idea, so I thought I'll write a mail for public discussion :-) . Looking at the timeline for SoC I hope it isn't too late. My idea is to start a d3d10 implementation up to the following point: -> Add a winver Windows Vista to make version checkers happy :-) -> Create the d3d10 lib and start the .idl file for header generation -> Write stubs for the functions to allow the app to create all the interfaces -> Write test cases for reference counting. ddraw and d3d9 show that Microsoft does not stick to its own COM rules -> Make methods that have already 1:1 equivalents in wined3d call wined3d. Add other methods as required to wined3d. -> Implement them as far as you feel like :-) I think the good thing about this is that there are is not much knowledge about wined3d and d3d10 necessary at the start. The one who works on it can learn the d3d10 interface while writing the stubs and learn about wined3d when starting to call it. Opinions? Suggestions? Cheers, Stefan

11 21

Re: CreateScalableFontResource - a few questions
by Juan Lang 13 Mar '07

13 Mar '07

Hi Chris, > For my first foray into contributing to Wine Welcome! > would it be better to write something like a NE_SaveModule that takes > an in-memory NE module and saves it to disk, and call that from my > .FOT saving code? Only if it makes your code more readable. In general Wine doesn't share code between modules, unless Windows does. So this would almost certainly be kept in gdi32, unless you know of a public Windows API that does what you suggest. > 2) NE binaries, including FOT files, contain as part of the header > a DOS stub-executable that typically spits out a message of > some sort. I reasoned that being in itself a compiled binary we > can't legally use the blob of binary that would appear in a > real-world FOT file as-is, and I certainly wasn't about to go > decompiling it, so I lifted the DOS stub executable from fnt2fon > which I'm assuming as it's distributed with WINE is fair game. That seems reasonable to me. > Also, are there any open-source requirements on that small binary > blob? Fnt2fon certainly includes it with no added info. Taking it from fnt2fon seems safe enough to me too. > 3) Related to item 2, so far, the actual spec of the .FOT file > format has eluded me, though knowing that it's a NE binary has > enabled me to reverse a lot of it, which I'm yet to test but I > believe will be enough to fool AddFontResource into doing what > it's supposed to do. Again, is it enough to go that far for now > as the FOT format seems to be unsupported in WINE? Yes, that's probably enough for now. --Juan ____________________________________________________________________________________ 8:00? 8:25? 8:40? Find a flick in no time with the Yahoo! Search movie showtime shortcut. http://tools.search.yahoo.com/shortcuts/#news

1 0

Re: wined3d: Set wrapmode for cubemags to clamp regardeless of the sampler state
by Stefan Dösinger 12 Mar '07

12 Mar '07

Am Samstag 10 März 2007 15:02 schrieb Fabian Bieler: > This Patch forces GL_CLAMP_TO_EDGE on all cubemaps. > > I tested this on XP with some Radeon X1???. > > Also, this fixes some renderissues Half-Life 2. Say, does that fix the strange quad boarders like in this screenshot? http://bugs.winehq.org/attachment.cgi?id=5297&action=view (Eve Online). It sounds like it would do that, I'm very impressed :-) How did you test that? It sounds like a test case using the visual test framework is worth an investigation. I can try to write a test for that.

3 4

WineHQ maintenance
by Jeremy Newman 12 Mar '07

12 Mar '07

I will be performing some maintenance to WineHQ today at 14:30 CST. The recent outages on WineHQ were attributed to a faulty drive in the RAID. I will be taking the server offline to replace that drive. The server should only be offline for about 20 minutes. -newman

1 0

LockRect Problem
by Erich Hoover 12 Mar '07

12 Mar '07

I'm looking into a problem that causes Supreme Commander to segfault (Bug #7643 <http://bugs.winehq.org/show_bug.cgi?id=7643>) and I believe I may have run into a problem with IWineD3DSurfaceImpl_LockRect. I believe the problem is a typo in the line: > This->resource.allocatedMemory = HeapAlloc(GetProcessHeap() ,0 , This-> > resource.size + 4); I think that the allocated memory should be the size of the resource multiplied by 4 (instead of adding 4). With the current allocation, for some textures, the operation to calculate the pBits location returns a memory address that is past the end of the allocated memory. So, after this operation: > pLockedRect->pBits = This->resource.allocatedMemory + (pLockedRect->Pitch > * pRect->top) + (pRect->left * This->bytesPerPixel) > the value of pLockedRect->pBits is greater than "This-> resource.allocatedMemory + This->resource.size + 4". I've dug around a bit to see if This->resource.size was just allocated incorrectly but that does not appear the case. So, if someone could confirm or deny that this is a typo problem then I'd really appreciate it. Erich Hoover ehoover(a)mines.edu

3 4

fog with pixel shaders < 3.0
by Fabian Bieler 12 Mar '07

12 Mar '07

Hello! I'd like to get fog working in conjunction with pixel shaders 2.0 or earlier. The problem is that said shaders don't replace the fog stage in Direct3D. Adding the necessary fog calculations to a GLSL fragment shader is trivial, however, this results in a dependency of the shader on the current fog state. Now, I have thought up three solutions for this problem: 1) Compile two versions of every fragment shader (one with fog and one without) and choose the appropriate one according to the state. Pro: Probably performance wise the cheapest solution Con: Generates more shaders, however, as shader are only compiled on demand, this shouldn't be too bad. 2) Rebuild the shader whenever it is bound in conjunction with a changed fog state. Pro: ? Con: This would be a performance killer as it would potentially cause multiple calls of IWineD3DPixelShaderImpl_CompileShader per frame, as some Programs use the same fragment shader for rendering with and without fog. (ok, I only know this of source based games, but imo that's bad enough) 3) Add Fog calculation to every shader, enabling or disabling it at runtime via a constant factor of 1.0 or 0.0 depending on the fog state which is supplied as a shader constant. Pro: cpu-load wise cheap Con: Adds some more instructions to fragment shader code. Now, I don't particularly like any of these solutions, so I'd welcome other ideas, comments or suggestions. Fabian P.S: I noticed that fog-state management is not yet included in the state table. Should a patch that fixes fog with pixel shaders wait until this is done, or is this of no importance?

3 8