Am 04.10.2013 um 17:15 schrieb Henri Verbeet :
> I guess that makes it ok in practice, but I'd still feel happier about
> this kind of patch if we actually enforced resource access flags
> first. (At which point you could also just check the access flags
> instead of the poo
; will go to a cpu side clear because of the INSYSMEM optimization. (This
> optimization is needed for a few other things to work correctly, but that's a
> different patch.)
>
I guess that makes it ok in practice, but I'd still feel happier about
this kind of patch if we actually
Am 04.10.2013 um 15:51 schrieb Stefan Dösinger :
> No codepath in wined3d_surface_blt will attempt to load a sysmem surface into
> a texture. fbo_blit_supported returns FALSE if src or destination are in
> sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills
> will go to a
Am 04.10.2013 um 15:28 schrieb Henri Verbeet :
> On 4 October 2013 15:02, Stefan Dösinger wrote:
>> Client storage only applies to GL textures, which won't be created for
>> sysmem surfaces.
>>
> I don't think that's necessarily true at the moment. In particular,
> ddraw blits can in principle
On 4 October 2013 15:02, Stefan Dösinger wrote:
> Client storage only applies to GL textures, which won't be created for sysmem
> surfaces.
>
I don't think that's necessarily true at the moment. In particular,
ddraw blits can in principle cause a texture to be created for sysmem
surfaces. There m
On 4 October 2013 00:03, Stefan Dösinger wrote:
> @@ -2883,10 +2886,6 @@ HRESULT CDECL wined3d_surface_set_mem(struct
> wined3d_surface *surface, void *mem
> /* Now the surface memory is most up do date. Invalidate drawable
> and texture. */
> surface_validate_location(surface,
> This is awfully overcomplicated (plus I do not know how to make such a
> "global" variable in wine) so I was wondering is it OK to implement this
> differently than windows does it.
If the implementation does not have to be the same to preserve
compatibility, then you should ignore those details
For past two weeks I've been implementing apphelp.dll. I got that one
working and moved onto kernel32 part of magic. According to various papers
and blogs it seems that windows logs all exes and dlls ever executed in
registry[1] and uses it as cache to lookup if binary needs to be shimmed or
patche
eview the translation[1].
>
>> Launchpad would need to pull updated PO files from Wine regularly.
>> Ideally that would be automatic and happen daily (both to account
>> for translations happening outside Launchpad and to take changes in
>> the resource files
files into account quickly).
transifex has option to pull form outside, and the frequency is about
daily[2].
> Conversely Launchpad should submit patches back to Wine. Ideally that
> would be automated as much as possible but I'm fuzzy on the details
> here (especially on how to pr
2013/5/22 Stefan Dösinger
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Am 2013-05-22 10:59, schrieb Christian Costa:
> > *"You are not allowed to analyze Windows files with the trace
> > functions of Wine"
> E.g. when you are working on Wine's d3dx9 implementation, you
> shouldn't use na
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 2013-05-22 10:59, schrieb Christian Costa:
> *"You are not allowed to analyze Windows files with the trace
> functions of Wine"
E.g. when you are working on Wine's d3dx9 implementation, you
shouldn't use native d3dx9.dll and create a +d3d9 log to se
*Hi,
*
*I read on the GSoC page this:
*
*"You are not allowed to analyze Windows files with the trace functions of
Wine"
*
*What does that mean?
*
*Thanks
*
*Christian
*
Thanks Nikolay and Piotr.
Sorry for my poor english... :-(
2013/4/1 Piotr Caban
>
> The functions should have been defined in headers. The order of
definitions is not important.
Piotr got what I wanted to express.
I have implemented a few of it and there are some still not. I think I can
define a
Hi Jactry.
On 03/31/13 14:40, Jactry Zeng wrote:
As we can see, _strcoll_l and _mbsnbcoll_l were implemented but they
were not declared.
Should we declare all of them? And whether the sequence was important?
The functions should have been defined in headers. The order of
definitions is not impo
Hi folks,
I tried to implement a lot of strcoll function these days, and I meet some
trouble when I added the declaration into include/msvcrt/*.h.
With "grep coll *.spec" in dlls/msvcrt/ we can find there was a lot of
strcoll function. Some of them was implemented
and some of them not:
@ cdecl __
On Sat, 23 Feb 2013, Henri Verbeet wrote:
> On 23 February 2013 17:20, Henri Verbeet wrote:
> > Personally, I suspect the test is just overly restrictive.
>
> Also, just to clarify something, initially on IRC I was under the
> impression the driver *only* exposed X1R5G5B5, i.e. instead of
> X8R8
On 23 February 2013 17:20, Henri Verbeet wrote:
> Personally, I suspect the test is just overly restrictive.
Also, just to clarify something, initially on IRC I was under the
impression the driver *only* exposed X1R5G5B5, i.e. instead of
X8R8G8B8, while clearly supporting 32 bpp display modes. Th
On 23 February 2013 16:42, Stefan Dösinger wrote:
> There are also potential issues because X1R5G5B5 is a 16 bit format, just
> like R5G6B5, which makes depth<->format mapping tricky. If the current setup
> uses a color depth of 16 bits and the app does not request a specific adapter
> format,
Am 21.02.2013 um 17:24 schrieb Francois Gouget :
> In essence our tests say that the driver must not support X1R5G5B5. Why?
I think the tests were written this way because we did not find any driver that
exposed this format, and we had a lot of cases in other areas where exposing
additional feat
If I run Wine's conformance tests in a QEmu VM using Spice's QXL driver
I get the following errors:
d3d8:device
device.c:1004: Test failed: Unexpected display mode returned for mode 0: 0x18
d3d9:device
device.c:1366: Test failed: EnumAdapterModes(D3DFMT_X1R5G5B5) did not return
D3DERR_INVALIDC
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=24350
Your paranoid android
On Thu, Oct 18, 2012 at 7:49 PM, Saulius Krasuckas wrote:
> The post:
> http://www.linuxforums.org/forum/coffee-lounge/192526-survey-about-gaming-linux.html
>
> The results containing one item about using Wine:
> https://docs.google.com/spreadsheet/viewan
The post:
http://www.linuxforums.org/forum/coffee-lounge/192526-survey-about-gaming-linux.html
The results containing one item about using Wine:
https://docs.google.com/spreadsheet/viewanalytics?formkey=dEI5dEx1SGw5TEJMWi1RUnBUX09LSGc6MQ
S.
I just submitted a draft rewrite of WineHQ's About page in English that
integrates some things from the wiki page, but there are still Hebrew
and Spanish about pages on the wiki. I started working on translating
the Spanish one, but realized someone else should probably do it after
one para
28.08.2012 19:50, Kyle Auble пишет
> If you're mainly noticing problems with the wiki, that may also be
> that we're using an outdated version of moinmoin. Cheer Xiao was saying
> that Moinmoin 2.0 will allow Mediawiki syntax so I'd recommend
> upgrading Moinmoin, then converting the pages to Med
Tues, Aug 28, 2012 4:47 AM, Oleg Yarigin wrote:
> Now I wait an answer from Dimi Paun.
>
>
> Well, in addition, how do you think, is any necessarity there to move
> wine site and wiki from Apache to Cherokee?
While I think it's good to keep alternatives in mind as new technology
comes out, I would
On 08/28/2012 04:47 AM, Oleg Yarigin wrote:
Well, in addition, how do you think, is any necessarity there to move
wine site and wiki from Apache to Cherokee?
Not going to happen anytime in the near future. I won't say never however.
-N
Finally I got an answer from Jeremy White, wine site admin:
Hi Oleg,
On 08/26/2012 08:21 AM, Oleg Yarigin wrote:
Good time of a day, Jeremy.
I write to you as to a WEB-administrator of WineHQ server about some
ideas of site functionality improvement:
1. How is about moving WineHQ Wiki
uble :
>> Sat, 25 Aug 2012 14:44, Oleg Yarigin wrote:
>>> When I edited pages in the WineHQ Wiki, I notised, its markup lankuage
>>> isn`t so good as MediaWiki`s one. How do you think about moving the Wiki
>>> into MediaWiki engine? Besides, moving each language se
(whatever sponsored means, didn't find
> further information) and the code
> is not accessable via a wine git repo (maybe it should be in tools.git,
> website.git or its own). This also leads to the fact that we still have no
> new wiki theme years after the
> theme chang
onsored means, didn't find further
information) and the code
is not accessable via a wine git repo (maybe it should be in tools.git,
website.git or its own). This also leads to the fact that we still have no new
wiki theme years after the
theme change on the website.
Now that we upgraded the
2012/8/26 Cheer Xiao :
> ... snip ...
> Try out MoinMoin 2.0 at this minefield[5]. The last Summer of Code[6]
> saw a few interesting enhancements like greatly improved themes,
> support for blog and ticket system (disclaimer: ticket system is my
> project), but the test site has not been updated y
ood as MediaWiki`s one. How do you think about moving the Wiki
>> into MediaWiki engine? Besides, moving each language section of the Wiki
>> into separated subdomain (like in Wikipedia) would be a good idea too.
>
> I've been working a lot on the wiki recently, and I actually
Sat, 25 Aug 2012 14:44, Oleg Yarigin wrote:
> When I edited pages in the WineHQ Wiki, I notised, its markup lankuage
> isn`t so good as MediaWiki`s one. How do you think about moving the Wiki
> into MediaWiki engine? Besides, moving each language section of the Wiki
> into separat
25.08.2012 14:42, GOUJON Alexandre пишет:
I can't help you about the other points but as every project, answers
you are looking for lies in the source code.
See http://source.winehq.org/ident?i=wine_server_call for instance.
I searched through the source with Notepad++, but I found nothing,
Hi to all!
When I edited pages in the WineHQ Wiki, I notised, its markup lankuage
isn`t so good as MediaWiki`s one. How do you think about moving the Wiki
into MediaWiki engine? Besides, moving each language section of the Wiki
into separated subdomain (like in Wikipedia) would be a good idea
On 08/25/2012 12:28 PM, Oleg Yarigin wrote:
And an off-top question: where is wine_server_call realisation defined?
I can't help you about the other points but as every project, answers
you are looking for lies in the source code.
See http://source.winehq.org/ident?i=wine_server_cal
Hi!
I have an idea to move some Wine parts into Linux subsystems. For
instance, Wine apps windows and window content can be drawn with Desktop
Manager via USER32.DLL opposite of using Wine Server. Similar thing can
be with clipboard.
I understand, it`s a big work, what is must to be started
Hello, regarding the "Implement Common Windows Scripting Classes" gsoc
idea. How many of these classes would be fine for the length of the
program? I'm thinking that maybe 3 classes with thorough would be cool
for a proposal.
Some of them like "Dictionary" seem to be pretty straight forward and
sm
ame in
> this case, but occasionally also urlmon,wininet,tid or even trying
> debugging version of Gecko (although I would not advice debugging version
> of Gecko unless there is a reason, which I can't know without knowing more
> about the bug).
>
Thanks for the hints. Would try t
Hi Alexey,
On 03/13/12 20:59, Alexey Loukianov wrote:
> Good day to all,
>
> I've got a question, which is most probably should be addressed to Jacek
> Caban, concerning the proper way to debug and report about the
> problems with
> wine-gecko/mshtml implementation.
>
On Tue, Mar 13, 2012 at 14:59, Alexey Loukianov wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Good day to all,
>
> I've got a question, which is most probably should be addressed to Jacek
> Caban, concerning the proper way to debug and report about the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Good day to all,
I've got a question, which is most probably should be addressed to Jacek
Caban, concerning the proper way to debug and report about the problems with
wine-gecko/mshtml implementation.
What I've got here is an app that cras
Hi,
The neutral sublanguage of English (en.po) is missing a lot of texts.
Is there really a need to "translate" everything to neutral English? I
think it's a waste of time to maintain three sets of English texts
(msgid, en.po, en_US.po). It would be more practical to have msgids
automatically
Hi,
Robert Hovden mailed me some time ago about the authors of the wiki pages and i
explained him how that works.
He wanted to write an Article and now here it is:
You can read it here: http://onlinedigeditions.com/publication/?i=100670
The magazines web address is, http://www.microscopy
On Mon, Feb 20, 2012 at 12:17 PM, Dmitry Timoshkov wrote:
> prateek papriwal wrote:
>
>> can anyone suggest me how to get knowledge of windows API's and Wine
>> Internals. I am reading the documentation provided on the site but i am
>> finding it hard to grasp the things .. if u can suggest me so
prateek papriwal wrote:
> can anyone suggest me how to get knowledge of windows API's and Wine
> Internals. I am reading the documentation provided on the site but i am
> finding it hard to grasp the things .. if u can suggest me some good
> readings or moreover a structured way of reading things
hello,
can anyone suggest me how to get knowledge of windows API's and Wine
Internals. I am reading the documentation provided on the site but i am
finding it hard to grasp the things .. if u can suggest me some good
readings or moreover a structured way of reading things it would be helpful
for me
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=16816
Your paranoid android
On 01/13/2012 12:05 AM, Erich E. Hoover wrote:
Real Name:
Erich Hoover
Changelog:
server: Add mechanism to store and retrieve information about a socket.
+
+/* Get and set user-accessible socket variables */
+@REQ(get_socket_variable)
+obj_handle_t handle;/* handle to
"Erich E. Hoover" writes:
> Real Name:
> Erich Hoover
>
> Description:
> This patch implements storing of internal information about a
> socket. The intent for this approach is to add a dynamic mechanism to
> permit the storage of various variables that
Am 13.12.2011 04:44, schrieb Vitaliy Margolen:
> On 12/12/2011 04:34 PM, Scott Ritchie wrote:
>> Would it be appropriate to display those self-added bookmarks in Wine?
>> I'm worried there might be something I'm missing about the
>> implementation that would ma
GOUJON Alexandre writes:
> Am I the only one who noticed that the "Release 1.3.35" was authored
> by Frédéric Delanoy ?
> Who's the author (really) doesn't matter but having a commit from a
> gmail.com e-mail address instead of a winehq.org one (just) surprised
> me.
That's a bug in my git front
Am I the only one who noticed that the "Release 1.3.35" was authored by
Frédéric Delanoy ?
Who's the author (really) doesn't matter but having a commit from a
gmail.com e-mail address instead of a winehq.org one (just) surprised me.
Anyway, let's pull this latest wine version, compile and test i
On 12/12/2011 04:34 PM, Scott Ritchie wrote:
Would it be appropriate to display those self-added bookmarks in Wine?
I'm worried there might be something I'm missing about the
implementation that would make this difficult or a bad idea.
It would only work with v6 controls, not the o
Scott Ritchie wrote:
> Would it be appropriate to display those self-added bookmarks in Wine?
> I'm worried there might be something I'm missing about the
> implementation that would make this difficult or a bad idea.
File open/save dialogs use the standard SDK templates, wh
ome are obvious, and we duplicate them (eg Desktop), others are
automatic, like gvfs links to external hard disks. Users can also add
their own.
Would it be appropriate to display those self-added bookmarks in Wine?
I'm worried there might be something I'm missing about the
implementation
On Thu, Nov 24, 2011 at 8:27 PM, Kane Jade wrote:
> Perhaps the program Zynamics BinNavi is useful to analyze the win32
> applications, etc:
> Zynamics BinNavi is the primary binary code reverse engineering tool based
> on graph visualization
Hi,
Most likely this is your own software and you're
database*
- Write *scripts and plugins to extend BinNavi* to meet your specific
goals
- Rename and *annotate variables and functions* to make them
self-explanatory
- Use the REIL meta-language to *write platform-independent program
analysis code*
To learn more about the features and
at looks like it should be replaced, correct?
OTOH, I'm unsettled whether MidiStreamSuspend & -Restart should wait
for a reply to the message, so PostThreadMessage may be enough.
Furthermore, I'm unsure about the implications of adding a dummy
window and message queue. The MSDN blog
On 27 September 2011 13:49, wrote:
> snippet. It looks like a +relay log, not showing what I want to see.
That's mostly intentional, for COM traces in general at least. The
main purpose of the initial trace in COM calls is to show that a
function gets called at all, since these don't show up in
Hi,
I'm not satisfied with the current winmm+mmdevapi logging. I suspect that COM
logging of other components is similarly bad. Consider the following
snippet. It looks like a +relay log, not showing what I want to see.
0022:trace:winmm:waveOutWrite (0xc000, 0x21f140, 32)
0020:trace:winmm:WOD_
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=14136
Your paranoid android
On Fri, Aug 19, 2011 at 2:15 AM, Nowres Rafid wrote:
>> That means that your patch series
>> [1/2] cmd: fixing an error with redirection operators
>> [2/2] cmd/tests: fixing an error with redirection operators (updating
>> test results)
>>
>> is incorrect, since tests marked todo_wine will fail af
On 19/08/2011 03:14, Dan Kegel wrote:
Hi Nowres,
it's awesome that you're digging into cmd like this!
The rule with Wine is that
Each patch you submit shall pass tests.
That means that your patch series
[1/2] cmd: fixing an error with redirection operators
[2/2] cmd/tests: fixing an error wi
On 10 July 2011 11:27, Scott Ritchie wrote:
> done that's worth listing? Is "sometime in 2011" still the best guess
> for 1.4's release?
>
I'd guess late 2011 or maybe early 2012. I think the main criterion is
having a solid 400 regressions. It's currently at 399, but it
fluctuates a bit.
Scott Ritchie open-vote.org> writes:
>
> According to Alexandre...
>
> 1.4 will be out "sometime in 2011"
.
.
.
>
> Plus, of course, the general goal of making more applications work :)
>
> It seems like we're making serious progress. Have any of these stalled
> or become less important? Ha
According to Alexandre...
1.4 will be out "sometime in 2011"
At the time of wineconf we already had several new features: animated
cursors, 64-bit Gecko, native cursor themes, AcceptEx support, mono packages
Goals for the 1.4 release:
Successful 64-bit make test
Successful 32-bit make test ;)
R
Patrick Gauthier writes:
> Now I am wondering if it's my system which is at fault for being badly
> configured or if I should just modify winebuild so that it is more
> lenient in its parsing of the target?
You should fix your mingw package. We need a cpu name to know which
architecture is suppo
On 06/12/11 07:03, André Hentschel wrote:
> Hi,
> i had a look in my config.log and found in my 32-bit tree:
> ...
> configure:7022: checking for i686-mingw32msvc-gcc
> configure:7052: result: no
> configure:7022: checking for i586-mingw32msvc-gcc
> configure:7038: found /usr/bin/i586-mingw32msvc-g
s describred there:
> http://www.winehq.org/docs/winedev-guide/testing-windows
>
> However, trying to compile comctl32_tests using the WINE headers would
> complain about EXCEPTION_EXECUTE_HANDLER being undefined. On the other
> hand, compiling with the MSVC headers would complain
cc-4.5.0_1,1
> mingw32-pdcurses-3.4
> mingw32-pthreads-2.8.0
>
> Eventually I would like to just be able to make crosstest so that I can
> stay in one dev environments and not two, so if anybody could help me
> about why isn't mingw32 detected, I would like it.
Hi,
i had a lo
Op 12-06-11 07:54, Patrick Gauthier schreef:
> Hi,
>
> As I was writing my task dialog test I ran into a few problems trying to
> test on Windows...
>
> First, I tried building it using make crosstest but I keep getting this:
>
> $ gmake crosstest
> crosstest is not supported (mingw not installed?)
complain about EXCEPTION_EXECUTE_HANDLER being undefined. On the other
hand, compiling with the MSVC headers would complain about TVIS_FOCUSED
not being present. According to this:
http://support.microsoft.com/kb/166471 it has been deprecated and
removed from MS headers a long time ago.
Eventually I
When 1.3.19 came out it changed the build requirements for OSS support
-- OSS 3 was no longer supported and OSS 4 dev libraries were required
at build time.
This was the changelog:
New sound driver architecture for MMDevAPI.
Better support for relative mouse events in DInput.
Debugger
y one wine handles differently is
SHCNRF_NewDelivery, so what do the others mean? MSDN says something
about it but quite frankly I don't know what the difference between
interrupt level and shell level notifications are. Also the the only
place in the tree where wine uses this function
Hi,
On 11-05-13 10:15 AM, Henri Verbeet wrote:
On 13 May 2011 19:03, Ralph Little wrote:
trace:ddraw:CreateSurface DDSURF dwFlags(124)
Is that correct? It doesn't have DDSD_PIXELFORMAT set.
No scrap that last message, my original trace was incorrect.
A typo meant I was outputting the s
Hi,
On 13 May 2011 19:03, Ralph Little wrote:
trace:ddraw:CreateSurface DDSURF dwFlags(124)
Is that correct? It doesn't have DDSD_PIXELFORMAT set.
Wait, you're right. I misread what the code was doing.
/* No pixelformat given? Use the current screen format */
if(!(desc2.dwFlags
On 13 May 2011 19:03, Ralph Little wrote:
> trace:ddraw:CreateSurface DDSURF dwFlags(124)
Is that correct? It doesn't have DDSD_PIXELFORMAT set.
Hi,
On 11-05-13 03:33 AM, Stefan Dösinger wrote:
On Friday 13 May 2011 01:36:09 Ralph Little wrote:
Hi,
Further to my last post, I can confirm that the pixelformat structure is
completely empty.
A quick dump of the DDPIXELFORMAT structure shows that:
Can you show us the entire DDSURFACEDESC2 s
On Friday 13 May 2011 01:36:09 Ralph Little wrote:
> Hi,
> Further to my last post, I can confirm that the pixelformat structure is
> completely empty.
> A quick dump of the DDPIXELFORMAT structure shows that:
Can you show us the entire DDSURFACEDESC2 structure?
> b) DDPIXELFORMAT is properly fill
Hi,
Further to my last post, I can confirm that the pixelformat structure is
completely empty.
A quick dump of the DDPIXELFORMAT structure shows that:
=
trace:ddraw:PixelFormat_DD2WineD3D =dwSize = 32, sizeof(32)
trace:ddraw:PixelFormat_DD2WineD3D ===
Hi,
I have been looking into bug #9672 regarding a crash on startup of The Sims.
Tracing through what is happening, the problem seems to be manifesting
in the DirectDraw implementation.
The Sims calls CreateSurface() with DDSD->dwFlags & DDSD_PIXELFORMAT set
to state that a pixformat is speci
When trying to submit my first patch I did not do it correctly, and on
http://source.winehq.org/patches/ it shows up 5 times.
The correct patch is
http://www.winehq.org/pipermail/wine-patches/2011-April/100677.html
Thanks for your patience.
Joel Teichroeb
oups dot google dot
com/d/topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion
I wonder if this announcement has any adverse effects on Wine's future.
We don't use any of mentioned APIs that are about to be removed. We use
Gecko more internal APIs. They are unfrozen for a while now an
Hi,
I have no idea to what extent and how Mozilla's Gecko library is being used in
Wine (all I know is that it's used in Wine's MSHTML component), but recently a
Mozilla developer made a very unsettling announcement: groups dot google dot
com/d/topic/mozilla.dev.embedding/c_NMcO-N8wo/discussion
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=9959
Your paranoid android.
On 3/15/11 1:50 PM, Marvin wrote:
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails
the label.
You can found the file combo.c in wine-1.2.2/dlls/user32/combo.c
I can't comment about the content of your patch, but a few things need
to be fixed.
First, is this something you can create a test case for? If so, please do.
Second, your mail won't apply with git-apply. Yo
I'm not entirely sure on how to do this properly. Making it an ERR
would be too loud for applications that never use s3tc textures, as a
WARN it's never going to be seen unless you look at the debug channel.
Printing a message in wined3d in CreateSurface() would probably work,
but the resulting ch
On 3 February 2011 01:00, Tobias Jakobi wrote:
> *bumping*
>
> This patch never went into master, although it's _very_ important. Wine
> users see a lot of D3D problems (mostly missing textures) since mesa drivers
> don't support s3tc "out-of-the-box" (libtxc_dxtn needs to be available).
> This le
Seems to have been a long thread recently about
restarting a port of Wine to Haiku, see
http://haikuware.com/bounty-discussion/1533-wine-bounty
I don't think there was anything really happening, though.
Hello,
I was searching online to find more info about GDI and I came across your
information.
Can you tell me, are you still involved with GDI? If
you are, how are things going for you?
Please let me know.
Sincerely,
Aaron Tyler
galllund3 how long it takes to have dx 10 and 11 and ubuntu natively, all
the world want to have a minimum release date for this wonderful work they
are dealing with the DX.
On Wed, Oct 20, 2010 at 2:31 PM, Joris Huizer wrote:
>
> --- On Tue, 10/19/10, Austin English wrote:
>
>> While these emails are very helpful, can you please do a
>> reply to the
>> original thread? It makes it easier for those of us using
>> clients with
>> threaded mode to follow.
>>
>> Thanks!
--- On Tue, 10/19/10, Austin English wrote:
> While these emails are very helpful, can you please do a
> reply to the
> original thread? It makes it easier for those of us using
> clients with
> threaded mode to follow.
>
> Thanks!
>
> --
> -Austin
>
I can understand that's easier, less mes
2010/10/19 Joris Huizer :
> Hello,
>
> In this patch ID3DXSpriteImpl_Flush is adapted; the new loop being like:
>
> int i, count, start;
> /* ... */
> for(start=0;startsprite_count;start+=count,count=0) {
> i=start;
> while(isprite_count &&
> (count==0 ||
> Thi
Hello,
In this patch ID3DXSpriteImpl_Flush is adapted; the new loop being like:
int i, count, start;
/* ... */
for(start=0;startsprite_count;start+=count,count=0) {
i=start;
while(isprite_count &&
(count==0 ||
This->sprites[i].texture==This->sprites[i-1
On 10/18/10 8:10 AM, Joris Huizer wrote:
> Hello,
>
> In the proposed patch "[PATCH 2/2] ntdll: Check for case-insensitive
> volumes.", I found this piece:
>
> +/* Add a new entry */
> +for (i = 0; i < sizeof(fs_cache)/sizeof(fs_cache[0]); i++)
> +if (fs_cache[i].dev == 0)
> +
1 - 100 of 988 matches
Mail list logo
