Thanks for the explanation -- I will email asking why soon -- and perhaps
resubmit the other patch
I have been looking at http://winehq.org/pipermail/wine-cvs to see what has
been applied
But source.winehq.org/git shows the diffs much nicer
- Nick
>
Why not create a texture and draw a quad instead of using glDrawPixels (as it
is deprecated in gl3)?Reference -- ogl 3 spec --
(http://www.opengl.org/registry/doc/glspec30.20080811.pdf)Under "E.1 Profiles
and Deprecated Features of OpenGL 3.0""Pixel drawing - DrawPixels and PixelZoom
(section 3
Thanks for reviewing my patch (it sure makes the SHOGO menu much nicer)
BTW do you know if I need to resubmit my other SHOGO patch ([PATCH] Fix ddraw
surface version setting)?
Concerning negative pixelzoom and drawpixels on R500
Please file a radar on that (and email the mac-opengl mailing list
gt; Hmm... Wouldn't this bug also affect surfaces without a PBO?
>
>
>> -Original Message-
>> From: wine-patches-boun...@winehq.org [mailto:wine-patches-
>> boun...@winehq.org] On Behalf Of Nick Burns
>> Sent: Sunday, December 21, 2008 12:36 PM
>>
> Resending this due to the terrible hotmail "formatting"
> Any tips for how to get legible emails out of hotmail without doubling up the
> newlines would be greatly appreciated
> Note: I cannot even read the emails I send from hotmail...
> ---
>
> I have a few tips for running built wine on
x27;
Now you should be able to run d3d and ogl windows apps under wine
- NickFrom 6cbcec2d4c5f6eb7a3855122eaf0f5c9957c30e0 Mon Sep 17 00:00:00 2001
From: Nick Burns
Date: Sat, 20 Dec 2008 20:08:27 -0800
Subject: Apple X11 GLX hacks
Workaround some issues with Apple X11
Also force vsync on (us
On Sun, Dec 21, 2008 at 4:40 PM, Nick Burns wrote:
>>
>> This is my last gfx fix for SHOGOThe readpixels call was putting data into
>> the wrong place in the pbo (fixed with pixelstore)And the y-flip code was
>> flipping the wrong data as well (set the bottom row to the bot
.
>
> Clearly there's some magic build juju that I don't have, perhaps
> related to opengl. I've read the wiki, but I haven't found anything
> that I haven't already tried. Can anybody provide a hint as to how to
> get this working? BTW, I'm usin
Thanks for reviewing this patchI have one more for SHOGO (w.r.t. 2d surface
blitting) - Nick> From: ste...@codeweavers.com> To: wine-devel@winehq.org>
Subject: RE: [PATCH] Fix ddraw surface version setting> Date: Fri, 19 Dec 2008
01:17:13 +0100> > The patch looks ok to me
Whow I sure did mess that upI had my patch -- then fixed it up and made a new
patchAnd for some dumb reason I uploaded the OLD version...SighI will resubmit
that patch(Sorry about my git newbie-ness) - Nick> From:
ste...@codeweavers.com> To: wine-devel@winehq.org> Subject: RE: [PATCH]
wined3d_
comments?
- Nick
From: "Nick Burns" <[EMAIL PROTECTED]>
To: wine-devel@winehq.com
Subject: RFC: Patch better support for DevMode Date: Mon, 01 Jan 2007
02:56:29 -0800
After looking at the behavior on xp and wine for EnumDisplaySettingsA and
EnumDisplaySettingsW before and af
Margolen <[EMAIL PROTECTED]>
To: Nick Burns <[EMAIL PROTECTED]>
CC: wine-devel@winehq.org
Subject: Re: dlls/opengl32/wgl.c: minor dealloc fix
Date: Mon, 01 Jan 2007 18:00:44 -0700
DO NOT top post bottom posted emails!!!
Nick Burns wrote:
>> From: Stefan Dösinger <[EMAIL PR
he app is using -- (should it also show params?)
And Thanks for the testing
- Nick
From: Stefan Dösinger <[EMAIL PROTECTED]>
To: Nick Burns <[EMAIL PROTECTED]>
CC: wine-devel@winehq.com
Subject: Re: RFC: OpenAL32.dll thunk -- demacroized
Date: Mon, 1 Jan 2007 22:42:42 +0100
Am 0
...
- Nick
From: Stefan Dösinger <[EMAIL PROTECTED]>
To: wine-devel@winehq.org
CC: Nick Burns <[EMAIL PROTECTED]>
Subject: Re: dlls/opengl32/wgl.c: minor dealloc fix
Date: Mon, 1 Jan 2007 22:33:49 +0100
Am 01.01.2007 um 11:03 schrieb Nick Burns:
There can be a problem where the detach i
After looking at the behavior on xp and wine for EnumDisplaySettingsA and
EnumDisplaySettingsW before and after a window has been created (I wrote a
little program to dump the devmodes), I noticed that the devmode structs
that wine gives back are lacking some fields.
Attached is a patch that f
ibs returned addresses in
that space? (not sure)
- Nick
From: Alexandre Julliard <[EMAIL PROTECTED]>
To: "Nick Burns" <[EMAIL PROTECTED]>
CC: wine-devel@winehq.com
Subject: Re: Wine 32-bit address space
Date: Mon, 01 Jan 2007 11:29:51 +0100
"Nick Burns" <[EMAI
According to
http://msdn2.microsoft.com/en-gb/library/aa366912.aspx
The range 3GB (0xC000) - 4GB (0x) is considered system memory
and apps should not write here (not sure why you would want to read from
there either).
But Wine tries to mmap this range (on Mac OSX at least)
I w
From: Alexandre Julliard <[EMAIL PROTECTED]>
To: "Nick Burns" <[EMAIL PROTECTED]>
CC: wine-devel@winehq.org
Subject: Re: Concerning the separate OpenAL32.dll thunk patch and
OpenALwinmm driver patch
Date: Fri, 01 Dec 2006 13:49:52 +0100
"Nick Burns" <[EMAIL
not
help linux
- Nick
From: Pierre d'Herbemont <[EMAIL PROTECTED]>
To: Nick Burns <[EMAIL PROTECTED]>
CC: wine-devel@winehq.org
Subject: Re: Concerning the separate OpenAL32.dll thunk patch
andOpenALwinmm driver patch
Date: Fri, 1 Dec 2006 17:15:30 +0100
On 1 déc. 06, at
- so other
people who know more about audio can add to it and make it better
If the audio drivers are going to collapse -- I could wait until then and
'try' add my winmm patch in that realm.
- Nick
From: Alexandre Julliard <[EMAIL PROTECTED]>
To: Detlef Riekenberg <[EMAIL PROTE
The patches have been split in 2 one for the thunk and one for the winmm
driver.
Have these patches been rejected?
(I still dont know how to tell that -- other than checking wine-cvs)
- Nick
From: Stefan Dösinger <[EMAIL PROTECTED]>
To: wine-devel@winehq.org
CC: Nick Burns <[EMAIL
Good point in some cases we can just let get proc address pipe the func ptr
directly back to the app..
But..
On Mac OSX -- the stack must be 16 byte aligned (for and lib/sys call) --
this means we need to thunk for the stack on Max OSX -- If Linux or other
plats have similar reqs then the thun
ine-devel@winehq.org
Subject: Re: RFC: OpenAL Winmm driver and OpenAL32.dll thunk was Re:
OpenALand DirectSound
Date: Wed, 22 Nov 2006 10:25:10 +0100
Am Dienstag 21 November 2006 12:03 schrieb Nick Burns:
> Attached is my diff/patch for both an openal winmm driver and an
> openal32.dll thunk
chrieb Nick Burns:
> Attached is my diff/patch for both an openal winmm driver and an
> openal32.dll thunk
>I would like to get these into wine -- please comment and stuff...
Hey great, I will test it with Jedi Knight: Jedi Academy, which uses openal
afaik :-)
<< attach4 >>
?
- Nick
From: Stefan Dösinger <[EMAIL PROTECTED]>
To: wine-devel@winehq.org
Subject: Re: Mem usage in Mac OSX
Date: Mon, 2 Oct 2006 12:43:30 +0200
Am Sonntag 01 Oktober 2006 13:30 schrieb Nick Burns:
> Im seeing some very odd behaviour in Mac OSX using wine -- and wondered
if
>
Whow 3 posts in a row...
I am deving -- finally (ya in the AM on a sunday) -- too much real job work
on the weekdays
So, I have yet another problem...
This time it is with WGL/OGL
I know it is transition atm...
But... I dont know why Tribes2 is so very mad at me
Fullscreen tribes2 (in a vi
Im seeing some very odd behaviour in Mac OSX using wine -- and wondered if
anyone could enlighten me
When I run any application -- I see it start with ~4GB of VM then depending
on the app -- it goes upwards of 5.7GB in VM usage (>4GB?) in Activity
Monitor (usually because of texture loading o
I recently found genpatch. Wow, wowey wow wow. Very sleek
Used this line to gen the attached patch
./tools/genpatch -v -n winePatchMacOSXStackUpdate -c "Mac OSX stack update"
-m "include/msvcrt/process.h tools/winegcc/winegcc.c"
Anyway -- this patch is very simple and just extends the work that
From: Robert Shearman <[EMAIL PROTECTED]>
Subject: Re: Feedback requested for Mac OSX x86 stack patch
Date: Thu, 08 Jun 2006 10:29:11 +0100
Nick Burns wrote:
I tried using winapi_check, winapi_test, winapi_...
They all seemed to give me some odd perl errors (missing defs/funcs in
con
From: Robert Shearman <[EMAIL PROTECTED]>
Subject: Re: Feedback requested for Mac OSX x86 stack patch -- #2
Date: Thu, 08 Jun 2006 10:36:31 +0100
Nick Burns wrote:
diff -u -p -r1.114 ChangeLog
--- ChangeLog 24 May 2006 18:09:06 - 1.114
+++ ChangeLog 8 Jun 2006 07:06:10
Got ya will remove that when I send to the wine patch list
From: "James Hawkins" <[EMAIL PROTECTED]>
Subject: Re: Feedback requested on an OpenAL audio driver patch -- #2
Date: Thu, 8 Jun 2006 10:03:19 -0700
On 6/8/06, Nick Burns <[EMAIL PROTECTED]> wrote:
Ok I fixed
That looks very impressive (good progress).
I would have to look at the actual GLSL produced by this.
The actual translation points look good.
From: "Jason Green" <[EMAIL PROTECTED]>
Date: Thu, 8 Jun 2006 11:54:04 -0400
By the way, here's a comparison screenshot of Civ4 from before my hard
dri
Ok I have fixed up my Mac OSX stack patch a bit as per the feedback --
thanks much
This only patches windef.h
There still needs to be some solution for msvcrt AND any other api entry
points that are not denoted with __stdcall or __cdecl or WINAPI or
WINAPIV
This means that Morrowwind (use
Ok I fixed up my OpenAL driver as per the suggestions (thanks much)
I am not sure how to use or test pkg-config (does that exist on Mac OSX?)
The differences with the OpenAL driver patch...
1. It has a perty ChangeLog diff
2. configure.ac now checks for AL/al.h (which is where OpenAL should be)
From: Alexandre Julliard <[EMAIL PROTECTED]>
Date: Tue, 06 Jun 2006 12:14:47 +0200
"Nick Burns" <[EMAIL PROTECTED]> writes:
> I was concerned about msvcrt not using the __stdcall/WINAPI for its
> functions (why is this?).
Most msvcrt functions use the cdecl cal
From: Alexandre Julliard <[EMAIL PROTECTED]>
Date: Wed, 07 Jun 2006 11:40:42 +0200
"Nick Burns" <[EMAIL PROTECTED]> writes:
> What about overriding __cdecl and __stdcall?
> Are there any internal functions that use those that should not?
> That would get arou
From: Leon Freitag <[EMAIL PROTECTED]>
Date: Wed, 7 Jun 2006 12:07:32 +0200
> AC_CHECK_HEADERS(\
>+ OpenAL/al.h \
>+ al/al.h \
>AudioUnit/AudioUnit.h \
>CoreAudio/CoreAudio.h \
>IOKit/IOKitLib.h \
Your patch checks for OpenAL headers only in these places. However my
distro
(Sus
From: Leon Freitag <[EMAIL PROTECTED]>
Date: Wed, 7 Jun 2006 12:09:36 +0200
P.S. Isn't it better to use pkg-config to check where the libs are located
anyway?
Leon
Is there an example of this?
- Nick
From: Leon Freitag <[EMAIL PROTECTED]>
Date: Wed, 7 Jun 2006 15:54:49 +0200
My first impressions:
1) Doesn't compile here:
audio.c: In function âOpenAL_WaveCloseâ:
audio.c:636: error: void value not ignored as it ought to be
because alcCloseDevice() is declared here as void (my openal versi
From: Robert Reif <[EMAIL PROTECTED]>
Date: Wed, 07 Jun 2006 20:55:58 -0400
Nick Burns wrote:
It seemed to work well for GTA3, Tribes2 and FlatOut(requires a binary
patch to run) (dsound) -- and for SndRec32 (win/wout)
(Games and ...App... tested under Mac OSX x86 -- Mac Book Pro)
Although I probably should not talk to myself (responding to my own email)
Something did occur to me
From: "Nick Burns" <[EMAIL PROTECTED]>
To: wine-devel@winehq.org, [EMAIL PROTECTED]
Subject: Re: Feedback requested for Mac OSX x86 stack patch
Date: Tue, 06 Jun 2006 18:49
From: Alexandre Julliard <[EMAIL PROTECTED]>
Date: Tue, 06 Jun 2006 21:20:51 +0200
"Nick Burns" <[EMAIL PROTECTED]> writes:
> Ok so that makes more sense about MSVCRT -- but if it is using cdecl --
> shouldnt that use WINAPIV?
CDECL would be more appropriate.
Date: Tue, 06 Jun 2006 22:36:26 +0200
Nick Burns wrote:
OpenAL 1.1 supports recording... (1.0 does not have recording so that is a
problem yes)
-- My driver handles this atm -- it checks for recording capabilities and
supports accordingly
half or full duplex ?
Unknown... (sorry not an
to reform msvcrt for a full patch)
Date: Tue, 06 Jun 2006 12:14:47 +0200
"Nick Burns" <[EMAIL PROTECTED]> writes:
> I was concerned about msvcrt not using the __stdcall/WINAPI for its
> functions (why is this?).
Most msvcrt functions use the cdecl calling convention, not s
the attribs of) windows callable
functions.
I thought WINAPI and WINAPIV were sufficent -- If they are not more
functions will need to be 'fixed'.
From: Alexandre Julliard <[EMAIL PROTECTED]>
Date: Mon, 05 Jun 2006 21:21:01 +0200
"Nick Burns" <[EMAIL PROTECTED]&
(notes are at the top of the patch)
I would like some feedback on my stack fix patch
I do not know how it interacts with linux -- no access to a linux box
This has been confirmed to fix numerous app issues (due to stack alignment)
I am starting to think it would be better to have these options
OpenAL 1.1 supports recording... (1.0 does not have recording so that is a
problem yes)
-- My driver handles this atm -- it checks for recording capabilities and
supports accordingly
The OpenAL api is rather simple
- For playback : you make buffers and queue them then poll them (to find out
wh
On Fri, 02 Jun 2006 02:08:04 -0700, Nick Burns wrote:
Are there any problems with using OpenAL for such a purpose?
Probably not, it depends on the exact level of abstraction OpenAL gives.
But it begs the question - why?
thanks -mike
The reason for using OpenAL is for platforms that dont
I have started work on an openal driver for wine...
So far I have playback and recording working (with minor issues)
(for some reason the DSound HEL is unhappy with my driver)
OpenAL seems to have enough functionality to do the job.
Are there any problems with using OpenAL for such a purpose?
-
Whow sorry about messing up the patch there guys...
Serves me right for posting at 3am
In the future ill be a better citizen -- sorry again
- Nick
Here is the patch thus far -- It is not clean or anything... (cvs -q diff -
straight from my tree)
--I think this patch will work and allow you to run specific ogl and d3d
apps (with enough stack fudging see below)
--Here is an example of the stack fudging
--Since this is too hard to add to all
Whow I havent posted in a while...
Gottta job -- no more college (but I have to finish my Masters Thesis...
crap)...
Ok back to wine
---
(Mac OSX X86 ONLY)
Some of my friends an I have been working on wine after work and have
managed to put together some patches
OpenGL dynamic loading
Window resizing in Direct3d9 -- and I mean the resizing handled BY direct3d
-- stretches the rendered image to fit the resized window...
This allows 2DTestDX9 demo to work with resizing...
I would like to know if the current ideas for window resizing will handle
the 2DTestDX9 demo.
I know this i
Just thought I'd let ya guys know -- I noticed a little regression in the
latest build of wined3d
On Nvidia GeForce 4 4200 64MB (ask if ya want more specs)
dx9_1pass_emboss_bump_mapping.exe -- only a white rectangle (no longer the
embossed wood texture) on a black background
dx9_2pass_emboss
I got Water demo working -- whew thats all of my lil demos here (crap gotta
get some more...)
So heres the deal
Water should have worked with wined3d -- but it was crashing on me due to
the following...
(the patch is attached -- you may have to use fromdos (for formatting
newline issues))
..
It may be nice to prove/test that the opengl32.dll implementation in wine
works correctly -- but I agree that another translation layer does not sound
nice...
"__WIN32_OPENGL__" is the compilation flag im using -- it can either be
defined in the makefile (is not at present) or it is choosen by
Is window resizing supported in GLX wined3d?
For GLX -> WGL wined3d...
I have written an incorrect version of window resizing -- that simply
changes the viewport. This viewport changing works fine for the demos (but
does not stretch the output as semantically defined by d3d9).
I am guessing t
Initial window resizing implemented
Initial vsync choosing implemented
Initial swap effects implemented
Synced with wine HEAD (thats the fun part...)
GLX is still supported
#define __WIN32_OPENGL__
to use WGL instead of GLX (this is done automatically if either __CYGWIN__
or WIN32 is defined)
Do any of the other devs out there have any ideas how to do some nice and
easy automatic gfx testing for d3d9, etc...
At present my testing methods are slow and easily prone to error (does it
look like what d3d9 gave me?). I run the test on one computer (real d3d9)
then on my other (wined3d d3
please forgive the spacing...
...This is just a start at a format for this kinda thing -- pls modify as ya
see fit...
...also more demos wont hurt(well only me)...
results of wined3d - d3d9 regression testing 7_12_2005
--Windows98SE AthlonXP 2100+, 256MB, GF4 4200 64MB 85hz (using
wined3d+GLX
results of wined3d - d3d9 regression testing on windows98se gf4 4200 64MB
(using wined3d+GLX->WGL patch)
General overview
some demos give odd crash on exit
resizing windows is hacked (blame me) -- instead of stretching the output
-- it simply changes the vireport size
for programs that enum
OllyDbg is a good free binary disassembler/debugger
http://www.ollydbg.de/
Ida Pro is a very nice disassembler/debugger -- (its commerical but it there
is a free windows version)
http://www.datarescue.com/
http://www.datarescue.com/idabase/idadown.htm
W32Dasm is a decent (kin
Ok simple question...
should d3d8 be based off of d3d9 or wined3d? (or should it stay solo...)
Since d3d9 is a fixed interface (d3d8 is basically a subset) and the fact
that wined3d can change
it could help maintenence in the long run mayhap?
...just a simple question... nothing major
Nick
I have made a patch to make wined3d use wgl instead of glx (tested under
win98se gf4 4200 and winxp gffx 5500) and would like to extend it and see it
into the wine tree.
This patch also applies the d3d9patch.2005-06-13.diff (heavily modified due
to changes in wine head).
I can send the files
64 matches
Mail list logo
