wine-devel April 2010

wine-devel@winehq.org

111 participants
263 discussions

Re: winedump: code cleanup
by Alexandre Julliard 02 Apr '10

02 Apr '10

"Mikhail Maroukhine" <mikolg(a)yandex.ru> writes: > - winedump/search.c::get_type - cleanup variable usage That's not much better. It would be cleaner to stop abusing the passed argument as a local variable. -- Alexandre Julliard julliard(a)winehq.org

2 3

MicroOLAP Database Designer for PostgreSQL
by Tom Wickline 02 Apr '10

02 Apr '10

This might be considered spam but I thought I would share it. MicroOLAP Database Designer for PostgreSQL with enhanced WineHQ support released. MicroOLAP Database Designer for PostgreSQL is an easy CASE tool with intuitive graphical interface allowing you to build a clear and effective database structure visually, see the complete picture (diagram) representing all the tables, references between them, views, stored procedures and other objects. Then you can easily generate a physical database on a server, modify it according to any changes you made to the diagram using fast ALTER statements. http://www.wine-reviews.net/wine-reviews/news/microolap-database-designer-f… Cheers, Tom

1 0

Re: [PATCH 3/5] Move palette uploading code over to arbfp blit_shader. [try 2]
by Henri Verbeet 02 Apr '10

02 Apr '10

On 2 April 2010 12:19, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > +void d3dfmt_p8_init_palette(IWineD3DSurfaceImpl *This, BYTE table[256][4], BOOL colorkey); That function is internal to wined3d.

1 0

Re: [PATCH 3/5] Move palette uploading code over to arbfp blit_shader.
by Henri Verbeet 02 Apr '10

02 Apr '10

On 1 April 2010 23:58, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > > +static void upload_palette(IWineD3DSurfaceImpl *surface) > +{ > + BYTE table[256][4]; > + IWineD3DDeviceImpl *device = surface->resource.device; > + BOOL colorkey = (surface->CKeyFlags & WINEDDSD_CKSRCBLT) ? TRUE : FALSE; > + > + d3dfmt_p8_init_palette(surface, table, colorkey); If that's really what you want, you need to add this function to wined3d_private.h. Right now it will generate a warning. Perhaps it should just be in surface.c though? This function depends on having an active context. Where is "palette_texture" deleted?

1 0

re: [PATCH 0/4] Unwinding the stack with Dwarf (CFA) information on i386
by Dan Kegel 02 Apr '10

02 Apr '10

Eric wrote: > With this patch set, one can get rid of most of the non visible parameters values > while using a backtrace in winedbg. That's great news, thanks, hope it goes in soon!

1 0

Re: [PATCH 2/2] Revert prev. Hack, as Bug 10000 is still present.
by John Klehm 02 Apr '10

02 Apr '10

On Thu, Apr 1, 2010 at 11:16 AM, Detlef Riekenberg <wine.dev(a)web.de> wrote: > With greeting from the current day. > hehe nice

2 1

winmm: For MCI parsing, use 64bit compatible structures.
by Joerg-Cyril.Hoehle＠t-systems.com 01 Apr '10

01 Apr '10

Hi, Eric Pouech wrote: >this patch is ugly as hell... Please qualify. To me, - data[3] = (DWORD_PTR)dev; + parms.open.lpstrElementName = dev; looks more robust than before: - no magic offsets, - no casts that may silence warnings. The one #ifdef WIN64 is a pure performance optimization on Win32. The other one with the TRACE() is indeed ugly, but I don't feel it's safe to call debugstr_w() on misaligned data in Wine64. Even if it were, printing data[3] as string may be wrong, because it may be data[4] (+5) that holds a pointer, not (3+4). Therefore I decided to renounce to print string contents on 64bit, despite their value in the logs. > and it still believe we can do the MCI >parser without knowing about MCI structures internals What do you mean? Quite to the contrary, the parser depends on knowing the internals of some commands (like MCI_OPEN) as well as the convention about the return value as 2nd (+3rd) slot after the callback. The parser bridges the gap between the resource definition files winmm_res.rc that are now in git and are known to work well with 32bit and the mixed DWORD/DWORD_PTR MCI_..._PARMS definitions whose correctness has been (partially) validated by tests. What we don't know is whether Win64 introduced a different winmm_res.rc. I'd sure would be pleased if somebody could describe whether there have been changes to the resources to accommodate 64bit pointers in MS-Windows. Everybody, please visit bug #22146 if you can contribute such knowledge. (Part of) my patch is needed even if there were (thanks to lack of magic offsets). Regards, Jörg Höhle

2 1

Another proposal for your critique: improving .NET 3.5
by John Koelndorfer 01 Apr '10

01 Apr '10

Wine-devel, Still looking at my options for summer projects and I thought this might be a good one that would work towards my goal of improving gaming for folks. As always, comments and critiques are very appreciated. I would request that, in addition to commenting on the general idea, that people also comment on the actual proposal. Does it look/sound good enough to be accepted? I fancy myself a fairly good writer but writing a proposal is still pretty new to me. :-) Thanks! John

4 5

Re: [PATCH 4/4] Add a blit method to arbfp_blit.
by Henri Verbeet 01 Apr '10

01 Apr '10

On 1 April 2010 12:50, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > - if (is_identity_fixup(src_format_desc->color_fixup)) > - { > - TRACE("[OK]\n"); > - return TRUE; > - } > - When did we stop supporting those? > + arbfp_blit.set_shader((IWineD3DDevice *)device, src_surface->resource.format_desc, > + src_surface->texture_target, src_surface->pow2Width, src_surface->pow2Height); You might as well call arbfp_blit_set() directly.

2 2

WineD3D BltOverride overhaul
by Roderick Colenbrander 01 Apr '10

01 Apr '10

Hi, For a while we have been discussing on how to clean up / rewrite some parts of the surface code in WineD3D. I did submit a number of patches to initiate a rewrite of some parts but not all patches were correct and it wasn't clear what final design I had in mind. I'm posting my ideas to here to get some feedback on how to proceed. For people outside wined3d this might not be that interesting but I'll give a short overview of the problems, so that you could also understand it a little bit. The main issue is that pieces of modern code and legacy DirectDraw code are entangled in a way which is not easy to untangle. There are various places which can be improved but for now I want to limit myself to 'BltOverride'. It is a big function shared between DirectDraw/D3D7 blitting and D3D8 CopyRects / D3D9 StretchRect and over the years it has become large and very ugly. The way I thought about simplifying this call is to move some parts to helper functions and to remove legacy functionality (e.g. move colorfill back to Blt). A lot of the work which has to be done is not just about moving code around. Some functionality can these days be implemented in a nicer way thanks to functionality like shaders. Below I have some pseudo code on how I think a chunk of BltOverride and the blit_shader calls it uses, should be implemented. The main idea is to move the majority of the code to the blit_shader. Unless color keying / 8-bit is required, I expect that no actual shader is needed. In case we need a shader, there are two cases namely when blit_shader is implemented using GPU shaders and the case we need a fall back. In case of the fall back, I think we need big chunks of the 'old' BltOverride code which needs to be moved over to ffp_blit. BltOverride (color keyed) offscreen surface -> render target blitting { if(orm_fbo && can_stretch) stretch_rect_fbo <-- this check is around now; but I guess we ultimately want a IWineD3DDevice_StretchRect which contains this code and which can fall back to BltOverride) context = context_acquire(CTXUSAGE_BLIT) blit_shader->set_shader(src_surface) blit_shader->draw_quad(src_surface, src_rect, dst_rect) blit_shader->unset_shader(); } arb_blit_shader based implementation { blit_shader->set_shader(src_surface) { generate_shader (if needed) activate_shader if(color_keying_active) upload_colorkey_to_shader if(p8_active) load_p8_palette } blit_shader->draw(src_surface, src_rect, dst_rect) { surface_internal_preload(src_surface) { under the hood, LoadTexture/LoadLocation should not perform surface conversion for us basically the issue is how to distinguish between 2d and 3d color keying and how to separete this } /* drawing */ if(fbo_blit) fbo_blit() else draw_quad() } blit_shader->unset_shader(); } ffp_blit implementation { blit_shader->set_shader(src_surface) { if(p8_active) load_palette else not_much_todo } blit_shader->draw(src_surface, src_rect, dst_rect) { if(need_color_keying) play_with_color_keying_flags (like current BltOverride does) surface_internal_preload(src_surface); if(need_color_keying) restore_color_keying flags activate_alpha_test_magic draw_quad() } blit_shader->unset_shader(); } I think the design described above could work (perhaps I missed something, please correct me then). One of the issues is color keying. Right now color key conversion is performed in LoadLocation based on some flag magic. In case of a 2d blit using shaders this is not needed but for Direct3D purposes it is needed. I'm not sure how to handle this in a clear way. (I fear that we also get some new issues when a game alternates between 2d and 3d color keying). I don't expect issues regarding 8-bit as long as we implement them in software and use opengl only during the upload (UnlockRect). If we would allow hardware blitting, it would need to be 8-bit -> 8-bit blits and no converted blits else we need hacks like paletteOverride which I would like to eliminate. Roderick

3 10

Jump to page:

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 April 2010