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
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
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.0Pixel drawing - DrawPixels and PixelZoom
(section
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
To: wine-patc...@winehq.org
Subject: [PATCH] Fix glReadPixels call from
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 OS X
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]
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
using the latest XQuartz 2.3.2_rc3
(xorg-server 1.4.2-apple27).
Thanks,
-n8
--
Nathan Gray
http://www.n8gray.org/
From 6cbcec2d4c5f6eb7a3855122eaf0f5c9957c30e0 Mon Sep 17 00:00:00 2001
From: Nick Burns nwbu...@nwburns2.mshome.net
Date: Sat, 20 Dec 2008 20:08:27 -0800
Subject: Apple X11
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 bottom row and
not the height'th row)
The code used
under wine
- NickFrom 6cbcec2d4c5f6eb7a3855122eaf0f5c9957c30e0 Mon Sep 17 00:00:00 2001
From: Nick Burns nwbu...@nwburns2.mshome.net
Date: Sat, 20 Dec 2008 20:08:27 -0800
Subject: Apple X11 GLX hacks
Workaround some issues with Apple X11
Also force vsync on (using CGL)
And cut down the mem
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 after a window has been
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
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 [EMAIL PROTECTED] writes:
The range 3GB (0xC000
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
...
- 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 is hit before
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 01.01.2007 um 12:06 schrieb
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 00:54, Nick Burns wrote
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 PROTECTED] writes:
Again -- for the sound
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 PROTECTED]
CC: Nick Burns [EMAIL
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 PROTECTED
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
@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
Just a question
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
?
- 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
anyone could
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
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
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
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)
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
drive
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 up my OpenAL driver as per
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 -
@@ -1,3
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
config.pm
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)
How do
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
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
(Suse 10.1)
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 around the APIENTRY/WINAPI/CALLBACK problem
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 calling convention, not stdcall.
Ok makes
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 stdcall.
Where can I find
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:54 -0700
From
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] writes:
(notes are at the top
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
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?
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
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
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
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
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
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
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
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))
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
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
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
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
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
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
57 matches
Mail list logo
